Object oriented game design

Memloop · 10-31-2009, 04:03 PM

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.

rogster001 · 11-01-2009, 07:17 AM

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

EVOEx · 11-01-2009, 07:27 AM

Quote:

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.

Memloop · 11-01-2009, 11:42 AM

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.

EVOEx · 11-01-2009, 12:28 PM

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();

Memloop · 11-01-2009, 12:51 PM

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 ...

EVOEx · 11-01-2009, 01:19 PM

Quote:

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.

Elysia · 11-01-2009, 01:34 PM

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.

EVOEx · 11-01-2009, 01:53 PM

Quote:

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.

Elysia · 11-01-2009, 02:01 PM

Of course, I am not a game developer, so I cannot say for sure, but it would seem that event driven is always the best. By streamlining the process of making events, it should be fast.
Today's games waste a lot of cpu power simply by doing idle looping.
It is an interesting concept, though, even if it would not work.

abachler · 11-01-2009, 04:53 PM

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.

**Bubba** · 11-01-2009, 04:55 PM

Quote:

Sleep (perhaps a mutex) until event is received, then process the event.

Quote:

By streamlining the process of making events,...

A mutex is not exactly streamlining the event process.

Quote:

Today's games waste a lot of cpu power simply by doing idle looping.

No they are maxmizing the use of the CPU. Just b/c the CPU usage reads 40% in your game does not mean it is being used optimally. All that means is you are playing nice with the Windows scheduler.
Too many threads will degrade performance and threading the wrong things will also degrade performance. Today's games overall are maximizing the CPU but moreso the GPU. Who cares about the CPU when the bottleneck is really the bus and getting data to the GPU? In the future most calculations will be all done on the GPU so it really doesn't matter what the CPU is doing. The CPU will probably be doing audio mixing, input processing, etc., which can all be threaded. Everything else will be done on the GPU to even include real-time tesselation of primitives and the tesselation will be done by the GPU. This can already be done in geometry shaders and newer cards are advertising real time tesselation of terrain grids in pure hardware in DX10 and DX11. No one cares about the CPU anymore b/c it usually isn't doing anything. If the CPU takes 100% to do audio and input while the GPU does everything else....does it really matter? The real powerhouse of graphics lies on the video card not on the motherboard.

Event driven systems are standard fare and most probably use it. Most of the books I've purchased recommend using event driven systems. If you want to learn more about how to do an event driven system I suggest purchasing Game Code Complete, 2nd ed..

Elysia · 11-02-2009, 10:09 AM

Quote:

Originally Posted by Bubba

A mutex is not exactly streamlining the event process.

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.

EVOEx · 11-02-2009, 11:16 AM

Quote:

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.

Elysia · 11-02-2009, 12:08 PM

A lot (I think?

). The whole while running is unnecessary polling.
Use a block to stop the main thread from running when there are no events and use a quit event to quit the game.

10-31-2009, 04:03 PM	#1
Memloop Robot Join Date: Mar 2009 Posts: 100	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.
Memloop is offline

11-01-2009, 07:17 AM	#2
rogster001 Registered User Join Date: Aug 2006 Location: Liverpool UK Posts: 241	Cleanup() Maybe this will help? Managing Game States in C++ « Game Dev Geek
rogster001 is offline

11-01-2009, 11:42 AM	#4
Memloop Robot Join Date: Mar 2009 Posts: 100	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.
Memloop is offline

11-01-2009, 12:28 PM	#5
EVOEx Registered User Join Date: Oct 2008 Posts: 452	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();
EVOEx is offline

11-01-2009, 12:51 PM	#6
Memloop Robot Join Date: Mar 2009 Posts: 100	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 ...
Memloop is offline

11-01-2009, 04:53 PM	#11
abachler Rampaging 35 Stone Welsh Join Date: Apr 2007 Posts: 2,924	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.
abachler is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
C Programming 2d Array Question	jeev2005	C Programming	3	04-26-2006 03:18 PM
beach bar (sims type game)	DrKillPatient	Game Programming	1	03-06-2006 01:32 PM
Game Engine Link Prob	swgh	Game Programming	2	01-26-2006 12:14 AM
My Memory Game	jazy921	C Programming	0	05-05-2003 05:13 PM
Im a Newbie with a graphics design problem for my simple game	Robert_Ingleby	C++ Programming	1	11-23-2001 06:41 PM