Thread: Object oriented game design

I'm doing a simple 2D engine in SDL, and I'm having a hard time figuring out how to design the class hierarchy.

I want an interface that is completely seperated from the underlying engine, so that I may change from SDL to OpenGL in the future for the video rendering for example.

My first stumbling point was when I was designing an Event class that handles keypresses and similar input. If the users quits the program, the code should call a global quit function that all classes should use, but I can't figure out how to design this part without using global variables (which I want to avoid). The quit function can't be static since it will have to cleanup non-static data. I also want to try to avoid multiple inheritance since everyone say to avoid it if possible.

Maybe this will help? Managing Game States in C++ « Game Dev Geek

Originally Posted by rogster001

Maybe this will help? Managing Game States in C++ « Game Dev Geek

I looked through it quickly and I agree that the design looks good (I've used the stack-based game-states before and they're very useful). But c'mon..:

Code:

// the stack of states
vector<CGameState*> states;

Hooray for std::stack...
I think the comment/line combination is a bit of a WTF.

That's a useful resource, but that design still has the same problem that I mentioned above. How should the HandleEvents() function in the CGameState class handle an event that requires calling a public member function in CGameEngine (e.q. a quit function)? You could use exceptions for this, but that's hardly what I would call a solid class design.

I think there are several methods. The best is probably; you could have a virtual method named "running" in all classes. Now, if a certain game state is running, the logic would be like this:

Code:

while(state.running()) {
  // Render, do events
}

The game state can now keep a local flag to indicate to the state manager that that game mode should be killed. You could even inherit that functionality similar to this:

Code:

class GameStateBaseClass {
public:
  GameStateBaseClass() { _quit = false; }
  virtual bool running() { return _quit; }

protected:
  void doQuit() { _quit = true; }

private:
  bool _quit;
};

Now any game state can simply call doQuit() to quit that game state and go to the previous one. You should never want to quit multiple states at the same time, as it's up to the state itself whether it should terminate. Eg. the game should never quit the entire program, it should go back to the main menu.

Otherwise you could have the popGameMode defined publically. The state manager probably shouldn't be a singleton, but you could pass it to the GameStateBaseClass class. Then from there you could just call _manager->popGameMode();

Okay here's another example. What if the event received is to save the game? It would be nice to have a public member function in the main Game class that handles it, i.e. Game::Save(). The problem is then, how is the Event class going to call that function? The save function can't be static. I can think of a couple of similar situations ...

Originally Posted by Memloop

Okay here's another example. What if the event received is to save the game? It would be nice to have a public member function in the main Game class that handles it, i.e. Game::Save(). The problem is then, how is the Event class going to call that function? The save function can't be static. I can think of a couple of similar situations ...

I wouldn't think of that as an event. And event is a mouse move, a click, a key press or release, an exit request, etc.
If there is one GameMenuState game state, which has a save button, the mouse click is the actual event. The GameMenuState finds out the user clicked save. Now, indeed, it has to call the save method on the MainGameState (for instance).

What I'd do is pass that MainGameState (inheritted, at least, by SaveableGameState with a virtual safe() function) to the GameMenuState. Maybe to its constructor, maybe to another function.
That's the best solution I can think of now.

Originally Posted by Elysia

Call me crazy or something, but I like the idea of a full-out event-driven system. The biggest benefit I see is that you do not need a loop that keeps polling states.
Instead, make it event-driven. Sleep (perhaps a mutex) until event is received, then process the event.
You could also create an event that accepts a functor to call and then create a functor using lambas directly in the code where you create the event.

I think that depends on the application. On most games, at least 3D, a lot of things happen and re-rendering has to be done all the time. In fact, the 3D applications I made so far all polled for events and rendered whenever there were no events available to process. For a normal application I agree that an event-driven design is better. For a 2D game engine I'm not sure, but I reckon it's the same as 3D. Unless of course for relatively static games like tic-tac-toe.

Event driven game engines give higher performance, as well as allowing greater flexibility. You don't need to rewrite the entire engine just to add a new type of attack for example, you simply create a new event, and then write the code into the object classes to handle that new event.

Originally Posted by Elysia

Maybe not. It was just a suggestion of something that might work, although not the best things to use use.

The only thing I really care about otherwise is that cpu cycles are not wasted on nothing
If they are being used to process necessary data, then it is all fine. But polling like the above code is definitely not a good thing. That would be a waste of cpu resources.

I still find it hard to believe. Most source I read worked something like this:

Code:

While running:
  While event available
    Handle event
  Render

So we only lack any events to handle once per frame. And most frame rates of games don't go over 60 or 120 per second. So how much processor power can we waste on polling events? I doubt it'll be much.