Game Engine

This is a common setup:

static libs: (you make a own project for each of these, and build em as static libs)
graphics - (ususally has a big manager class, for setup, loading textures etc)
input - (ususally has a big manager class for reading keyboard/mouse/joystick)
sound - (also often a big "CSoundManager" class, for loading and streaming your wav files :)
math - (your vector and matrix classes if you roll your own)
physics - (if you use more then basic physics for collision detection etc)
utils - (frame timer, random, string utils, etc)

And as the executable, you build your game. Which depends on the libs above.
A good way to figure out what to put where when designing is to think in a network client/server way. Where you imagine that you will use a standalon server. The you can think "will this component be used by the client only, or the server only, or both?".

Three classes you will probebly want to have in your executable project is:

actor - a simple actor, use polymorphism or other method to controll if its a troll or a elf.. class troll_actor : public actor {};

level - represents a level, contains list of actors.

screens - diffrent screens in your game, for instance the menu, "ingame", highscore, credits.. etc. A nice design would be baseclass screen, and then:
class ingame_screen : public screen {};

This is what i can think of ontop of my head, if you have any specific questions just ask!
Hope this helps :)

This would probably go better in Game Programming; Game Design is more for gameplay aspects than implementation issues.

That being said, I have a generic 2D sprite-based engine that mostly works (I'm in the middle of re-implementing collision detection to make it faster). The engine itself divides the world into Layers, which are depthwise slices of the world (so e.g. Layer 1 draws on top of Layer 0, and sprites on different layers don't collide with each other). Each Layer contains a quadtree of Sprites. A Sprite contains a set of animations that describe how it is drawn, and a Lua script file that describes how the sprite behaves. The "update" function in the Lua script is called every frame so the sprite can do its thing.

There's no explicit "Player" sprite; rather, each sprite specifies whether or not it listens to user input when it is loaded. Presumably, the average game maker is going to want to have one sprite that accepts user input, and make the camera follow that sprite around. My design means that they aren't forced to do that, though.

Everything is configurable. The layers, sprites, and animations are all defined in config files. For example, an entry in layers.txt might look like:

L:0 #Layer 0
R:1 #Rate of scroll compared to a baseline, for parallax effects
C:50:100 #Location of first sprite
S:4 #Place sprite #4 at (50, 100)

sprites.txt looks similar, but instead declares whether or not the sprite listens to input, which animation "strings" define it, and which Lua script it uses. Animations are defined by referring directly to PNG files for each frame of the animation. So to make a new game with the engine, you would need to create: new PNG files, new Lua scripts, a new animations.txt, a new sprites.txt, and a new layers.txt.

Note that you can easily adapt this design to a 3D world; you'd just need to use model files and textures instead of animation frames, a more complex skeleton-based animations.txt, and an octtree instead of a quadtree (and obviously, no layers).

Congratulations!

First though, let me point out that the Game Design forum is more on, well, designing what the game is going to be like, rather than the software engineering aspect; but double-posting is a heinous crime so better wait until a moderator comes along...

I'm sure I'm not the best person to advise you of the specifics, but be sure to stick to the general object-orientated design principles like:

Loose coupling: components don't have too many dependencies, are not too interlinked, it's good to rely on interfaces (or abstract classes in C++) to abstract variations in behaviour

Strong cohesion: like instead of having modules that do bits of everything, modules do specific things like AI, rendering etc

Encapsulation: hiding complex operations, which is really the point of a game engine else you might as well just use the API

Open-closed principle: parts of your engine should be open for extending but closed for modification (as modifying existing classes is risking bugs)


I bet I sound like a seasoned developer with lots of experience after saying that, but my secret is that I read this fantastic book, Design Patterns Explained. It was quite cheap off Amazon too...gave me a whole new perespective on design. My coding wasn't bad before (and it was amazing to see how many design patterns I'd accidently used!) but now it's so much easier to look at the bigger picture. Also, learn and use UML. Period. It is sooo cool!


Good luck!


EDIT: omg! two people posted while I was writing! Just editing to say that it might be a good idea to download some free engines and have a look at their architecture.

Hey,
Thanks for the help. I'll check out the stuff some of you recomended.
Oh,
Thanks for the explanation about the Game Programming forum thing.
I thought that since I need design help it should go here. guess not.
Thanks again