Archived

This topic is now archived and is closed to further replies.

New Game Engine

This topic is 5145 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Wouldn''t it be better to make a MTUDP client/server network system instead of just UDP? I don''t know what the pros and cons are for the both, but it might be something to look into.

-UltimaX-

"You wished for a white christmas... Now go shovel your wishes!"

Share this post


Link to post
Share on other sites
Multithreaded User Datagram Protocol. Same thing as UDP just multithreaded. It''s alows for updates, and the such, without stalling your main loop.

-UltimaX-

"You wished for a white christmas... Now go shovel your wishes!"

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
quote:
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.



I disagree. Now that we have 3D cards, we should use them. To fall back to software rendering like Quake I, to write a software rasterizer that constructs a frame buffer to be copied to video memory, doing stuff like texturing in software, that''s not a challenge, it''s wasting your time.

Share this post


Link to post
Share on other sites
quote:
Original post by Fidelio66
quote:
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.



I disagree. Now that we have 3D cards, we should use them. To fall back to software rendering like Quake I, to write a software rasterizer that constructs a frame buffer to be copied to video memory, doing stuff like texturing in software, that''s not a challenge, it''s wasting your time.



Oh, it''s certainly still a challenge, but yes, it''s wasting time. If you''re determined to include it in your project spec, Max_Payne, then I strongly recommend that you get the other two renderers done first, and then do the software renderer later when it wouldn''t be blocking progress elsewhere. Consider it a perk to be added at the end.


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

Share this post


Link to post
Share on other sites
quote:
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)


The 32 bit security key is random, that makes 4 billion possibilities. The only way to "crack" it is to try as many possibilities as you can. To try all these possibilities it would take gigs, making it MUCH harder to spoof client traffic.

quote:
Oh, it's certainly still a challenge, but yes, it's wasting time. If you're determined to include it in your project spec, Max_Payne, then I strongly recommend that you get the other two renderers done first, and then do the software renderer later when it wouldn't be blocking progress elsewhere. Consider it a perk to be added at the end.


Obviously its not a top priority. We probably won't be making it ourselves in fact, we might just recruit somebody that likes ASM and optimization to do it for us. I find that having a software renderer along with D3D and OpenGL is a compatibility advantage, anyways, no point in saying its not useful, because it will be done one day :D

Not so long ago I have started a small section about physics... Now, the next thing I need to add is something that describes our world format and how the game world will be managed... Then I will revise the document some more and we will be ready to start.

On a side note, hasn't anybody found grammar or spelling mistakes?



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

[edited by - Max_Payne on November 8, 2003 3:28:27 AM]

Share this post


Link to post
Share on other sites
You don''t need an ID. In the unlikely even they did manage to spoof their address in the packet headers, you''d end up sending their packets to the wrong address, and communication simply wouldn''t work.

Share this post


Link to post
Share on other sites
quote:
Original post by smart_idiot
You don''t need an ID. In the unlikely even they did manage to spoof their address in the packet headers, you''d end up sending their packets to the wrong address, and communication simply wouldn''t work.


Ah please stop talking about what you don''t understand. With raw sockets, anybody can spoof the origin address and port. The server port is known... So if you know of a person who''s on the server because he is on IRC or on ICQ, you can just try all port numbers and keep sending disconnection commands until the person gets kicked, which could be done in a few seconds. With the security key, it could hardly be done in a few days.





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

Share this post


Link to post
Share on other sites
!!!!!!!!!
Quote
"We have also chosen not to simulate the more advanced physical phenomenons such as air resistance because this does not play a very important role in most games (apart from flight simulators)."

I completely disagree! you guys will miss the most exciting effects you can have in your physics engine!! How about drinving a car. Without this force your car will never stop accelerating! (ok there is rolling resist but still it will not look realistic at all!!)


Air resistance is so important.! How about magnus effect? its so cool especially in explosions!
Well in the end its your choice.

Share this post


Link to post
Share on other sites
quote:
Original post by Max_Payne
Yeah I''m sure all racing games simulate air resistance


Actually, they probably do - or at least, ''resistance to motion,'' which would be friction and air resistance rolled into one.

If you design a generalised physics system, adding air resistance should be a no-brainer - it''s just another dampening force in the system.

Share this post


Link to post
Share on other sites
> Guaranteed UDP is easier to implement than having two connection mechanisms.

I disagree; but there''s another very good reason for using guaranteed udp instead of tcp: unordered packets. For alot of stuff you need guaranteed delivery, but you DON''T want to wait for packets to arrive in order - TCP will make you wait (possibly a very long time) for lost packets to arrive in order, whilst UDP will give you the packets sent after the lost one.

Did you ever play Battlefield 1942 and you don''t receive a single team-talk message for 30 seconds... then suddenly you receive 50 message all at once? They should have used unordered guaranteed udp instead...

Share this post


Link to post
Share on other sites