• Advertisement
Sign in to follow this  

engine design

This topic is 4280 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

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!

Share this post


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

Share this post


Link to post
Share on other sites
Quote:
Original post by newera
I 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?

Share this post


Link to post
Share on other sites
Quote:
Original post by stealthgate
Quote:
Original post by newera
I 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.

Share this post


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

Share this post


Link to post
Share on other sites
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_H
typedef class CGfxObj
{
LPDIRECT3DDEVICE9 d3ddev;

public:
LPDIRECT3DDEVICE9 getDevice() { return d3ddev; }
// etc...
} Gfx;

#endif



I've done some very rudimentary prototyping and haven't tried this method out yet.

Share this post


Link to post
Share on other sites
You may want to take a look at this article:


http://www.gamedev.net/reference/articles/article1798.asp

hope this helps.

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Personally, in my solution file, I have 3 projects: my engine code, my engine unit tests, and the actual game code. The unit tests and game just compile normally; however, the engine itself is set to compile to a static library and the other projects are supposed to link against it's object files, rather than the actual library. I also make the solutions directory a part of my include path so I can do things like #include <Engine/File.h>.

Share this post


Link to post
Share on other sites
Quote:
Original post by AcePilot
Instead, you should have functions that operate on the device, so the client program does not know or have access to the underlying device.


What do you mean functions that operate on the device? If I call a function that requires the device to execute, how should it get access to the device? Thanks...

Share this post


Link to post
Share on other sites
I'm assuming that all your graphics functions are going to be inside the CGfxObj class. That way, they already have access to the private d3ddev, so they dont need a getter function. If you have a sprite class, then that sprite class probably needs direct access to the device. In that case, put something like
friend class Sprite;
in your CGfxObj so the device is availible to the Sprite class.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement