• Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

About this blog

Random Thoughts and Progress

Entries in this blog

Game State

Well the good news is that I was given a reprieve on the 3 month overtime death march for two weeks. Unfortunately for my kick ass progress it looks like we will be starting it up harder and longer within the week. I was able to get some decent work done to my art assets. I have been looking into picking up the Genius G-Pen F610 drawing tablet to speed up art production, once I get a few dollars ahead. If anyone has any input on this little guy let me know.

Anyway, a few weeks ago I saw a blog on Gamasutra about using design patterns in your game. I personally think that is an awesome topic with loads of possibilities. The gentleman writing the blog briefly touch on a few. Now due to the nature of design patterns I personally think that it is hard to say whether someone else' implementation is right or wrong. As long as your implementation does not cause poor performance and solves your problem without causing other problems I call it a win.

[heading]What three things do almost ALL interactive software have in common?[/heading]

So before we get started discussing what is a design pattern I would like you to consider something. What 3 things do practically every piece of interactive software have in common? We'll come back to this later.

A design pattern is a solution to a problem that occurs over and over in software. I believe the idea was originally taken from the world of architecture. The awesome thing about design patterns is that they are very loose by nature.

[subheading]What the hell does that mean!?!?[/subheading]

Good question! it means that aside from some generalized concepts there is no cut and dried, "This is the only correct way!" The initial reaction is probably along the lines of, "how is that helpful in any way if the solution is not the same for everyone?" And there in lies the beauty and the power of design patterns. In software we run into problems that are pretty much the same things over and over. The real problem is that they are not the exact same problem over and over but have many of the same aspects. The solution to that problem needs to be specific to that problem in order for it to be successful.

What some really smart people did was put together groups of patterns of problems and solutions and called them design patterns. These problems are somewhat generalized as are the solutions. The design patterns also define the pros and cons of using them! Holy cow! That means there is a catalog in the mystic aether that solves all of our problems!

[subheading]No not really. But sort of.[/subheading]

There is a catalog of patterns and it is getting larger everyday and some of them begin to get more specific to a problem. Design patterns are not a silver bullet. They do not solve every problem and using as many as you can in one project will probably be more of a pain and less useful than it is really worth. To borrow a phrase.. We need to use intelligent design. One of the basic ideas in the patterns are abstraction and encapsulation. By adding some abstraction we can handle more problems with the same methods. By encapsulating things that don't change we can implement them across the board and change them across the board too.

I am doing a huge disservice by over generalizing but you will need to do a bit of research on your own to really get the nitty gritty of it all.

All of that being said I would like to talk about the State Pattern today. The state pattern describe the state of an object. So it's not just a clever name. Ironic isn't it. It consists of an abstract class using only virtual functions to describe the behavior of the class. Then a concrete class implements those virtual methods according to it's intended function. Two short sentences but there really is a lot of stuff said between them. Check out the above link to see a diagram.

[subheading]My problem[/subheading]

