2D Games Formats – Side-scrolling

You can find this game slice here

The theme of the game slice was inspired by jetpac on the Z X Spectrum. In Jetpac you must pick up fuel cells that fall from the sky and carry them one-by-one to your ship, which you must also construct. Enemies fly across the screen, and you must dodge them or lose a life. The key elements of the game I wanted to use were collecting fuel to take off, and different level platforms on which the fuel cells can be.

During the creation of this game slice, I encountered several different stumbling blocks at various stages, each with their own set of problems and solutions. From the list of recommended features, I managed to achieve:

  • Movement, collision and physics
  • Using Tiled for level design
  • Scaling, camera management and parallax scrolling
  • Background audio and sound effects
  • Collectables
  • Spritesheet animations

The first task that I completed was using Tiled to create the level design. I have used the software in the past while performing work experience in industry, so I was excited to have an opportunity to use it to create my own game. I created two foreground, collision, parallax and two background layers. By doubling up on foreground and background layers, I could create extra depth with my level design.

I then exported my tiled level to a JSON file so that it could be read by Phaser, however, when I was creating the level I forgot to embed the tileset. This resulted in a rather long headache of trying to figure out how to do so, before realising it was a tiny button in the bottom right corner of the screen. On the positive side, I know to immediately embed my tileset before beginning any level designs in the future.

The next error that I encountered was that my collision set-up function was not working correctly. After going over my code by talking through it at my debugging buddy (a stuffed alligator) I discovered that I had forgotten to use the .call method when invoking the function.

