Basic Game Engine Structure


I’ve seen a couple of posts on the forums asking what the best way to structure a game is. For what it’s worth, here’s a structure I’ve used in a few of my games. The design itself isn’t too complicated, but it’s pretty flexible, and will keep your code simpler in the long run. I think the Spacewars code uses a similar design, but I haven’t looked at it in depth (slightly embarrassing.) I won’t go into rendering engine structure; that could be a future post, if enough people ask. This is just a way of laying out all your GameComponents so that you’re not constantly tripping over your own feet.

 
Edit:

Just a small disclaimer – a sample
has been released on the Creators Club website which uses this basic
design, but is more flexible. Plus, the source is available! As much as
it pains me to say it, it’s probably a more useful resource than this
post.

 

The design isn’t too technically complicated, but you should at least be familiar with what a state machine and a stack are, and how to use generics.

 

The Problem:

To understand why this structure is useful, I’ll first explain the problem it’s trying to solve. Imagine a game that has a menu and is pauseable. The game is going to have to keep track of a lot of different GameComponents, and is going to have be constantly fiddling with the Visible and Enabled properties on them, depending on what state the game is in. For example, when you go from the menu to the game, you’re going to want to set Visible on all of the menu’s UI elements to false. When you pause the game, you want to stop updating everything, but you may want to keep drawing it like normal. It doesn’t take long for this kind of ad hoc structure to turn into a bug-prone code circus.

Say for example, you’re writing the code that pauses your game.  There’s about fifty different GameComponents in your game now, and you have to remember all of the ones that should be disabled when the pause key is pressed. What if you forget to disable the bad guys? Now you’ve got a bug where the player can pause the game, and everything pauses – everything except the bad guys, who happily carry on blasting your ship apart.

What we need is a better way to keep the GameComponents organized. How do we do it?

 

The Structure:

Basically, we’ll turn the game into a sort of state machine. The whole design will center around two classes, GameScreen and GameScreenManager. A GameScreen is a grouping of GameComponents, and roughly corresponds to the current state the game is in: at the menu, waiting to start a game, playing the game, paused, etc. For this example, we’ll have the MenuScreen, PlayScreen, and PauseScreen.

Each of the screens keeps the GameComponents it needs in a GameComponentCollection, just like Framework.Game does. GameScreen also has Update and Draw functions that call Update and Draw on their components.

The GameScreenManager is in charge of keeping track of all the different GameScreen. Internally, this is implemented as a stack of active screens.

Here’s the structure we have so far (sorry about the shoddy diagram; VS2005’s class designer is cool, but I’m not very good at it. There should be a “has-a” association between GameScreenManager and GameScreen – the ActiveGameScreens stack.)

Ok, so why a stack? At first glance, it seems like an odd way to organize your screens. It allows for some pretty cool behavior to be implemented simply, though. Let’s say, for example, that when the user pauses the game, you just want to stop everything from updating, and put an image over the top of everything that says “Paused.” With a stack, that’s easy: you can just push a new PauseScreen onto the stack. When the user unpauses, pop the PauseScreen back off again. To implement the “everything still draws, but nothing updates” functionality, we’ll add two new properties to GameScreen. BlocksDraw says that no screens under this one can draw, and BlocksUpdate does the same thing for update.

Now, we’ll give GameScreenManager Update and a Draw functions. In his Update, he’ll go through the stack of ActiveGameScreens from top to bottom, calling Update on everyone until he finds someone that BlocksUpdate.

Draw is a bit more complicated, since we want things on the top of the stack to draw after things on the bottom. Bear with me here, think of pause again: we want to draw the game screen, then the pause screen over the top. In order to get this behavior we have to draw from bottom to top. But, in order to know what to draw we have to go through the stack from top to bottom, looking for BlocksDraw. So, we’ll go through twice: Draw could be implemented using a temporary list called screensToDraw. First go through the stack from top to bottom, adding to screensToDraw until you find one that BlocksDraw. Then go through screensToDraw backwards drawing all the screens. Iterating through the screens twice is not likely to cause any kind of noticeable performance hit: it’s hard to imagine cases where you’d have more than around five screens on the stack.

List<GameScreen> screensToDraw = new List<GameScreen>();
foreach (GameScreen screen in ActiveGameScreens)
{
screensToDraw.Add( screen );
if (screen.BlocksDraw)
break;
}

for (int i = screensToDraw.Count - 1; i <= 0; i--)
{
screensToDraw[i].Draw( gameTime );
}

 

Different Screens:

It works for more than just pausing, too. You could split your HUD and main game into two separate screens, making their code easier to understand. You could go even further, splitting your HUD into separate elements, and then give the user control over what UI elements they want to see without completely muddying up your code.

In a first person shooter, you might have a console that slides down and takes up most of the screen. This could be a screen with BlocksDraw and BlocksUpdate both set to false. A full screen in game menu (the kind you hit esc to get to) would be a screen with BlocksDraw and BlocksUpdate both set to true. BlocksDraw is set to true for this one because there’s no point in rendering the whole game if the menu is just going to draw over it anyway.

 