Yes I know... I know I have more than one and not all of them are psychological. Seriously though. When I first started making games I tried keeping track of all of my states using enumerations and switch/case blocks to handle them. This works great! For very small programs with very few states. Now take you average small game, like a tetris clone for example. Off the top of my head I can think of about 14 different states for the game as follows:

  • New Game
  • Game Active
  • Game Over
  • Title Screen
  • Load Images
  • Load Sounds
  • Load Cut Scenes
  • Intro
  • Level Completed
  • Level Loading
  • Level Clearing
  • Display High Scores
  • Instructions
  • Enter Initials for High Score
    So this is for a very basic game. Each of these game states needs to be handled differently. You are going to want to handle input, rendering and game updating differently for each state. Think about this... A switch/case block to handle rendering 14 different states. A switch/case block to handle updating 14 different states. A switch/case block to handle input for 14 different states. That just sounds messy thinking about it. That is okay. I am not going to post any code from some ancient project show casing this. But that was how I used to do it.

    Remember when I asked what three things almost all interactive software have in common? They all do these three things:

    1. Handle input according to the current state
    2. Update the software model according to input and state
    3. Render information to the screen according to the input and current state

    And you know what. Every piece of software does this for every pass through the main loop. I can also bet that you saw the one reoccurring theme in those three things. The word state (I know. I made them bold font). The point is this is one of the most perfect candidates for the state pattern. We can use abstraction to make a template that will handle the functions and concrete classes of that template to encapsulate the functions for each separate state.

    So what does this look like?

    [subheading]The Game State[/subheading]

    #pragma once

    class GameState{


    virtual void HandleInput(void) = 0;
    virtual void Update(void) = 0;
    virtual void Render(void) = 0;
    virtual void onEnter(void) = 0;
    virtual void onExit(void) = 0;

    virtual ~GameState(void){};


    So there are a few things here that I didn't mention to begin with. OnEnter and OnExit. More than likely you will find that as you change states within your game there are specific tasks that need to be performed when you enter or leave any one state. Maybe loading media assets upon entering a state and releasing them just as you exit the state? Depends on your state and it's function, but they will come in handy.

    So the header for a concrete game state would look something like:

    #pragma once
    #include "GameState.h"
    #include "Game.h"

    class stateINTRO :
    public GameState
    stateINTRO(Game *g);

    void HandleInput(void);
    void Update(void);
    void Render(void);

    void onEnter(void);
    void onExit(void);

    Game *game;
    bool completed;


    Pretty simple now you can handle input, update your game model and render independently for each game state. Just to give you an idea of how this simplifies the main game loop here is the main.cpp from bash.

    #include "SDL.h"
    #include "Game.h"

    int main( int argc, char* args[] )
    //Try to create a new game
    Game *bash = new Game();

    //Check to make sure the game systems initialized correctly

    //While the game is not requesting to quit run the game




    //Clean-up the memory used by the game
    delete bash;

    return 0;

    So yes there is a lot more crap stuffed into the game object. BUT the game object is the game engine. It only provides services like managers for input, audio and graphics. It also provides functions that span across many different states. This in itself makes the game engine a bit more reusable and flexible. Meaning the engine is not the game.

    So the interface to the game states in the game engine it could look something like:

    void Game::HandleInput(void){

    //Always handle the user trying to quit the game
    this->ExitRequested = true;

    //Let the current state handle the other input

    void Game::Update(void){
    //Update the keyboard so the current state doesn't have to
    //Update the gamepad
    //Allow the current state to chose what systems to update

    void Game::Render(void){

    //clear the drawing surface
    SDL_FillRect( this->screen, NULL, GColor::BLACK);

    //Let the current state draw what it needs to

    //Update Screen
    SDL_Flip( this->screen );


    void Game::SetState(GameState *s){
    this->currentState = s;

    [subheading]Pro's and Con's[/subheading]

    That about sums of the majority of the game state, or at least my current implementation. But as with all design patterns there are drawbacks associated with them.

    What are they?

    Class Explosion
    The major problem with this pattern is that EVERY SINGLE STATE requires a new class. Ouch. That can get pretty messy. You are basically trading a messy class for a mess of classes. With proper naming conventions this will help mitigate the organization problem. But it also makes it hard to see the design as a whole without creating a diagram of the state machine. BTW I recommend doing this even if it is just on paper.

    Brittle Interface
    Yep it's true. Without proper foresight in your design this pattern can muck things up quick. Why? Because if you need to add another interface in the pure virtual class you need to add it to EVERY concrete class. This is also why I recommend putting a design on paper or in UML prior to tearing into it. That being said I think as far as the game state goes, it doesn't get much more basic than what I presented.

    So the pro's! What are the good things about this and why is it even worth making a metric ton of classes?

    Harder to Break
    It is harder, though not impossible, to break any other state by making changes to any single state using this pattern. You have encapsulated your functionality and cannot muck about with any other state.

    Really big plus here. This pattern forces the programmer to design to an interface. Meaning since you only have 3 functions you need to interface to the game as a whole you can have multiple programmers working on separate states all at the same time and not have to worry about them breaking another state.

    Although it is hard to see the whole picture it is doable. It is very very hard to look at one single class that handles every single state of input, logic and rendering. Piecing those bits into one manageable whole is harder than being able to look at one file for one state and knowing what it does.

    [subheading]No Silver Bullet[/subheading]

    This is no silver bullet. This is not the thing you want to use all over your program unless you are prepared to deal with the negative aspects of this little devil. But it does solve some specific problems and it does it well enough in my opinion.

    I highly recommend two books for further reading.

    Head First Design Patterns
    This book is truly awesome! It is a pleasure to read injecting humor and thoughtfulness into every chapter. This is not your typical dry stereo instructions programming book. Go buy it today.

    Design Patterns: Elements of Reusable Objects
    This is the original gang of four book that everyone mentions. It really is an excellent read and presents the topics in a well thought out manner. I would recommend reading this book after you have read Head First Design Patterns.
So for a few weeks I have been working on coloring the art for the over world map from the sketches I received from my artist. Apparently my skills with photoshop could use some serious improvement! I have put in about 20 hours so far and I think I still have at least that many to go. I am getting the effect I was looking for so I am pretty happy.

[size="3"][heading]"Time is an illusion... lunch time doubley so!" - Douglas Adams[/heading]

As is the way of it, I started doing some serious overtime at work two weeks ago( looks like it will continue for a couple more weeks too). Due to my ridiculously long commute it was easier to stay in town at my brother's place than to come home. Otherwise a 12 hour day turns into a 16 hour day. Needless to say I don't have a laptop that has any of the art programs I need to continue work. But I do have visual studio on it. So I decided to figure out a gamepad for Bash.

I have never worked with a joystick or gamepad before as this is the first platformer I have worked on. Looking around at examples of input control for SDL on the net all I seem to find is event based control systems.

[size="3"][subheading]Burn the witch![/subheading]
I don't particularly like event based control systems. Now before the pitchforks and torches are passed around and appropriate chants are agreed upon let me say that they ARE useful. Event based systems(not just keyboard or controller input) solve a fair number of problems. It just seems to me that they are a bit over-used(is it just me??) and not the best solution in every case. Being programmers we should evaluate our tools in our toolbox and pick the best one for the job and not just go along with the latest fad.

The above rant aside I figured what the hell it can't be that hard! And it really isn't! The code posted below it the result of an hour or so's work. It is not a fully fleshed controller class but it is functional enough to replicate the Super NES controller. Meaning I am more interested to know if something is being held down or just pressed. Hence the identifiers DOWN and PRESSED. Down is being actively held down. Pressed will only register 1 time when it is pressed. It won't register a press until it is released and held down again.

SDL Controller


#pragma once
#include "button.h"
#include "SDL.h"
#include "vector2d.h"

using namespace std;

class gamepad

string name;
bool available;
int availableButtons;
int availableHats;

vector2d axis, axis_old;
int hat, hat_old;
float threshold;


void init(void);
void update(void);

void addButton(string name, int number);
void setButton(string name, int newNumber);

bool isButtonDown(string name);
bool isButtonPressed(string name);

bool stickUp(void);
bool stickDown(void);
bool stickLeft(void);
bool stickRight(void);

bool stickPressedUp(void);
bool stickPressedDown(void);
bool stickPressedLeft(void);
bool stickPressedRight(void);

bool hatUp(void);
bool hatDown(void);
bool hatLeft(void);
bool hatRight(void);

bool hatPressedUp(void);
bool hatPressedDown(void);
bool hatPressedLeft(void);
bool hatPressedRight(void);

bool state(int num);



I suppose I will start this off with a bit of information about myself and my current project. I have been programming in some form or another for over 15 years. Either professionally or as a hobby. I have always been working on some sort of game, I suspect as most hobbyists, never completing all of my projects. While working on my AS degree for electrical engineering I got a job as a software developer and decided to skip the rest of a 4 year degree to work doing what I loved at a start up company. Long story short, a few years later the start up tanked. I spent a few years trying to get stable then decided to finish my electrical engineering degree and work with one of my other passions.

Now all of this is leading into the current project BASH. I had the idea of creating a parody game about pokemon about 7 years ago when my oldest son was really getting into them. Unfortunately keeping up the GPA(~30 hours a week) and working 40 hours a week and having a family left zero time to complete this project. In January of 2011 I decided it was time to resurrect this idea I had and finish it.

At the time I was using C++ and the PTK library to do the graphics, sound and input. I did some research before starting the project back up and decided to use SDL. I gave myself 6 months to get the game done and assumed I should be done by July of 2011....

Anyway I think that is a good preface to the current project. More to come later.
Sign in to follow this  
  • Advertisement