Game Dev Diary – Part 2 – Living with Chaos

Living with Chaos

Hey guys Nemo here. Last week in our Game Dev Diary blog I went into the importance of having a game design document and gave a concise version of my design document of ‘Delirium’ a top down sci-fi action game set in a spaceship with a variety of bosses. You can scroll down to read up on it if you missed out on last week’s blog. With a readable, understandable and detailed document in my hands it was time to develop. This week was all about coding the game.

One Game Engine to rule them all.

Over the past 4 years, I have come across and have used a number of Game engines; Games engines that are free such as Unreal Engine 3, Game Maker Studio, Flash + Flixel and Unity3D. There has been a great debate on the internet and between my colleagues about which Game engine is the best. Many have argued that Unity3D is the one to rule them all. However I have found that Unreal Engine was a brilliant for developing games that were first person shooters. Game Maker Studio excelled in 2D pixel perfect games. Flash was efficient at vector art based games. And Lastly Unity3D which was the jack of all trades when it comes to Game engines. It’s not the greatest engine for a first person shooter game, nor was it the greatest for 2D pixel perfect and vectors games. They all had their own pros and cons. The point here I want to make is:

“There is no one Game engine to rule them all.”


When I choose a Game engine for a project, it boils down to two things:

  1. Familiarity
    – Learning how to use a new Game engine isn’t hard, but it is time consuming. Time is something you cannot obtained back. There is little point in learning a new engine or language just to obtain the same result. Use an engine that you are most familiar with.
  2. Situational
    – Sometimes it’s better to choose a Game engine depending on your needs. If you are trying to make a precise first person shooter, its wiser to choose an engine that already has it built in like Unreal Engine rather than having to code the system from scratch to your own engine. Sometimes, the engine your familiar with might not have the functionalities that you want your game to have. An example of this would be trying to make a 3D game on Game Maker. There’s going to be a 98.9% failure rate.

Just choose one, and stick with it. Or you could make your own engine.

Chaos Manager

I chose to use Unity3D for this project as I have made many of my games on it and have become accustomed to it. One major problem that I have found using Unity3D was the sheer amount of chaos it can produce. Unity handles the main game loop logic(mentioned previously here) for you behind the scenes which can have nasty side-effect; It becomes extremely difficult trying to control the flow of the game loop. Without this control, you are no longer able to exactly know when each individual objects call their respective functions, they become independent. Not only that, it becomes much harder when looking back into your old projects. You or any new members to your project trying to understand your project will not know where the program begins. It makes it difficult to implement new functionalities/features to the project without having to go through every single objects in the game. This is the Chaos. So how do we control this Chaos?


This is where the Chaos Manager comes in, it is also commonly known as the Game Manager. So what is the Game Manager exactly?

  • Instantiated once
  • Handles game states and controls the flow of the game
  • Saves persistent data


Singleton Pattern

A Game Manager is designed to be a singleton pattern. Singleton pattern makes sure that there is only one instance of Game Manager allowed at any given point in time. We only ever want one instance of game manger in the game scene so that it can control the flow of the game. I won’t be going into the details of what a singleton is as it is explained much better here.

There are many ways of implementing a singleton design. The general Pseudo code would be:

if  uniqueinstance_gameManager is NULL
then create the gameManager
return uniqueinstance_gameManager;

Game States

Every game has game states : Start -> Play -> Pause -> Die -> Game Over, etc. Game Managers hold information on game states. By holding onto this information, game states allows us to control the flow of the game. Each state lets the game manager to know what game Objects to instantiate at what time. This allows for neater organisation of code, and makes it easier to identify where the game beings and ends.

These data are usually stored as a enum, accompanied by a handler and a getter/setter.

public enum GameState { START, MAIN_HUB, BOSS_ROOM, CREDITS };

public delegate void OnStateChangeHandler();

public GameState gameState {get; private set;}

Persistent Data

Since game Managers have a singleton design it allows us to have access to be persistent data. Data that will not disappear throughout different scenes of the game. This allows for some awesome things to happen. With persistent data, you are able to save player information, carry their stats, weapon of choice, last location, death counts over to different scenes. I shall talk more about this next week.

So Far

  • Implemented GameManager and state controllers
  • Implemented new rooms and scenes
  • Sweet camera panning between rooms
  • Updated movement and weapon system
  • Working on AI implementation of first boss

oqOxXR4 oc945Fc


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s