Gravity Galaxy released!

After over two years of development, I have finally released my game onto iOS and Android. The release has gone pretty well, with the game being featured by Apple on the App store in a whole bunch of different regions and getting over 100,000 downloads in its first two weeks of release!


“Gravity Galaxy is a clever, interesting puzzler that will keep you plenty entertained” –

“The simple controls, slick gameplay, and reasonable IAP scheme combine to create a game I truly enjoy” -

“The game is addicting, expertly-crafted and a pleasure to play” –

More information about the game can be found at

Filthy Lucre

For the last year and half while working at Fabrik Games I have been working as part of the team on the companys debut Playstation 4 title Filthy Lucre. In September the first version of the game was released on PS4 and since then we have been working on updates and the Steam version, which will be released soon.

The game is a stealth/action hybrid with a focus on letting the player tackle missions in whatever play style they like best, with a friend in online multiplayer or by themselves in single player.

Working as part of the programming team I helped develop many areas of the game, some examples include:

  • Creation of Gear and Weapon items
  • Worked on the Trigger System used for interactions (e.g picking up items, doors, panels)
  • Networking of gameplay elements
  • User Interface

Filthy Lucre has been a great project to work on and through it I have developed skills in a lot of new areas as well as experience with the process involved with developing games for Playstation 4.

Procedural Planet Generation

Recently I have developed a technique to generate random planets, with the plan to use the generated planets in a game I am developing in Unity. The generated planets look like this:

Random Planets

These planets are created by first generating a random  spherical mesh. This is done by choosing a start position, then creating a set number of vertices around this start point at any given radius. To randomize the position of each vertex in a way to avoid overlap with neighboring vertices, the vertices are moved a random amount on the line that represents its direction from the start point. So essentially, they are either moved randomly closer or further from the start point. Once the vertices are in place they can be used to create a mesh. However I found only having one set of vertices from the center point to the radius of the planet created problems later when I was trying to use a shader to fade towards the edge. To create a mesh that I could work with more easily in a shader I repeated the first process many times, creating sub layers within the mesh that connected to each other.

Generated Mesh

UV’s for the mesh could be calculated fairly simply by comparing the vertices position to the start position. To generate the texture used on the planets I came up with a technique that makes use of Cellular Automata. The idea is to generate multiple layers of the texture, that only consisted of two colors on each layer. I devised two different Cellular Automatons rule sets that would be used. The first would try and create small isolated sections of the layer color on the texture, then switch to the second rule set that would try and grow these isolated blobs outwards. To create more diverse layers the rules were randomized in several ways, for example the number of cycles before switching rule sets is randomized, as well as the actual rules that affect how cells die and live. An example of what an individual layer looks like can be seen in the picture below:

Texture Layers

To combine the layers into one texture, each layer is added incrementally, averaging the color of each pixel in its texture with the value of the corresponding pixel already on the combined texture. The result of combining 4 layers (which is the amount used in the picture at the top of this blog) looks like the following:

Combined Texture

To create the fade effect a simple shader is used to blend the texture with the polygons color alpha, which gives the final result.

Final Result

I feel the results so far are pretty good but there is still a bit of work I would like to try and do, for example experimenting with ways to make the edge of the asteroid more apparent and possibly finding a better technique for the fade to edge that is already in place.

Procedural Dungeon Generation

Source code available here

I recently used three different techniques to generate dungeon structures. This was done as part of my final year project. All techniques were implemented with Unity and used a common procedure to produce a 3D representation of the dungeons. The full report I wrote to go with these generators can be found here

Cellular Automaton Generation

 Arguably not the best technique to use for dungeon generation, and much better suited for cavern generation, the results did give interesting shaped domains.

Binary Space Partitioning Generation

A much more common technique used to generate dungeons. Produces very uniformed shaped dungeons.

Delaunay Triangulation Generation

Based off the generation technique created by Phi Dinh for his game Tiny Keep. This techniques creates much less uniformed dungeons than the BSP technique and gives very appealing results. My implementation uses the incremental algorithm for constructing a Delaunay triangulation combined with the edge flipping technique.

Source code available here

Rage Gauge!

Rage Gauge is a mobile game developed in Unity as part of my final year team project module, take a look:

