Sign in to follow this  
AcePilot

Game engine design

Recommended Posts

Hello, I have a question about the game engine I am currently designing. A few weeks ago when I had the idea of creating a game engine, I just thought to myself "I want a 3D renderer, a physics engine, network support, and a sound system in my engine". I started coding, but then the design got quite messy and I was only working on the renderer and the physics engine at this time. The engine had no apparent structure or design so I stopped working on it (I guess that is what you get when you start coding without planning properly). Then I restarted my engine project, this time designing it in UML first. That is where I am right now. Currently this is my design: Design I have organized my engine into subsystems, which are responsible for different tasks. Anyhow, my question is that is it necessary to list every single function in the engine to properly "plan" the engine? Or can you just do the following along with a requirements/features list? Design Any help is appreciated. P.S. There are some errors in the UML designs but nothing major...

Share this post


Link to post
Share on other sites
It looks like a good start, though I am a little confused on the connection between MatrixOperations and GraphicEntity. Is that inheritence? Then I am really confused, as I don't that should be the case. In any case, I suggest you use some preexisting libraries for the math.

Also, this subject has already been discussed quite much on these forums (no, it's true!). Googling for game engine design site:gamedev.net will provide some of the threads. It's definitely worth looking through a bunch of those.

OMGBBQ~!one This is my 1337th post!

Share this post


Link to post
Share on other sites
I think the graphicsEntity should represent an entity in the world,
having a model, textures and maybe even an animation.
You will probably want to derive more detailed graphicsEntities
from this interface class.

However other responsibilities, like creating, managing and destroying
are not a responsibility of an entity. I would use some kind of manager
class which manages all entities (maybe even does some spatial sorting).
Setting a position for an entity should also update the manager (remove
and re-insert into the sorting-structure).

For creating & destroying I would use an abstract factory - input
the 'graphicsEntity-family (an enum)' and the factory will create
an instance of the subclass of your interface class.

Furthermore, in the renderer I would add a method "setActiveCamera()".

Instead of passing strings (filenames I assume) into various places
(like the soundsystem for playing a file), use a manager which caches
your sounds & wraps them into something like a 'soundbuffer' (a copy
of the file in memory).
This will bring you huge gains when playing the same sound over and
over in a small interval - since it's already in memory (ns-times)
instead of having to load it from the (slow!) harddisk (ms-seek-times).

That's some ideas for you to play around with :)

Regards

Share this post


Link to post
Share on other sites
The most important aspect of design is that is sets the delineation of responsibilities and interaction between components. While a throurough design may seem like it should have every single class, variable and method defined, this is usually overkill and may even be harmful. Flexibility on a small scale is just as important as a solid design is for the big picture. You don't want your design to be so detailed that you feel married to the minute details, or worse yet, to code other subsystems to rely on those minute details (if you *Absolutely Have To* rely on it elsewhere, its not a minute detail.)

A subsystem such as AI, Physics, Graphics or what have you is really very similar to the concept of a class. It has some details that are internal, it has a way that it interacts with the outside world (the "interface") and it has a clearly defined purpose and responsibility. You design a subsystem in much the same way as you would design a class. The difference is that your building blocks are now classes themselves, rather than methods and members. Much like a class, the internal workings of a system are of little consiquence as long as the interface is well designed and its responsibilities are clear. Of course, designing how your system works internally is also important, just the same as a class, but this internal structure is de-coupled from the outside world through the use of the interface, again, just like a class.

Some good questions to ask yourself:

What data does this system own?
what purpose does this system serve?
What other systems will interact with this system?
What kind of interface best serves this interaction?
What interfaces do I need to support interaction with these other systems?
What is the (rough) internal structure of the system.

While I'm sure that this list could be extented to include a few 'Hows' it is no small coincidence that the list is dominated by 'whats.' Generally speaking, 'Why' defines a need or purpose, 'what' defines its purpose and structure, and 'hows' define low-level behavior.

Share this post


Link to post
Share on other sites
Thanks for the replies Enselic, Kitt3n and Ravyne. The arrows that show relationships are quite confusing and unnecessary, so please disregard them [smile]. I am aiming for a more C-like interface to the engine, so inheritence is really not an option here. The reason I want to do that is so if I work with someone for a game project and they only know C, it is easier for them to understand the engine. I am thinking of creating an object-oriented wrapper for this engine later if my game requires it, since to me
 c.Normalize(); and entity.Render(); 

are much cleaner than
c = Normalize(c); and RenderEntity(entity);


As for the GraphicsEntity, it simply represents a Mesh but it stores the world matrix of the mesh too, so I can't call it a model or a mesh anymore. I will probably add animation support to the GraphicEntity interface since I've heard that an engine's Mesh capabilities are almost at the center of the engine.

As for Ravyne's comment, I am guessing that a 'plan' should then list the required functionality of a component, and should focus not that much on the 'how'? For example, If I added a rough specification of what each interface should do beside it's name in design two, would that be sufficient? Because my primary concern here is that am I over-planning and being too specific or under-planning and being too vague.

[Edited by - AcePilot on May 24, 2006 6:05:53 AM]

Share this post


Link to post
Share on other sites
>The reason I want to do that is so if I work with someone for a game project
>and they only know C, it is easier for them to understand the engine.
Imo opinion that's a bad reason - if the other programmer only knows
assembler, would you then write your entire project in assembler?

Try to learn the most you can, having experience in OO is valuable (imo).
Remember, finding someone else to work with is not easy, and you will
probably end up having to write maintain the engine yourself... OO
might just help you make it a bit easier.

Regards

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this