Switching States:

If we give GameScreens a reference back to the GameScreenManager, they can access the ActiveGameScreens stack in order to move the game from one state into another. To replace one screen with another, like a MenuScreen might want to, just pop the current one off, then push the new one on. We saw above how pause would work: PlayScreen watches for the pause key, and pushes on a new PauseScreen. PauseScreen watches for pause button, and pops itself off. GameScreenManager’s constructor takes a GameScreen for the startup screen.

 

Initialization – A Complication:

When a game is first created, the graphics device is created, and then the base Framework.Game.Initialize is called. This function then calls Initialize on all of the GameComponents in the Components collection. Internally, the DrawableGameComponent.Initialize function does some magic to make DrawableGameComponent.GraphicsDevice and LoadGraphicsContent work. Obviously, those are important, so we need Initialize to be called on all the DrawableGameComponents.

However, since our screen’s components aren’t in Game.Components, Game won’t call Initialize for us: we’re going to need to do it ourselves. We’ll add an Initialize function to GameScreen, which will call Initialize on all of its components. Now, every time you create a GameScreen, remember to call Initialize on it – and make sure the graphics device is ready when you do so!

It all sounds complicated, but just remember to Initialize your GameScreens, and create your GameScreenManager in your game’s Initialize, not the constructor. Even if you don’t understand that part above, if you do those two things you’ll be fine.

 

Final Design:

Again, sorry about the diagram; There should be a “has-a” association between GameScreenManager and GameScreen – the ActiveGameScreens stack.

 

Potential Improvements:

To reduce stress on the garbage collector, advanced users might want to keep a cache of screens somewhere, rather than instantiating fresh ones every time. Take it easy on the garbage collector, and your performance will thank you. smile_regular


Comments (13)

  1. Machaira says:

    You beat me to it. I was thinking about doing something on this (it comes up a lot in game dev forums), but yours is probably better written than what I could have done. 🙂 For what it’s worth, I’m linking to this from my blog.

  2. Machaira says:

    I did come up with an idea for one improvement – if a window’s BlockDraw is set, the ones below it could be drawn greyed out. This would require a little change to the draw, probably overloading it with a flag to specify whether to draw regularly or greyed out.

  3. Ultrahead says:

    Very good article.

    Maybe one of the search processes for the Draw call can be erased, at least partially, by taking advantage of the update method.

    I mean when the update method goes through the stack in a top-down manner it also verifies whether the screen must be drawed or not.

    To ways to follow from here: either you let that search to "scan" all screens objects in the stack regardless whether a BlockUpdate was found or you stop when the BlockUpdate was found and continue the search in the draw method in case the BlockDraw was not yet found.

    Another approach would be using "events".

    Again, very good series of articles.

  4. CatalinZima says:

    The whole thing looks very good, but when I began implementing it, a thought crossed my head.

    Does this design ensure the calling of LoadGraphicsContent for the components in the GameScreen, when the device is reset ?

  5. Ultrahead says:

    @Catalin: maybe you could test it throwing a device exception at some point in the execution that requires resetting?

  6. nickspacek says:

    I’m implementing this pattern as well, and I had some thoughts, possibly related to CatalinaZima’s above.

    If you aren’t managing a pool of screens, then how do you ensure that the Initialize and LoadGraphicsContent methods get called?  I did a test, and if you Components.Add a DrawableGameComponent at the end of Game.Draw (after base.Draw) then the Game class is still smart enough to Initialize the component before it tries to Draw it.  Unfortunately, as far as I can tell there is no way to check if the Component has called its Initialize and LoadGraphicsContent.  But how is the Game class doing it then?

  7. nickspacek says:

    Just had a thought.  What could be done is to have either the GameScreens themselves or the manager add them to the Game.Components list and just manage their Enabled and Visible properties based on the blocksUpdate and blocksDraw properties.

  8. Mykres Space says:

    I came across this a little while ago and have been watching the progress, Game Maker Studio is a 2D

  9. JoelBennett says:

    nickspacek:  I am wondering about the same thing.  I guess there is only one way to find out – try it!

  10. zygote says:

    for (int i = screensToDraw.Count – 1; i <= 0; i–){    screensToDraw[i].Draw( gameTime );}

    this needs to be:

    for (int i = screensToDraw.Count – 1; i >= 0; i–){    screensToDraw[i].Draw( gameTime );}

    note the change of <= to >=

    thanks,

    Ziggy

  11. I came across this a little while ago and have been watching the progress, Game Maker Studio is a 2D editor and Engine for Tile based RPG Systems. In the month of January the system was released in CTP for us all to try and see how it goes. Included on

  12. Gabriel says:

    @zygote: he's iterating backwards through the collection. Your change would cause it to never run, because i will always be greater than 0 as long as screensToDraw has items in it. <= 0 is correct because it will stop after it reaches the item at index 0, the first one.

  13. Kaji says:

    A simple implementation: https://gist.github.com/925477

    Sincerely,

    Kaji