   engine design
  hey everyone!I'm embarking on an in-depth and dangerous journey to the world of game programming and want to begin construction of a game engine. I've been coding for a *looong* time and know NOT to expect anything fantastic. In fact my goal is a simple 2D sprite engine, something small and enjoyable to make. I want this to be a huge learning experience and have plenty of time to devote.I've looked around, and even done a little (very little) prototyping. What I'm wondering about is what is a good way (not necessarily the *best way) to write the engine.I have a couple ideas:   1. Compile the engine code into a .dll file to be used for execution and a .lib file for game writing.   2. Integrate both into an executable. Create a foundation of the engine in some directory structure that is included by the game project.I'm thinking about going old-fashioned here and use a procedural approach rather than OO.So then for (2), I'm thinking about having a single .h file that defines and prototypes all the necessary structures and functions used as far as the engine goes. This file is shared by inclusion in other files, such as one that contains common graphical functions (non-specific to engine initialization) like loading a texture to apply to a sprite or drawing the mouse pointer. Functions like these require the d3d device, which would be a member of some sort of struct like gameEngineGfx_t.So if there was: gameEngineGfx_t g_engine; I would call something like: loadsprite ( path, g_engine ); or loadsprite ( char *path, g_engine.gfx ). Where the device would be a member of the gfx aspect.Would it be more beneficial to split up these aspects into multiple files? A gfx header, sound header, etc.Sorry for being so looooong-winded. I'm extremely interested in hearing what you guys think!   
  Well it is always a good idea to decouple as much as possible, so having separate headers for each "subsystem" would be nice.  I would highly suggest using OO though.   ;Quote:Original post by neweraI would highly suggest using OO though.What would be a good OO approach? Should each "subsystem" be its own object? Would a master object that controls all game systems be a good idea?   ;Quote:Original post by stealthgateQuote:Original post by neweraI would highly suggest using OO though.What would be a good OO approach? Should each "subsystem" be its own object? Would a master object that controls all game systems be a good idea?That's the general idea.  The point of organizing it this way is to divide the problem domain so that each object is concerned with only its area of operation.I encapsulated most of my subsystem classes into one large CApplication object, but try not to give your "ubercontainer" object too much responsibility.  You could end up with what they call the "god class", which is an anti-pattern where one object is bloated with too much responsibility.Procedural programming is perfectly acceptable; pretty much any code that is safe and maintainable is "good" code, but object-oriented programming tends to be more reusable.   ;  ive been thinking loooong and haaaard about this.A master object to control subsystems is a good idea.For me i have a master object which contains (among others) a mesh, view, skin and primitive manager.I also have an interface and a base class for these sub systems.I have taken all the non-d3d dependant code out of my d3d library (dll) and put it in my base class which compiles to an executable.Try to make your sub systems as independant as possible, it makes life easier imo.Tomorrow i am going to implement directx 10 where i need it. I think it is going to go well.;  I can definitely see the value in using oo rather than procedural. Each subsystem (gfx, sound, npcs, etc.) can be defined by classes. Now, each class is defined in some header file -- what prevents redefinition?Say I'm implementing a function that loads a texture and it requires (as mentioned earlier) the d3d device object. I can include the header file that describes the object which contains the device object as a member. But if I need it elsewhere, there is sure to be redefinition.Is a format like this a good way to prevent redefinition:#ifndef GFX_H#define GFX_Htypedef class CGfxObj{    LPDIRECT3DDEVICE9 d3ddev;public:    LPDIRECT3DDEVICE9 getDevice() { return d3ddev; }    // etc...} Gfx;#endifI've done some very rudimentary prototyping and haven't tried this method out yet.   ;  You may want to take a look at this article:http://www.gamedev.net/reference/articles/article1798.asphope this helps.   ;  thanks for the article link...it is more than helpful! i'm off to hack out something and see how well I can get it to function, I'll let you guys know how it turns out - hopefully I'll have some good knowledge to share by the end.   ;  Dont try to make your first engine 'the perfect' engine. Your first engine will be crappy but working. Your second engine will be still crappy but a bit better than the first one [smile] and so on.    As already shown OO would be the best approach. It will be helpful when you'll have to deal with lage amount of code.   ;  IMO, you shouldn't have functions like getDevice() since they are in a way 'limiting' your implementation of the engine. What if you want to port the engine to OpenGL or a software renderer? Instead, you should have functions that operate on the device, so the client program does not know or have access to the underlying device.   