The objective of the game is to destroy as much as possible while avoiding collisions with any police obstacles.

Rage Gauge won third place for Best Game Design in the 2014 Game Republic student showcase. More information can be found on the Game Republic website.

I had many key roles in the development of the game.

Level Editor
One of my largest tasks was developing tools inside the Unity Editor that could be used to develop level segments (known as ‘chunks’) in the game, and maintain the documentation for it. The tool was designed so everything about how the levels spawns could be controlled from outside the codebase, including creating biomes (sections that only used certain chunks during that biome), creating predefined “Super Chunks” (a series of chunks that always spawn in the same order) and controlling the random creation of obstacles and collectibles on chunks, including the probability of any given obstacle spawning.

Parts of the Chunk Editor

Parts of the Chunk Editor

If you would like more detail information on how the editor works, check out the documentation which you can read here.

Game Play
I created many areas of the game play. The most important being the player Monster Truck movement and handling how it should collide with solid obstacles in a way that didn’t disrupt game play. I also worked on a few obstacles such as the Flash Bang and the Crane as well as other areas such as particle systems and the random generation of the endless level. As well I designed and created every chunk as well as all the OBS files in the demo using the Chunk Editor.

I also took a role of performance optimizing for the game looking for ways to improve the performance. I worked closely with the design team advising the use of Texture Atlases for there models, as well as general techniques to lower render calls and profiled the game looking for areas of the code base that were more intensive than necessary.

Unity Dungeon Generator

Github Repository

This week I decided to take a little break from FlyBy and work on something  fun, so I decided to try and make a BSP Dungeon Generator in Unity.

To begin with I needed to create the Binary Tree that would store the space inside it. I decided to represent the space just using Unity’s primitive cubes. Splitting a BSP Node would take the cube it stored, break it in half randomly, and create two new cubes that would be stored as its left and right children nodes. After 5 splits of the tree it resulted in this:

The level split up into sections

Each color square is a leaf of the BSP Tree

With the level now partitioned it was time to start adding rooms to each section. I decided I would create a room prefab, and make several variations of it for each possible number of exits. Then when it came time to generate the connections between rooms just change the room to the correct prefab. So I created a prefab that looked like this:

A room with 4 exits

A room with 4 exits

Then it was a case of just randomly putting these into leaf nodes on the tree. Randomizing its position and size depending on the size of space that node was holding:

Stretched room prefabs

Stretched room prefabs

And doing this cause the prefabs to get horribly stretched, making the exits a non uniform size, and look like a complete mess. At this points I re-thought my plan and decided to store everything as tiles in a grid. this would mean that each room would be made out of lots of floor and wall tiles. Although significantly more expensive, it is a much more flexible approach. After making these changes I ended up with this:

Rooms now made out of tiles

Rooms now made out of tiles

Ah, that looks much better. Now to start connecting them. I decided to go with the most simple approach possible. To begin with I connect sibling rooms, these being rooms that share the same parent node in the BSP tree. To actually connect the rooms I created a ‘Digger’ class that would move from a start position towards a target position changing the tiles it touches into floor tiles, and surrounding the tiles it creates with walls, if those tiles are empty. The Diggers movement was a very naive ‘while My_x is less than Target_X, My_x ++’ sort of affair. Ideally I would like to go back and make the ‘Digger’ use a form of path-finding to find the shortest path avoiding other rooms and such, but that is a job for another day. The results of connecting siblings looks like this:


Siblings connected to each other

Not too bad, but we do get the unideal double connecting of rooms. I fix this by checking if nodes are already connected before connecting them. At this point it is just a matter of continuing traversing up the tree connecting the rooms with parents higher up the tree, until we are back at the root of the tree. At this point the dungeon should be fully connected! Lets have a look:

A fully connected dungeon!

A fully connected dungeon!

Top down view

Top down view

That doesn’t look too bad. At this point I decided to do a few iterations of a cellular automaton to ‘clean up’ the dungeon a little. This mainly removes corner pieces to make the dungeon feel more open and remove wall pieces that are sticking out awkwardly by themselves. I am pretty pleased with these results but there are plenty of improvements that could be made. If you are interested in the code for this project check out the Github Repository.

Github Repository