'SLUGDOUGH', a silly mobile game which asks the player to cut the SLUGDOUGH into pieces to fit into holes.
I wanted to make a playful, mobile game with a consistent visual and auditory aesthetic, and a surprising amount of depth from a puzzle perspective.
How did I make SLUGDOUGH?
I started out by identifying the key development areas that would be required to make a functioning prototype possible. This includes:
Tile based pathfinding
I researched potential options for the tile based pathfinding, watching several tutorials on YouTube and considering building the system myself by scratch. I settled down on implementing a tile based pathfinding solution by Random Art Attack. Once I had this up and running, I wrote code to move an object along a path set by the algorithm. This is the core of how SLUGDOUGHS find and move along a viable path.
![]()
Random Art Attack’s Custom Movement on a Grid and Path-Finding: Unity 3D Tutorial (this is truly the worst tutorial I have ever followed but the ultimate solution is sound)
In addition to this, I built functionality for each grid square, such that it shoots a raycast upwards to detect what object is sitting above. If it is a closed cutter, or SLUGDOUGH piece, this is an impassable space and therefore not a feasible route. If it is an open cutter, it can only be passed through in the x or z plane depending on its orientation.
A desired outcome of this design is that when a SLUGDOUGH sets out, it will not set a route which pases through the existing body of its own, or another SLUGDOUGH. However, it does not update its route throughout travel and therefore can collide with a racing rival SLUGDOUGH closer to its final destination, which will result in a reset state.
Puzzle creation
I sat down with my pen and pad and noodled through all the potential types of puzzle which I could imagine for SLUGDOUGH. I then stripped it back to basics to determine how I could teach the player the mechanics involved in making more complex puzzles possible.
Abandoned ideas for new mechanics include:
![]()
Some sketches planning the early tutorial levels
On train journeys to and from Beaconsfield and during lunchtimes I'd load up a test version of the game on my phone, press it onto friends and playtest the first few levels to get an understanding of how well the tutorialisation was working. My first few iterations left players irritated.
The key to improving player enjoyment and effective feedback was in both speeding SLUGDOUGH up and adding a marker which flashes, indicating SLUGDOUGH's target. Without these changes players would violently mash the screen in an attempt to get SLUGDOUGH to move, which in itself caused another SLUG (read as bug), either resulting in the SLUGDOUGH teleporting around the screen or cutting into bizarre segments mid-path. For a game all about decapitation, too many heads were rolling here.
Character rendering along path
Next, I needed the SLUGDOUGHS to render correctly when moving along their given path. This started to get complex considering there are four different types of possible SLUGDOUGH:
Therefore I made four different types of SLUGDOUGH head object prefabs to differentiate and treat them each differently. Further, I ensured that each SLUGDOUGH piece knows the next and previous piece in the chain. This allows a search to be done up and down the length of the SLUGDOUGH to find the head and end. Finally, I wrote a script which moves the SLUGDOUGH appropriately along its path to match visual expectations. This essentially involves moving the head to the next position in the path, and the rest of the pieces to the location of the next piece in the chain.
![]()
There can be any number of different sized SLUGDOUGH on screen simultaneously
Cutting logic
The most complex part of developing SLUGDOUGH was creating the cutter logic. Less brain scratching about how I was going to do it - I knew I could use the previous/next piece logic as the character rendering system. More so, the complexity was due to the huge number of permutations of cutting different length SLUGDOUGHS.
![]()
Ready for the chop
Hole logic
I’m proud of the logic I wrote for the holes. Following the difficult time I had building the cutting logic, I sought to simplify the hole logic as much as possible. Simply: If a SLUGDOUGH is smaller than the hole, and its head and end (if it has one) is over the hole, then the level will restart. If a SLUGDOUGH is a matching length to the hole’s length, and the head and the end are over the top and bottom of the hole, the SLUGDOUGH will fall into the hole. The hole will then no longer act as hole and will be passable. If a SLUGDOUGH is longer than the hole, then the SLUGDOUGH is free to pass over the hole.
![]()
Fill all the holes to finish the level!
Soundtrack
I worked with one of the National Film and Television School’s composers, Nir Perlman, to compose the SLUGDOUGHS’ different songs; each length of SLUGDOUGH has a different song depending on whether it is moving or stationary. These layer to create an orchestra of sound. We both lent our voices for the acapella recordings. The music was implemented in game by having all the tracks playing constantly on loop, and the volume is turned on and off when appropriate, linked to which types of SLUGDOUGH are moving or stationary.
Animation
This was fairly simple to execute but slightly difficult to conceptualise. I ended up creating a child object from each head prefab which contains the rendering component, with a pivot at the bottom, and a parent which has a pivot at the centre. This ensured that the head would move exactly on the tile grid but that it would animate, and could squash from its base. Tidy. Animation is linked to if the SLUGDOUGH is moving or not, with a more pronounced animation if it is moving.
How did I make SLUGDOUGH?
I started out by identifying the key development areas that would be required to make a functioning prototype possible. This includes:
- Tile based pathfinding
- Puzzle creation
- Character rendering along path
- Cutting logic
- Hole logic
- Soundtrack
- Animation
Tile based pathfinding
I researched potential options for the tile based pathfinding, watching several tutorials on YouTube and considering building the system myself by scratch. I settled down on implementing a tile based pathfinding solution by Random Art Attack. Once I had this up and running, I wrote code to move an object along a path set by the algorithm. This is the core of how SLUGDOUGHS find and move along a viable path.
Random Art Attack’s Custom Movement on a Grid and Path-Finding: Unity 3D Tutorial (this is truly the worst tutorial I have ever followed but the ultimate solution is sound) In addition to this, I built functionality for each grid square, such that it shoots a raycast upwards to detect what object is sitting above. If it is a closed cutter, or SLUGDOUGH piece, this is an impassable space and therefore not a feasible route. If it is an open cutter, it can only be passed through in the x or z plane depending on its orientation.
A desired outcome of this design is that when a SLUGDOUGH sets out, it will not set a route which pases through the existing body of its own, or another SLUGDOUGH. However, it does not update its route throughout travel and therefore can collide with a racing rival SLUGDOUGH closer to its final destination, which will result in a reset state.
Puzzle creation
I sat down with my pen and pad and noodled through all the potential types of puzzle which I could imagine for SLUGDOUGH. I then stripped it back to basics to determine how I could teach the player the mechanics involved in making more complex puzzles possible.
Abandoned ideas for new mechanics include:
- Giant slow SLUGDOUGH
- SLUGDOUGHS that combine into strange shapes
- Infinite cutters
- Deep holes which can take multiple SLUGDOUGHS
Some sketches planning the early tutorial levels On train journeys to and from Beaconsfield and during lunchtimes I'd load up a test version of the game on my phone, press it onto friends and playtest the first few levels to get an understanding of how well the tutorialisation was working. My first few iterations left players irritated.
The key to improving player enjoyment and effective feedback was in both speeding SLUGDOUGH up and adding a marker which flashes, indicating SLUGDOUGH's target. Without these changes players would violently mash the screen in an attempt to get SLUGDOUGH to move, which in itself caused another SLUG (read as bug), either resulting in the SLUGDOUGH teleporting around the screen or cutting into bizarre segments mid-path. For a game all about decapitation, too many heads were rolling here.
Character rendering along path
Next, I needed the SLUGDOUGHS to render correctly when moving along their given path. This started to get complex considering there are four different types of possible SLUGDOUGH:
- Main SLUGDOUGH
- Extends one square in length every move.
- Is made up of a half circle head and trailing straight or curved pieces depending on path orientation
- Solo SLUGDOUGH
- Made when a cutter slices a pre-existing SLUGDOUGH, leaving a SLUGDOUGH of just one square length.
- Is made up of circular head only
- Duo SLUGDOUGH
- Same as the solo, except two squares long.
- Made up of a half circle head and a half circle end
- Child SLUGDOUGH
- Three squares or more long
- Is made up of a half circle head, trailing straight or curved pieces depending on path orientation and a half circle end
Therefore I made four different types of SLUGDOUGH head object prefabs to differentiate and treat them each differently. Further, I ensured that each SLUGDOUGH piece knows the next and previous piece in the chain. This allows a search to be done up and down the length of the SLUGDOUGH to find the head and end. Finally, I wrote a script which moves the SLUGDOUGH appropriately along its path to match visual expectations. This essentially involves moving the head to the next position in the path, and the rest of the pieces to the location of the next piece in the chain.
There can be any number of different sized SLUGDOUGH on screen simultaneously Cutting logic
The most complex part of developing SLUGDOUGH was creating the cutter logic. Less brain scratching about how I was going to do it - I knew I could use the previous/next piece logic as the character rendering system. More so, the complexity was due to the huge number of permutations of cutting different length SLUGDOUGHS.
Ready for the chop
Hole logic
I’m proud of the logic I wrote for the holes. Following the difficult time I had building the cutting logic, I sought to simplify the hole logic as much as possible. Simply: If a SLUGDOUGH is smaller than the hole, and its head and end (if it has one) is over the hole, then the level will restart. If a SLUGDOUGH is a matching length to the hole’s length, and the head and the end are over the top and bottom of the hole, the SLUGDOUGH will fall into the hole. The hole will then no longer act as hole and will be passable. If a SLUGDOUGH is longer than the hole, then the SLUGDOUGH is free to pass over the hole.
Fill all the holes to finish the level!
Soundtrack
I worked with one of the National Film and Television School’s composers, Nir Perlman, to compose the SLUGDOUGHS’ different songs; each length of SLUGDOUGH has a different song depending on whether it is moving or stationary. These layer to create an orchestra of sound. We both lent our voices for the acapella recordings. The music was implemented in game by having all the tracks playing constantly on loop, and the volume is turned on and off when appropriate, linked to which types of SLUGDOUGH are moving or stationary.
Animation
This was fairly simple to execute but slightly difficult to conceptualise. I ended up creating a child object from each head prefab which contains the rendering component, with a pivot at the bottom, and a parent which has a pivot at the centre. This ensured that the head would move exactly on the tile grid but that it would animate, and could squash from its base. Tidy. Animation is linked to if the SLUGDOUGH is moving or not, with a more pronounced animation if it is moving.