function create_col(map) {
    var col_layer = map.getLayer("col").tilemapLayer;
    col_layer.setCollisionBetween(0, 1000);

    this.physics.add.collider(player, col_layer);
    this.physics.add.collider(player, fuel_cells, pick_up_fuel);
    this.physics.add.collider(spaceship, col_layer);

This is important to use when you are creating your own functions outside of the main Phaser ones of preload, create and update. Once I changed how I called the function, I made significant progress. In the same coding session, I managed to add music, collectables and player movement.

The last features that I added to the game were scaling and resizing the game window, as well as vertical parallax scrolling. To add parallax to the game, you need to use the setScrollFactor method to set the x and y scroll factors. A scroll factor of 1 means that the layer doesn’t scroll in that direction.

map.createStaticLayer("para", alien_world, 0, 0).setScrollFactor(1, -0.2);

In working on this game slice, I pulled together several different techniques that we had covered that I am interested in using more in the future. I particularly liked adding sound effects to the game, now my player character makes a sound when jumping and picking up a collectable. If I were to continue with this project, I would add some enemies moving along set paths, as well as adding in the code that would allow the player to use a controller.

Introduction To Web Analytics

What Is Web Analytics?

Web analytics is a way to track how a web page is traversed and used by the people that visit it. According to Margaret Rouse, “The use of web analytics is said to enable a business to attract more visitors, retain or attract new customers for goods or services, or to increase the dollar volume each customer spends.”

Uses of Web Analytics

Web analytics is a powerful tool that can provide a variety of interesting data to web developers. The main method of identifying a single visit to a website is using a session. When the website is first accessed, a session is generated for the user. The session tracks the order in which pages are visited, where the webpage was accessed from in the world, how long the user visits the website for and where the user exits the webpage from.

Information on where your users are in the world is helpful as you can use it to guide future development such as localised versions or translations of your website. The exit page of the user (where they “bounce” from) is great for flagging whether certain pages are fulfilling users needs, or not providing the answers they want. If someone bounced from the “Contact Us” page, then you can be assured that they are more likely to have found what they were looking for. On the other hand, if the user bounces from a blog post on different types of rocks, maybe the page is simply not engaging to your audience.

Advantages of Web Analytics

Web analytics gives the developers key insights into how the users are interacting with and navigating their website. This leads to better informed development decisions, and minimises time wasted on features that no one is going to use. As web analytics is a quantitative type of data collection, this means you can use statistical analysis techniques to create summaries of your data.

How Web Analytics Can Be Used In Games

Web analytics can be applied to games through the use of event tracking. Events are triggered by the player performing a specific action, such as picking up a power-up, or completing a level. This allows developers to see where the player is getting stuck, what items they are missing and when in the game the player considers purchasing a micro-transaction. Tracking player interest in micro-transactions can be particularly important due to the money involved. Often it is used to optimise the options available to players, as it can show which bundles sell the best, and how likely a player is to make a repeat purchase.

Disadvantages of Web Analytics

In the world of social and mobile gaming, analytics are used heavily to influence game design. As a result, there are many copycat games that are difficult to tell apart from one another. Furthermore, web analytics only give you symptoms of design flaws with your game. As a developer, you may not understand why everyone is quitting after level three, unless you actually talk to someone playing the game. It may turn out that the game is extremely difficult at that point, or it is too easy and players are bored.


To use web analytics effectively, you need to combine it with other forms of data analysis, particularly qualitative methods to better explain what your event tracking is showing. Web analytics is a powerful tool for collecting huge amounts of data on what your players are doing, but it’s important to make sure that the data you gather is relevant, and can be used to improve your games in the future.


https://searchcrm.techtarget.com/definition/Web-analytics [website] [accessed: 13/12/2018]

Reflection on Analyse This

For my analysis using The 100 Principles of Game Design I wrote about the game Rogue Legacy – a rogue-like game that involves dying over and over to make incremental progress in defeating an ever-changing dungeon.

For the principles I wanted to look at in Rogue Legacy, I chose to discuss the use of a core gameplay loop and imperfect information. I chose core gameplay loop as a principle, since Rogue Legacy operates on the basis of entering a castle, exploring, dying, and continuing on as one of your three children. Some of these children have negative traits, such as near/far-sightedness or dementia, resulting in an imperfect view of your surroundings.

It was interesting to write about the core gameplay loop in Rogue Legacy, as some games with a cyclical format can become repetitive, whereas Rogue Legacy stays fresh even after playing for over an hour. The two principles work in harmony here, where the use of imperfect information keeps each cycle interesting, as you sometimes have to pick the least bad traits available, giving your attempt at the castle different challenges each time.

These principles are relevant to me as I love rogue-like games and would like to make one in the future. Furthermore, many games in this genre use these two principles so it was key to understand how they were implemented in one of the best examples of the genre.

When following The 13 Basic Principles of Gameplay Design, I wrote about They Are Billions, a zombie real-time strategy game with a steampunk apocalypse setting. I decided to use Matt Allmer’s principles as they covered all aspects of They Are Billions and how its different components work.

The most important principles for me when writing about They Are Billions were sound, anticipation and communication. These are cleverly weaved together in the design of the game, with sound acting as the unifying factor. Sound design is particularly important to me as a player, since I have been a part of two national music organisations, so I’m often keeping an ear out for interesting use of music and sound effects in games.

Anticipation is core to They Are Billions, as from the very start of the game you are anticipating a giant wave of zombies coming to attack at the end of a set period of time. This is built upon through the use of music, from the Final Wave (Build Up) theme using frantic violins to the brass section blasting out through the speakers whenever there is a wave of zombies approaching.

Finally, They Are Billions would be a far worse game without the clever way that it uses communication. In games where many things can be happening at once, ensuring the player never misses a beat is crucial, otherwise the game could feel unfair, and punishing the player for trying to complete more than one task at any given time.

These two games are very different from one another, except for one common factor of crushing difficulty. I found it interesting to analyse two games from two distinct genres, and in doing so I learnt more about how each game worked, such as the strategy game nestled inside of Rogue Legacy, and the rogue-like features of They Are Billions where if your command centre is destroyed, you have to start over again when no two maps are the same.


Despain, W. et al. (2012) 100 Principles of Game Design. San Francisco: New Riders. [book]

Allmer, M. (2009) The 13 Basic Principles of Gameplay Design. [website]

https://www.gamasutra.com/view/feature/132341/the_13_basic_principles_of_.php [accessed

Prototyping – Week 2 Testing and Reflection

This week, I finished my prototype to a playable standard, and had five people test it. Quite a few of the tasks I did this week were originally planned to be extensions, and I am pleased that I managed to move on to them. Each day I completed the tasks I had assigned myself to, some I even completed a day earlier which allowed me to get ahead on other aspects of the project:

  • (05/10) – Finish the interaction, element assumption and game over features.
  • (06/10) – Bush bonus object, level file reader.
  • (07/10) – Second level design and implementation.
  • (08/10) – Testing the game and a last minute bug fix on the second level.

Before I started testing on Thursday 08/11/18, I wrote out some objectives that I wanted to achieve through testing:

  • To see if players are capable of solving the puzzles without hints.
  • To discover if players quickly understand the core mechanics of the game and how to use them.
  • To find out if players find the game frustrating in any ways.
  • To check if the controls feel natural or if they need adjusting.

From these testing aims, I derived a key set of questions that I wanted to ask of my five testers:

  1. Did you complete both levels? If not, why?
  2. If you had to sum up the core of the game, what would you say?
  3. Were the mechanics new and engaging or had you seen it before?
  4. How easy were the controls to pick up? Would an entire game with these controls be frustrating or manageable?
  5. Was the game fun? Why?
  6. Were any parts of the game frustrating? If so, how could they be improved?
  7. Any final comments?

I had an interesting range of feedback from my testers, with some varying opinions. For example, everyone agreed the control scheme was fairly easy to pickup, but two found using elements challenging and thought hit boxes should be bigger. All the testers got a good sense of what the game was about from the prototype levels, and no one had seen environment interaction puzzles combined with controlling more than one character.

The main point that was echoed throughout was that the game would benefit greatly from some form of tutorial or a dialogue box that popped up to explain the controls to the player before the game began. I agree with this sentiment, as I had to explain the controls every time a new tester sat down, as they are not quite standard WASD.

In conclusion, I found this week beneficial to extending my project beyond what I had originally thought was feasible, which allowed me to gain better feedback from my testers as they had more to play through and compare.

Prototyping – Week 1 Reflective Journal

During this week of the prototyping project, I completed all the tasks that I had assigned to myself for this week. These were:

  • (30/10) To create a basic level design on paper and a production plan.
  • (30/10) To create basic shapes to represent the Tyler and Mike characters that meant it was easy to identify which character was which.
  • (31/10) To implement the mechanic that allows you to switch between each character.
  • (01/11) To get Mike’s movement working as he had a smaller range of movement.
  • (02/11) As Tyler’s movement was more complex involving a jetpack-style jump motion I gave myself an extra day to do it.
  • (04/11) Write up the production diary for the week and write a reflective journal.


I used Asana to organise myself during this project. It is an online team organisation service, and I have used it in the past for both long and short-term projects. It has a board format that I used to create tasks, and then assign them deadlines to give myself a timeline.


I decided to do my initial designs for the level on paper, to allow myself to create a few iterations of the design quickly. After deciding on the final layout, I created a 10×10 grid on the page to make a tile accurate level design to be used when creating my tile and collision maps later. I created two main level ideas, labelled 1 and 2, for which I created a series of steps that the player might follow to solve the level’s puzzle. This was so that I could ensure it was fairly easy to follow how to solve the puzzle, as if it was unsolvable, the game would not be fun.

I struggled a little with the jetpack jump initially, however, I decided to implement all of my movement differently, allowing the jetpack to feel smoother and cohesive with how the player moves side to side. The switch character mechanic was surprisingly easy to implement, and gave me extra time to work on other aspects of the project on the day it was assigned. I used a string which would be checked if it read “Tyler” or “Mike” when key press checks were being performed and other character-dependent actions.

Overall, I have made good progress on the project this past week, and I am happy with what I have achieved so far in the time. I believe I could have assigned more tasks to the first week, however I did fall ill at one point and lost time there, so it worked out that I had given myself less tasks as I had less time than originally anticipated.


Prototyping Project – Production Diary

My prototype is for a 2D platformer game where you play as a robot (Tyler) and its’ inventor (Mike). Tyler has the ability to take on properties of objects which allows him to remove obstacles from Mike’s path to the end of the level.


Today I worked on the character sprites, the initial level design, and the movement/switch functions. I got some basic boxes in to represent the characters, and on paper I created a sketch of how I want the level to look, and what obstacles the player may encounter. Tomorrow I will continue on the switch function.
Currently, it changes the value in the switch function, and where it is called from, but not globally, which is a major issue. The movement left and right for Tyler is effective, but I’ve been unable to test it for Mike so far.


Despite being ill today, I completed the implementation of the character switch function, allowing me to test the movement for Mike. The reason why it wasn’t working yesterday was that I had used a single equals sign in an if statement, where instead I needed to use 2.


Today I found a tile sheet map to use for my platforms that was freely available online at:
I also began work on the jump function for Tyler. I have got him moving up and back down again when you press the jump key, but it happens so quickly that you can’t see it, however, I still have tomorrow before his movement needs to be complete.


Using a branch on Github, I restarted work on the jump function for the robot today. I mostly scrapped what I did in terms of physics yesterday, and started over through implementing gravity to ensure the player would fall to a platform. This meant I also had to edit the second character’s movement, but it was quick and easy to update.


Today I implemented my level design I had done on paper earlier in the week and I worked on collision detection for the platforms throughout the level. It’s not quite working yet, but I have planned for it to be completed it for tomorrow.


I got lots done today in the computer lab before my afternoon session and during it. I implemented the lava, well and exit objects. I also made it so that the lava can be turned to stone when Tyler is carrying water. I started working on the bush game bonus, but I didn’t quite get to finish it. Finally, I created a game over state for if Mike fell into lava and a game won state for if Mike reached the exit.


I have completed a reflective journal entry on the first week of this project, which can be found here.

I also completed the bush bonus object, so that you can water it to make it grow or burn it down using lava. Once I completed that, I created a level reader that took in an array of numbers from a file and stored them in the map and collision_map arrays to allow new levels to be loaded and played.


On paper I started designing a second level for the game, then I transferred it into two txt files to be read from by the game. Finally, I tweaked a few functions so that they were compatible with different level layouts, such as filling out the collision function. This needed to be done as I had only set up specific cases for the function, rather than fleshing it out completely to work for all cases.


In our session today we tested out each other’s prototypes, and I gained valuable feedback on my game which I will use in my write-up.

Wireframes for Mech Builders

Mech Builders is puzzle game where you unlock mech parts to build a fighting robot with which to crush your enemies! At the start of the game, you are shown the power level and stats of the mech you will be battling against, before being taken to a puzzle select screen. If you are successful in beating the puzzle you gain a new part to use for your mech. However, you can choose to try a harder version of the same puzzle to have a chance of receiving an upgraded part. If you opt to do so, and fail to complete the puzzle, then you will lose the part you chose to risk.

Once you have completed all the possible levels for the mech match, the two mechs will fight each other until one of them falls apart and loses. To progress in the game you have to build bigger and better mechs, defeating powerful foes along your way to dominance.

My initial sketches

I initially designed my wireframes on paper, so I could get my first ideas down to be iterated upon. Then, I moved into Axure to create digital wireframes of each of the five screens.

Title Screen

The first screen I created was the title screen. I kept all the key buttons the player would need in the centre of the screen. By surrounding those buttons with cogs on either side and an image of a selection of mechs in the game at the bottom, I can draw the eye into the middle of the screen, making the menu options easy to find.

Enemy Mech Stats

Once the player has opted to start a new level, they are shown the stats of the enemy that they are going to be attempting to defeat. They can view this screen any time from the pause menu, so that players do not need to memorise a lot of information as they play. On the left, there will be an image of the mech in its signature pose, ready for battle. The same image will be used later in the mech comparison screen, to give the game consistency. On the right, there will be a slowly rotating model of the mech, giving the player a 360 view of what the mech looks like. I put the challenge them button at the bottom of the screen to encourage the player to at least skim-read the enemy stats before starting the level.

Puzzle Selection

After the player has hit challenge them on the enemy mech stats screen, they will be taken to the pick a puzzle screen. The exact number of puzzles that the players will be able to choose from is currently unknown, however it could change based on how far through the game the player is. When they are facing more challenging mechs, they will have less puzzles to choose from so they have to be more careful when it comes to risking components.

Each image for a puzzle will give a vague hint as to the type of puzzle it is, as well as what component you are likely to get from completing the puzzle. I gave the player the option of viewing their mech and the enemy mech at the bottom of the screen so that they have a better understanding of which parts they still need to collect or if they have one of each part, which ones they should try another puzzle for to get a better version.

Use It or Risk It

This screen is shown to the player each time they successfully complete a puzzle. On the left, the enemy mech is shown to keep the layout consistent, as in other comparison screens the enemy is also shown to the left. Players have the option to either read a detailed description of each components with their strengths and weaknesses, or they can quickly glance at the overall component ratings given underneath the picture of each part. I made the use it and risk it buttons bold and large on the screen, to draw the player’s attention to the decision that they have to make before they can continue.

Mech Comparison

The mech comparison screen is shown to the player right before the mechs go head to head in battle. It gives a detailed description of each mech, as well as a bar chart which gives a direct comparison of specific key stats that will show which way the battle may swing. The placeholder on the left is the same posed image of the enemy mech that the player is shown on the enemy mech stats screen. The placeholder on the right serves a similar function for the player created mech, except the pose is generated based on the overall rating of the mech so that weak mechs will pose in ways that makes them look delicate whereas high-tier mechs will pose like a stereo-typical wrestler.


I found working out a basic layout idea on paper was beneficial to my overall designs as it allowed me to get my initial ideas out to be refined further. This is useful particularly if you want to iterate upon your sketches before moving onto the wireframing stage. Wireframes are useful as they allow you to see how the game will flow between screens and identify how large different elements have to be on the screen to make them usable.

From this wireframing project, I have learnt how to use Axure to create pixel accurate wireframes. I have also spent time considering how layouts can change based on platforms, as well as how much information you can fit on a single screen based on the size of that screen.

Reflection on Car Project

You can find this project here

For the past week, we have been working in pairs to create a simple car mini-game using Javascript. Initially, we programmed in movement functions and a cross-hair pattern before moving on to more advanced features.

The first change we made was creating a car object, to make the code easier to read and to clean up the code base. As we added new features to the game, such as collision detection, we needed to add more properties and methods to the object. The second feature we implemented was quadrant detection, where different sections of the canvas would change colour when you entered them, along with changing the image of the car. While Zoe cleaned up the image, I began creating the basic if statements for the quadrant detection before we came back together to tackle the rest of the code work together.

function get_car_quadrant() {
    context.fillStyle = "#58c8a9";      //colour of border
    if (car.x < canvas.width / 2) {
        if (car.y > canvas.height / 2) {
            //bottom left           
            context.fillRect(0, canvas.height / 2, canvas.width / 2, canvas.height);     //create a filled rectangle
        } else {
            //top left
            context.fillRect(0, 0, canvas.width / 2, canvas.height / 2);
    } else {
        if (car.y > canvas.height / 2) {
            //bottom right
            context.fillRect(canvas.width / 2, canvas.height / 2, canvas.width, canvas.height);
        } else {
            //top right
            context.fillRect(canvas.width / 2, 0, canvas.width, canvas.height / 2);

This worked by checking if the car was in various quadrants using if statements comparing the x and y values to the width and height properties of the canvas. We then created filled rectangles the size of the quadrants to make it appear as if they lit up when the car was in them.

The next feature we added was acceleration and deceleration. When you press the same key more than once in a row, the car will speed up. If you change keys, the car will move off at a slower pace. We didn’t get the car to slow to a stop, but we are otherwise happy with our use of basic acceleration and deceleration.

In the car object, we stored the following properties:

  • x and y co-ordinates as well as x & y speed (dx, dy)
  • speed and angle of travel
  • width and height of car
  • 4 flags for if the car is at the edges of the canvas
  • the co-ordinates of the corners of the car in a two-dimensional array.

We also gave the car object two methods:

  • corner update that calculates the current position of the car’s four corners
  • detect collision which resets the collision flags before detecting if the car is at the edge of the canvas on any side.

    corner_update: function () {
        car.corners[0] = [car.x, car.y];
        car.corners[1] = [car.x + car.width, car.y];
        car.corners[2] = [car.x, car.y + car.height];
        car.corners[3] = [car.x + car.width, car.y + car.height];
    detect_collision: function () {
        this.blocked_left = this.blocked_right = this.blocked_up = this.blocked_down = false;
        var corner = [];
        for (i = 0; i < 4; i++) {
            corner = this.corners[i];
            if (corner[0] <= 50) { //left side this.blocked_left = true; } else if (corner[0] >= canvas.width) {
                this.blocked_right = true;
            if (corner[1] <= 50) { this.blocked_up = true; } else if (corner[1] >= canvas.height) {
                this.blocked_down = true;

These methods were the last code sections we added to the game, as the collision detection was the last feature we added. We decided on corner based collision detection, as we felt it was the most accurate method of keeping the car from going off the edge of the map. By creating methods rather than functions, we kept relevant code inside of car object, making our code easier to understand.

From this project, I have learnt how to use corner-based collision detection, as well as how to implement more advanced movement methods involving angles. I enjoyed working with Zoe, and we successfully split the workload as well as bouncing ideas off of each other.

Reflection on Snake Game

You can find this project here

During the snake game project, I have used a few programming techniques introduced in the bouncing ball animation as well as some new ones. Here is a list of the new techniques shown during this project:

  • Methods of objects
  • helper vs control functions
  • taking key press inputs
  • taking touchscreen inputs

When creating an object, it can have properties and methods. Properties are values and methods are functions of the object. These can be called using ObjectName.Property or ObjectName.Method() and are useful for encapsulating values.

function create_snake() {
    var new_snek = {
        colour: generate_hex(),
        x: grid * 2,
        y: grid * 2,
        dx: grid,
        dy: 0,
        cells: [],
        max_cells: 4,
        move_left: function () {
            if (this.dx === 0) {
                this.dx = - grid;
                this.dy = 0;
        move_right: function () {
            if (this.dx === 0) {
                snake.dx = grid;
                snake.dy = 0;
        move_up: function () {
            if (this.dy === 0) {
                snake.dy = -grid;
                snake.dx = 0;
        move_down: function () {
            if (this.dy === 0) {
                snake.dy = grid;
                snake.dx = 0;

    return new_snek

In this function, I create and return an object called new_snek. It has the properties:

  • colour – stores the randomly generated colour of the snake. This is used to draw the snake in the same colour every time the position of the snake is updated on-screen.
  • x – stores the current x co-ordinate of the snake’s head.
  • y – stores the current y co-ordinate of the snake’s head.
  • dx – stores if the snake is moving along the x axis and if it is moving in a positive or negative direction.
  • dy – stores if the snake is moving along the y axis and if it is moving in a positive or negative direction.
  • cells – is an array that holds information about each segment of the snake’s body. Each time the snake consumes an apple, a new cell is added to the array.
  • max_cells – stores the maximum number of cells the snake can have. When the snake reaches this point, each time it eats an apple it loses a cell to keep it’s size consistent.

To allow my snakes and apples to have random colours, I directly copied my generate_hex function from the bouncing ball animation. I chose to have random snake colours as I felt it would be easier for players to determined that they died and are starting over once more with a new snake. I made the apples random colours to keep things visually interesting.

The object new_snek also has the following methods:

  • move_left
  • move_right
  • move_up
  • move_down

These methods allow you to directly move the snake object in 4 different directions as long as you weren’t previously moving along the same axis. These are called by event listeners that are detecting arrow/WASD key presses or touch inputs.

function add_listeners() {
    var start_x, start_y, distance_x, distance_y;

    document.addEventListener("keydown", function (e) {
        //left (A) 65 | right (D) 68 | up (W) 87 | down (S) 83
        if (e.keyCode == 65 || e.keyCode == 37) {
        } else if (e.keyCode == 68 || e.keyCode == 39) {
        } else if (e.keyCode == 87 || e.keyCode == 38) {
        } else if (e.keyCode == 83 || e.keyCode == 40) {
    document.addEventListener("touchstart", function (e) {
        var touch = e.changedTouches[0];
        start_x = Math.round(touch.clientX);
        start_y = Math.round(touch.clientY);
    }, { passive: false });
    document.addEventListener("touchmove", function (e) {

    }, { passive: false });
    document.addEventListener("touchend", function (e) {
        var touch = e.changedTouches[0];
        distance_x = Math.round(touch.clientX) - start_x;
        distance_y = Math.round(touch.clientY) - start_y;
        if (Math.abs(distance_x) > Math.abs(distance_y)) {
            if (distance_x > 0) {
            } else if (distance_x < 0) {
        } else {
            if (distance_y > 0) {
            } else if (distance_y < 0) {
    }, { passive: false });

I use the OR || operator to allow the user to control the snake using WASD or the arrow keys at any time depending on their personal preference. This gave my game additional flexibility as some players would default to WASD while others find the arrow keys easier to use.

By calculating the distance between the beginning and end of a touch event, I can determine which direction the player swiped in. This allows me to then call the appropriate move property of the snake using nested if statements.

The key techniques that I learnt during this project were how to detect key presses and touch input. I can use these in future web-based game projects to ensure that the game is playable across multiple platforms. I found creating objects without using a class an unusual experience, as the way I learnt OOP was using a stricter language where to create an object you had to have created a class.

They Are Billions and The 13 Basic Principles of Gameplay Design

They Are Billions is a strategy game where you must survive the zombie apocalypse and build up defences to protect your fledgling city. However, at the end of the match, an enormous horde of zombies will rush to your city, doing whatever they can to destroy it.

The 13 Basic Principles of Gameplay Design were created by Matt Allmer in 2009 based on the 12 Principles of Animation that he had learnt about at college. I will be using these as a framework to analyse They Are Billions.



Focal Point

The focal point of the game is defending your Command Centre from attack by the zombies. To do so effectively, players must build up their colony in size and resources. The expansion of the colony is a secondary objective in the game while defending your colony is the main focus of your activities. To unlock new defensive structures and troops, players must gather resources, while building research facilities and troop recruitment methods.


Each time you play the game, you choose how many days a particular run should last. Each run can last between eighty and one hundred and fifty days. At the end of this period of time, the final horde will attack. Throughout the entire course of the game, the player is anticipating the all-out-assault from the zombies at the end, shaping the way the player builds their colony and which troops they train.

Another way they are billions uses anticipation is by having each troop have two stances. One is on standby/navigating the map while the other is primed to attack. This way, the player can tell when their troops are ready to immediately attack, and when they are waiting to be told to attack or are in the midst of following a move or patrol order.

Announce Change

The map is filled with stray zombies which are attracted to human troops and structures by noise. Occasionally, they will wander towards your colony and attack. Separate from this, are zombie waves. These are announced to the player whenever there will be an attack along with what direction the attack will be from. The player is then given eight in-game hours to prepare their defences in the given direction before the horde makes its way through the map, picking up a few stray zombies along the way.



Believable Events and Behaviour

As you are exploring the map in They Are Billions, you will encounter zombie villages, old settlements that are overrun with zombies. These will continually spawn zombies to come and attack your colony, so it is key to take them out. Whenever you attack a building in a zombie town, more zombies will come flooding out of the building you are attacking and nearby ones to defend the town from attack. This forces the player to split their troops up and have some attack the buildings while others defend them.

This is an example of believable behaviour since when people’s homes or towns are under attack, they will attempt to defend themselves and others. Another way the game incorporates believable behaviour is when a colonist comes near to a zombie, they will run in any direction away from it screaming, as anyone would probably do.

Overlapping Events and Behaviour

Sometimes, smaller unannounced waves of zombies will attack your defences, at the points the game deems are the weakest. These are random, and come without warning from any direction, resulting in the player have to fight fire on multiple fronts.

When troops fight and kill zombies, their veteran percentage increases. Once it reaches 100% they upgrade, gaining higher damage, health and/or rate of fire stats. When playing the game, you can use this to your advantage by making death squads to run around killing zombies to become veterans or by posting new recruits on busy walls where zombies like to attack.

Sniper veteran and other stats


Since the game is in 2.5d, it doesn’t use basic physics such as gravity or drag. However, physics are implemented through the energy mechanic and the rate of fire of various troops and buildings. To expand your colony further, you must spread energy connections out beyond your base using Tesla towers. These bring more squares under your sphere of influence and are key to keeping all your defences running, as without energy any building defences shut down.

Another way energy is used is through shocking towers. These deal massive Area of Effect damage, but require a recharge time. This is cleverly shown through the coils around the top of the tower lighting up one after another. When the charge is fired sparks of energy shoot out of the tower. Other building defences also have delayed rate of fire and speed of missiles. For example, great ballistas have a medium rate of fire, but a slow travel time as they are giant mounted cross-bows. On the other hand, the upgraded versions of great ballistas – known as executors – have an extremely high rate of fire and fast travel time as they are automated gun towers.


Sound plays a vital role in They Are Billions to build the world around the player, to engage them in their surroundings and to create tension during critical events. Each of the 4 maps have their own environment sounds, to give each their own atmosphere. If you zoom into different aspects of the environment, each has their own sounds layered into the atmospheric noise. For example, if you zoom into a river or lake, the sound of running water is added to the background noise. I believe that Numantian Games spent a long time on the sound to ensure that the game felt fleshed out, and to help push across the steam punk setting of the game.

Whenever an action is completed for the colony, such as a troop is trained or a building is built, there is a short beep followed by an audio prompt of what has happened. This also occurs for attacks, and is useful for signalling events to the player when they may be focussing on something happening on the other side of the map. Without this feature, players may miss attacks, important buildings completions, and being able to organise their troops effectively.

Each type of building in the game has its own sound which is played when you click on it. This provides the player with information on what type of building they are interacting with, as well as giving the buildings life. For example, you can hear shouting from the Soldier’s Centre, laughter from the Inn and electricity zapping through Tesla Towers.

On top of each building having unique sounds, each zombie and troop type have their own voice lines, ranging from different pitched growls, to questions about when troops are going to be paid. This is the only time I feel the sound design could be detrimental to the game as the repeating voice lines from troops can become grating when you are fine-tuning their movement to route zombies a specific way. The troops voices still have use though, as when you select a group of troops, the most commonly selected troops voice line will play, giving the player a quick idea as to the make-up of the team especially if they check the icons displayed at the bottom of the screen.

Finally, the best way that They Are Billions uses sound is in the games music. Each piece in the soundtrack was recorded with the Bratislava Symphony Orchestra, giving the music a fullness which is often lost in games where digital instrument samples are used instead. The composer Nicolas Diteriks did an excellent job in creating a sense of looming danger and excitement through the music, and much of the game’s atmosphere and world-building would be lost without his booming score. The main theme is epic, using dissonance and rising chords through the brass section to create a feeling of impending doom before melting into softer strings to show hope that you may yet defeat the endless hordes. All the while, the percussionists hammer out a war beating, bringing a sense of the battle to come.

The build up to the end game is tense, with strings oscillating back and forth, trying to put your nerves on edge as you desperately prepare your final lines of defenses before the Final Swarm Theme crashes in. The way Diteriks used the brass to create scale and a sense of power gives me goosebumps whenever this theme begins. I have a personal passion for classical music, and seeing it utilised so effectively in an independent game shows how sound is crucial in creating a game that feels full of life.



They Are Billions has an interesting approach to pacing. As you can pause the game at any time, the player can take a breath and think about their next decision, in spite of their impending doom. When there are no zombies attacking, the game feels relaxed and slow, trying to lull you into a false sense of peace and security. As soon as zombies begin pounding at your defences, the game instantly feels faster. No matter the size of the zombies attack, every action you take has a sense of urgency, even if it is an unrelated building project on the other side of your colony. This is further added to through the games use of sound, and the way the brass section soars during an announced wave to inform you of the imminent danger.




As the game is in 2.5d, the developers have used a grid format to dictate where players can build, the sizes of objects, and to display areas from which buildings are taking resources from – this is key as buildings of the same type cannot draw resources from an overlapping area.

Walls are a key part of They Are Billions as they allow you to create layers of defences and minimize casualties when a zombie makes it past your outer-most defences; however there is a 2 layer limit to any wall that you build. If you attempt to build a wall 3 layers thick, the game blocks this action. I believe the game developers introduced this to prevent players from building incredibly thick walls to simply delay the zombies in one part of the map forever while they deal with an invasion elsewhere.

In They Are Billions, there are 4 possible maps, each with their individual terrain and challenges. Every map plays differently, and there are positives and negatives to each differing environment. By giving each map specific attributes, the developers can play around with the spacing of resources and obstacles to keep the game fresh as the player’s skill level increases. The maps are as follows:

  • The Dark Moorland – this map is unlocked at the start of the game, and has lots of terrain obstacles such as lakes, rivers and mesas which minimises free building space. While this can make organising your colony more challenging, it does allow for fantastic defence layering.
  • The Peaceful Lowlands – compared to The Dark Moorland, this map has a lot more building space, but is covered in sand making it difficult to build farms – a key food resource for many colonies. By changing the ground type in a lot of areas, the developers force the player to think strategically when building their colony.
  • The Frozen Highlands – the developers cleverly interpreted the theme of coldness in this map, by making all units move roughly 20% slower. This changes how easy it is for you to mobilise units to an area of you colony that is under attack and makes it feel like walls are infinitely further apart as you watch your troops trek through the snow and ice.
  • The Desolated Wasteland – the final map of the game is by far the most challenging. The map is overall open, but it has a larger number of Villages of Doom – a series of infected buildings that spit out zombies over time and must be removed before the end of the game to stand a chance at surviving. Furthermore, forest areas are few and far between, as well as green fields to build farms upon. Despite the openness of the map, it is difficult to build housing areas due to the prevalence of minerals such as iron or stone, which cannot be built upon.



Linear Design or Component Breakdown

This game has many different resources which you must balance alongside defending yourself from the oncoming zombie hordes. Each resource is interlinked with the others through the buildings, as to gather more of a resource, you need to use up your supply of a different resource. For example, stone quarries require wood to build, which need sawmills to collect that need gold for the workers. These workers need food, homes of their own, and said food and homes cost more supplies. Therefore, I believe the designers of the game used the component breakdown principle when creating They Are Billions. By identifying all the major sections of the game before starting to code it, Numantian Games ensured that all parts of the game would feel connected, and that no resource, building or battle would exist in a vacuum.




In They Are Billions you are the leader of possibly one of the last pockets of civilisation in the world, which gives context to the level of power you have over the colony and your ability to fine-tune every last detail down to the exact spot a troop will walk to. Players are able to make the game as hard as they like using the population and number of days settings before they start a new game. This affects their score modifier, which can range from 7% of their points to 440%. By giving players this level of fine control, the game developers ensure that despite creating a high skill game, even players less experience can give the game a go. More experience players often restrict themselves to create gameplay challenges such as only using the weakest class of troop, or not building one type of building that makes the end game easier.

The music in They Are Billions is critical in how the game makes the player feel, and their anticipation. So much of the game is built around the idea of the enemy are on there way and that it is inevitable that you will be attacked, that the frantic energy of the music is key in keeping the player engaged during tense sections of gameplay. It builds on the atmosphere for the player, and makes the world feel fully realised.


Communication is key in They Are Billions due to the way that priorities can quickly shift for the player due to a completed building, a random attack on your colony, or an impending zombie horde. When the player reaches a population goal, a pop up will appear to allow them to select a mayor, which is accompanied by a brief change in music and a voice alert along the lines of, “a colony needs a mayor!” To ensure that players are less likely to miss events happening across the map, alerts pop-up in the top left of the screen, as well as an announcement over what has occurred. If there are lots of alerts at once, only the first alerts voice line will play, and the rest will be notified to you using a beep. These announcements commonly include:

  • “Units under attack!”
  • “Attention: building completed.”
  • “Our defences are being attacked.”
  • “The infection is spreading across the colony.”

A lot of the game’s communication is done through sound, using announcements, changes to music and various sound effects like scraping on walls to signal to the player what is happening in the game. This was a good decision by the game designers, as when you have a large colony, you may be working on multiple projects at once, and visual alerts may not have been enough on their own for many key events.

The HUD on the bottom of the screen is where a lot of the gameplay takes place for the player. There you can see all your resources, the map, date, pause/play button and buildings you currently have researched. When you have the build menu open, anything that you currently do not have the resources for is greyed out, to indicate that it is currently unavailable for building. Also, when you have completed the research for some buildings, there are often holes left in rows of buildings, showing that there are more buildings to be unlocked through advanced research tiers.


The main appeal of They Are Billions is its unique take on the Real Time Strategy (RTS) formula by creating a crushingly difficult zombie game. They Are Billions has a target audience of experienced gamers, if you are new to the RTS genre, this is not the game to start with. By making the game so that a single mistake is potentially devastating or game-ending, the developers Numantian Games clearly aim the game at fans of this genre.

Another part of They Are Billions that makes it appealing to the player is that you play as the underdog against a far superior force throughout the game. When I play the game, I love taking out zombies with careful planning and strategy. This makes defeating the random waves and the end horde incredibly satisfying as you have beaten incredible odds.


They Are Billions cleverly utilises these principles of gameplay design to create a fun yet challenging game set in a cohesive universe. While some principles were possibly under-utilised such as physics, others were key in bringing the game together. The most important principles in the making of this game were sound, announcement of change, anticipation and communication. Without all four of these principles working together, players may have missed key events while playing that could affect their current plan and change they building strategy.



Allmer, M. (2009) The 13 Basic Principles of Gameplay Design. [website]

https://www.gamasutra.com/view/feature/132341/the_13_basic_principles_of_.php [accessed

They Are Billions Wiki[website]

http://they-are-billions.wikia.com/wiki/Category:Maps [accessed 19/10/18]