Archived

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

Classes -> Engine Design -> Again -> Crazy

This topic is 5671 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''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?

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
3D Game Engine Design teaches you how to design an engine about as well as your highschool algebra text. It nicely covers all the components that go into an engine, but unless you wade through the accompanying code, which isn't too great IMO, you won't come out understanding how a practical engine fits all those components together.

Just think of it this way, some of those classes you mentioned will only have one instance throughout your engine, and for those I'd use layering, your engine class has a display class, an audio class etc. On the other hand, some of your classes will be instantiated several times, e.g. your textures, meshes, etc. So you should have a class to hold those, a scene graph in the case of the mesh, maybe a texture manager in the case of the textures.

On the plus side, that book has a lot of algorithims for the many mathematical problems you face with 3D, lots of containment, collision, transformation, etc. routines and explanations to be had.

------------
- outRider -

[edited by - outRider on June 8, 2002 8:43:43 PM]

Share this post


Link to post
Share on other sites
Supposedly "Programming Role-playing games with DirectX" is supposed to be a very good resource on both 2d and 3d engine design and goes through the whole process and helps you build a sample engine.

Share this post


Link to post
Share on other sites