I am planning on making a new 3D engine with my team. Having learned from the previous engine we have made, it has been decided we would write a complete design document this time. This design document should be explaining how the engine will be built with a reasonable amount of detail, without going as far as writing pseudo-code. So here I am posting a link to this design document, hoping that people will read it (or at least part of it) and give me feedback about what they think could be clarified or what they think should be added, or simply if you believe this could be designed better and have suggestions. I must also say that my main language is french, therefore it is highly probable that you encounter a few grammar mistakes or incoherences in the text, if you find some, please notify me . Here is a link to our new Game Engine Design Document.
Looking for a serious game project?
www.xgameproject.com

If you could define what you mean by "MTUDP", that could be a start :D


Looking for a serious game project?
www.xgameproject.com

We''ve never talked about multithreading in the doc, which doesn''t mean it won''t be used. And actually, you have to realise, network traffic cannot "stall" the main loop, its more of the opposite: Low framerate can create higher latencies if it''s not multithreaded.

Half-Life has it single threaded, our past engine did have it multithreaded but the latency was just as slow as other games.


Looking for a serious game project?
www.xgameproject.com

1. Ditch the D3D & OpenGL & software rendering idea, you''ll just waste a lot of time doing duplicate work and making things harder for yourself.
2. Things like class names, directory structure and header file organisation are low level implementation details and shouldn''t be in a design doc.
3. Your renderer design is only described as being ''beyond the quality level of the average commercial game engine''. Theres no details on any spatial partitioning, how lighting and shadows will be taken into account, or what kind of environment it will be most suitable for.

Oooh, an indie team with a design doc! You are a rare find

Let''s see now:

Section 2.2:

Renderers: I probably wouldn''t bother with software rendering. I can''t see a minimum system requirements around anywhere (yes you should have one), but it''s really not necessary for most people with the systems of today. It''s also a very time-consuming thing to write. OpenGL and Direct3D switchable renderers is good though.

First person camera: why first-person? After all, the only difference between first-person and third-person is that in third-person has the player being drawn for themselves, and third-person doesn''t. I''d recommend a generalised camera system which allows you to ''attach'' the camera to an entity. It would let you do in-game cutscenes (thus not breaking the visual flow of the game) and would be a powerful feature for machinima. You still have the in-game movie playback if you need it.

Trilinear filtering: I''d expect this to be handled by the graphics API, no? The option to switch between linear filtering, bilinear filtering, and trilinear filtering would be best.

Buffered input + input system for movement and control: how about the ability to record and playback input (demos)? For that to work you''d also need to provide a random-number recording mechanism too.

In-game movie playback: render fullscreen, or to texture? I''ve seen few games where you can actually interact with a TV and get more out of it than just a 5-frame loop.

Section 2.3:

Coordinate system: Right-handed vs Left-handed isn''t about which way is up; given that X increases to the right and Y is up, it''s about which way Z increases - towards you or away?

Rotations: if you''re using euler angles for rotations, how useful are your Quaternion classes going to be?

Section 2.5

General: it would be a good idea to create a graphical representation of the systems in the engine and how they will interact - it doesn''t have to be UML, just something to show which blocks are there and how they''re tied together.

No Singletons: why?

Shared/Common: you are aware that mods don''t usually need actual source to compile, only headers, right? You could easily distribute headers and a static library, if we''re talking about utility code.

Map editor using game engine: That''s good. Are you looking at a full ''map IDE,'' complete with particle system designers etc, or just a Worldcraft-style geometry/entity building tool?

Section 2.6

General: OK, so here''s where you really need the diagram. A listing of class names isn''t terribly useful - at the very least, you need an outline of what that class does (unless that comes later).

Client and Server: you are aware that it''ll need to act as a pure client as well - when playing in a network game that someone else is hosting?

Section 2.8

Software rendering: again, I recommend you don''t bother (at least to begin with - maybe after everything else is done). There is no such thing as a ''simple'' software renderer, to put it simply. The only real reason I can see there for a software renderer is that the map editor might need it; but the map editor''s a tool. It''s not distributed to the users at large. Hell, to begin with, you have complete control over who gets it. Most, if not all, of your developers are going to have hardware capable of windowed rendering (I believe any OpenGL implementation will do it); any that don''t, well, they can code the software renderer while everyone else is making maps.

Abstraction: Looks pretty good, though you might want to look more into optimisations - I see ''vertex arrays'' in there, which is a good start, as Direct3D will prefer to be using Direct3DVertexBuffer9 objects while OpenGL doesn''t provide any such thing (except through extensions).

Section 2.10

Guaranteed UDP: instead of writing your own guaranteed messaging code for UDP, why not just have both UDP and TCP connections between client and server, and then pick a connection based on whether the message is guaranteed?

Confirm packets: if the original packet gets through but the confirm packet is lost, so the server sends the original packet again, how will the client know not to process the extraneous message? (It would still need to send a confirm, but it would then need to drop the message from its own queue).

Security key: If you''re testing the packet''s source address to make sure it''s from the server, I wouldn''t bother with the security ID. Anyone who''s intelligent enough to fake their machine address will be intelligent enough to use a packet grabber to get the security key out of it. Unless there''s something about the key you''ve not said.

Section 2.11

No RegisterEntityType()/CreateEntity()/AddEntityToManger()?

Section 3.3

Entity base class: when you say that the entity base class will be ''provided'' by the game engine, do you mean as an interface (an abstract base class, all functions are pure virtual), or do you mean as an actual class that the engine implements parts of (with some virtual functions for the game library to overload, of course)? If so you might get some linker weirdness... the .EXE of the game engine would need to export the members of that class, at least.

Section 3.4

Entity creation: Ahh, I see. In that case, I guess the CBaseEntity constructor would add itself to the entity manager? (In which case, see my point about section 3.3 above...) Or maybe the function returns the entity to the engine and then the engine adds it to the manager. Personally I don''t like the idea of the game library having to create the entity like that (as it''s going to be pretty much the same in any game library), but that''s more of a style thing, I think.

How will the game library behave when the engine is being used in the map editor? Will entities be visible in the game window at all? Or perhaps they''ll be defined by an external file, like the .FGD files in Worldcraft.

In general

It''s quite hard to read. You''ve got large chunks of text, with little emphasis, and it would definitely benefit from some diagrams in places. Also, look into using things like bullet points more - this document doesn''t exist so people can learn about your engine, it exists so they can quickly find information about how they should implement something. Eventually you''ll want to split it into multiple files, I expect (perhaps by the big-numbered sections (The Project, The Engine, The Game, The Design Process), and then cross link between them (indeed, don''t be afraid of putting links between sections in the middle of the text).

It needs more information - things like the audio system, the particle system, and so on. No doubt you''re still working on that.

Other than that, pretty good

Richard "Superpig" Fine
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3 | Enginuity4 | Enginuity5
ry. .ibu cy. .y''ybu. .abu ry. dy. "sy. .ubu py. .ebu ry. py. .ibu gy." fy. .ibu ny. .ebu
"Don''t document your code; code your documentation." -me

Glad to see some people did some reading

quote:3. Your renderer design is only described as being ''beyond the quality level of the average commercial game engine''. Theres no details on any spatial partitioning, how lighting and shadows will be taken into account, or what kind of environment it will be most suitable for.

Thats normal, space partitioning aren''t up to the renderer, its up to the world manager, which decides how the world is drawn... It could use octrees, quadtrees or BSP trees, the only difference would be in the type of frustum tests performed.

quote:Renderers: I probably wouldn''t bother with software rendering. I can''t see a minimum system requirements around anywhere (yes you should have one), but it''s really not necessary for most people with the systems of today. It''s also a very time-consuming thing to write. OpenGL and Direct3D switchable renderers is good though.

One of the reasons we are making a software renderer is because it poses a good programming challenge... It can also help for the map editor, and if we have it for the map editor, might as well let the game use it.

quote:First person camera: why first-person? After all, the only difference between first-person and third-person is that in third-person has the player being drawn for themselves, and third-person doesn''t. I''d recommend a generalised camera system which allows you to ''attach'' the camera to an entity.

Yes I have been thinking about "binding" the camera to entities, third person mode could possibly be added.

quote:Trilinear filtering: I''d expect this to be handled by the graphics API, no? The option to switch between linear filtering, bilinear filtering, and trilinear filtering would be best.

Those options won''t be provided, the renderer will choose how it manages textures... And most likely, we will just have the renderer pick the best filtering method available on the user''s hardware (I hardly see a performance difference between them anyways).

quote:Rotations: if you''re using euler angles for rotations, how useful are your Quaternion classes going to be?

Euler angles for the rotation of entities, but skeletal animation needs to be done differently.

quote:Guaranteed UDP: instead of writing your own guaranteed messaging code for UDP, why not just have both UDP and TCP connections between client and server, and then pick a connection based on whether the message is guaranteed?

Confirm packets: if the original packet gets through but the confirm packet is lost, so the server sends the original packet again, how will the client know not to process the extraneous message? (It would still need to send a confirm, but it would then need to drop the message from its own queue).

Security key: If you''re testing the packet''s source address to make sure it''s from the server, I wouldn''t bother with the security ID. Anyone who''s intelligent enough to fake their machine address will be intelligent enough to use a packet grabber to get the security key out of it. Unless there''s something about the key you''ve not said.

No offence, but it seems like you don''t have much experience with networking. Guaranteed UDP is easier to implement than having two connection mechanisms. If the server sends a reliable packet, the client will send a confirm everytime it is received, but the packet will be treated like any normal packet on the client side. Everyone connected to the server knows its address, the client address can also be known if you know the client (somebody on IRC for example). The purpose of the security key is to make it next to impossible to spoof packets. The fact is, you can''t use a packet sniffer remotely, you have to be on the same network as the person.

quote:this document doesn''t exist so people can learn about your engine, it exists so they can quickly find information about how they should implement something

I disagree, every new joined will need to read it, to get familiar with the engine. Its purpose is to give people an idea of how we are globally doing things, in the big picture. Implementation details are usually up to the programmer.

Next thing I need to do is to talk about the world format


Looking for a serious game project?
www.xgameproject.com

Nice job. It''s a very good start-- much better than most. I''m eager to see how the project progresses. I am working on something similar, although I''m still in the prototyping phase. If you haven''t read it, you ought to check out a book called Large Scale C++ Software Design. It''s got some really good information on managing the complexities of especially large projects (like game engines). Unlike most books, he spends a good deal of time talking about the physical layer of design (file structure, revision managment, etc.)

bpopp (bpopp.net)

quote:The fact is, you can''t use a packet sniffer remotely, you have to be on the same network as the person.

Sure you can. Are you forgetting about your clients? Don''t be so naive as to think they won''t be your biggest threat. If the engine is popular enough, you will get hacked. Like superpig said, a security key, unless it is fairly complex (which is difficult to do due to resource limitations) can easily be reverse engineered (especially if the project is open-source). Look at how quickly CD key algorithms get hacked (or so I hear)


bpopp (bpopp.net)