Classes -> Engine Design -> Again -> Crazy
I''m sure this question has been up a couple of times already, but I think the question can''t be questioned to much.
What do I want of this question and what kind of answers would I like? Well, here goes: As my engine becomes more and more "sofisticated" I need to have a good structure and I''ve been rewritten this grunt a couple of times, when my structure keeps frying my brain over open fire.
This is the way I''ve been structuring it before the upcoming rewriting:
CInput -> Class For The Input (DirectInput)
CAudio -> Class For The Audio (DirectSound3D)
CVideo -> Class For The Video (OpenGL)
CLog -> Class For Logging
CMath -> Class For Math (Matrix / Vector ... Math)
CQuaternion -> Class For Quaternions (Creating / Loading ...)
CMD3Model -> Class For MD3 Model (Loading /Rendering ...)
CTime -> Class For Time (FPS / Frametime ...)
CCamera -> Class For The Camera (Rotate / Move ...)
CData -> Class For Static Data (Targa ... )
CGame -> The Hub Of The Web (ACTUAL CODING)
Does this seem reasonable for you experts? If I just can get a proper structure, everything will go so much smoother
And a somewhat off-topic question:
Functions like PrintToScreen and SaveScreenshot, should the be placed in the CVideo or the CGame class?
Are they separate objects or are you containing some inside parent classes? (child-parent referencing gets messy. I personally treat each as a global object, others will say make them singletons)
My global components include Window, Forms, Game, Gamestate, Sound, Resources, Network and Graphics.
Making the objects separate makes the design a lot easier, because it removes the need of figuring out "what needs to be a child of what."
There's no real place where your PrintToScreen and SaveScreenShot functions should go, but putting them inside CVideo seems to make sense. The detection for the keys that might trigger the operations, and the function calls themselves, could be inside CGame where it references CInput for key commands.
[edited by - Waverider on June 5, 2002 5:26:07 PM]
My global components include Window, Forms, Game, Gamestate, Sound, Resources, Network and Graphics.
Making the objects separate makes the design a lot easier, because it removes the need of figuring out "what needs to be a child of what."
There's no real place where your PrintToScreen and SaveScreenShot functions should go, but putting them inside CVideo seems to make sense. The detection for the keys that might trigger the operations, and the function calls themselves, could be inside CGame where it references CInput for key commands.
[edited by - Waverider on June 5, 2002 5:26:07 PM]
Thank you for the thoughts.
None of these classes will have any child classes (no idea what they are ) The "PrintToScreen" was placed in the CLog (wich now contails: ToFile and ToScreen [Log.ToFile / Log.ToScreen])
The SaveSnapshot was placed in the CVideo, but the game class hasn''t been implemented yet, but that class will be the hub of the entire project
None of these classes will have any child classes (no idea what they are ) The "PrintToScreen" was placed in the CLog (wich now contails: ToFile and ToScreen [Log.ToFile / Log.ToScreen])
The SaveSnapshot was placed in the CVideo, but the game class hasn''t been implemented yet, but that class will be the hub of the entire project
Hey, I''m doing much the same thing: trying to come up with a good class hierarchy that can be reused in other projects. For some ideas on OO engine design, I would suggest taking a look at this website: http://baskuenen.cfxweb.net
If you go to the C++ 3D Game Engine section you can download a sample game and source code. The author also explains the basics of the engine hierachy in the ''C++ Classes section''.
First of all, as a minor change, I would suggest a different name for CGame. You might assemble a class called CEngine that connects all of the classes in a reusable fashion. Then, for each project you might derive a CGame class from CEngine, and override/define functions.
Another idea that you might consider (which works well for GUI elements) is to have self sufficient objects. What I mean by this, is you might maintain a list of pointers to some base class in CGame, which have a common interface to update and draw themselves. Then, you just cycle through all the objects, and have them do their thing. If these objects represent menus, then you don''t have to worry about using a state machine. You just create a new class, and add a base pointer to it in your list. Then, the self contained menu object can draw itself, parse its input etc...
If you go to the C++ 3D Game Engine section you can download a sample game and source code. The author also explains the basics of the engine hierachy in the ''C++ Classes section''.
First of all, as a minor change, I would suggest a different name for CGame. You might assemble a class called CEngine that connects all of the classes in a reusable fashion. Then, for each project you might derive a CGame class from CEngine, and override/define functions.
Another idea that you might consider (which works well for GUI elements) is to have self sufficient objects. What I mean by this, is you might maintain a list of pointers to some base class in CGame, which have a common interface to update and draw themselves. Then, you just cycle through all the objects, and have them do their thing. If these objects represent menus, then you don''t have to worry about using a state machine. You just create a new class, and add a base pointer to it in your list. Then, the self contained menu object can draw itself, parse its input etc...
what about scene graphs ? does anyone know anything about scene graphs ? not the tree-algorithms I''m familiar with them but what about what actually goes into a scene graph in an indoor-environment-with-many-dynamic-objects type setup ...
<Fish>{
<Fish>{
Scenegraphs are an extremly good and extremly useful method for organizing all the objects that need to be drawn to the screen.
But what you need is a book or an article about the theories on structuring your gaming engine -- which should include more than just the stuff you need to render to a screen.
But what you need is a book or an article about the theories on structuring your gaming engine -- which should include more than just the stuff you need to render to a screen.
Try this one:
(Only the rendering part shown)
*it is plugin based, so you can add any features any time
CGraphics - graphics API specifics, base code, handles plugins
---
cModel - contains the model information only.
CModelPlugin - handles the rendering, animating, performing collisions and everything else with the cModel
---
cSprite
CSpritePlugin - sets various render states for drawing, draws sprites, performs collisions, etc.
---
CHeightmap - renders the heightmap. *may use CModelPlugin to test collisions between models and the map
it''s quite easy to say, but not to implement
div/0
---
Keep it simple, stupid
(Only the rendering part shown)
*it is plugin based, so you can add any features any time
CGraphics - graphics API specifics, base code, handles plugins
---
cModel - contains the model information only.
CModelPlugin - handles the rendering, animating, performing collisions and everything else with the cModel
---
cSprite
CSpritePlugin - sets various render states for drawing, draws sprites, performs collisions, etc.
---
CHeightmap - renders the heightmap. *may use CModelPlugin to test collisions between models and the map
it''s quite easy to say, but not to implement
div/0
---
Keep it simple, stupid
quote:Original post by TonyFish
exactly - I was think about getting "3d game engine design".
Any suggestions?
It''s really good if you have some higher-math background (difeq+), and still useful if you have a good math background (grok algebra, some linear algebra, & some calc). It''s probably too deep to be useful if you don''t (at the very least) have a good understanding of algebra. Google "WildMagic", I think you can download the code that comes on the CD with the book.
It has a chapter covering heirarchial scene graphs & animation.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement