engine design

My simple game engine uses Object composition from http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/. It works relatively good and its easy to write and modify.

I use a base class called Object and from that I inherit everything else. Have been working great so far, the only hard thing have been to make the editor with it. I think inheritance from a base class is straight forward and easy to understand.

edit: think i understood the question wrong

I, kind of, don't really manage my game states...

When I was trying to find a nice, simple way to do my state "system" (for lack of a better word) I had a look through these forums and found someone (I forget who) who suggested using what's called the Run and Return Successor pattern.

So I end up with a main game loop that looks something along the lines of:

while ( running )
{
current_state = current_state.update( );
if ( current_state == null )
{
break;
}

current_state.draw( );
}


I've found this to be all the interface I need for most cases and enough of an interface to handle more complex cases. If your game happens to need hierarchical states for example, then just implement the interface and store a collection of states in your class.
If you need a paused state, just have it take the normal game state when initialising and return that original state when pausing should stop.

So I now don't have a manager, meaning that if I wan't, I can have game states anywhere I need and that the only place that has the right to switch states is the state itself. As it should be, IMO.

As for your design pattern question, whenever a particular pattern solves your problem completely without too much overhead is generally considered a good time to use it.

I use a base class called Object and from that I inherit everything else. Have been working great so far, the only hard thing have been to make the editor with it. I think inheritance from a base class is straight forward and easy to understand.

edit: think i understood the question wrong

It's cool my question is a little nebulous. Maybe I just need to learn more about OOP.

anyway Thanks guys. I'll read more about that shallow hierarchy thing, seems interesting. Yeah I think that's the best way to do it diablos_blade. I was thinking that maybe the 'switch' thing would just be easier and maybe Polymorphism might not be needed for smaller games, but I guess it's a good way to work.

I basically avoided inheritance as much a possible, which ended up being completely, and offloaded stuff to Lua as much as I could. This included input, interface stuff, game objects, game logic, and so on. Since everything was basically being run in a lua script, tracking game state wasn't really necessary, because... well, so little's actually hard coded that it's just not an issue. The only game states I have are um... request to change level, request to save game, and request to quit. Which are just stored in global variables (and are the only global variables I have, outside of the lua VM and some SDL junk which both have to be global).

Except now I have to rewrite a bunch of stuff because I didn't know anything about functional programming when I STARTED embedding Lua and there's a bunch of stuff that would be more elegant if I just offloaded it to Lua as well. tl;dr version -- closures are the best things.
In terms of game objects, what I'm doing is like... there's a game object class, and an instance class. GameObject has the immutable data, and Instance has the mutable data. I think this is like, a Flyhweel pattern or something. I don't know. Basically though there's no real class hierarchy. Everything in a level's going to be an Instance of a GameObject. In terms of C++ implementation, the player, walls, items -- they're all the exact same class. And every game object is basically just a register for a lua script, which can have a map representation if it wants.