SHAPE.SHIFT() Post-Mortem

It’s been one week since judging for Ludum Dare 35 started so I thought this might be a good to start writing up the post-mortem for my entry SHAPE.SHIFT().


Click The Pic To Play!!

The theme for this Ludum Dare was “Shapeshift”. Initially I had doubts on whether I was going to create something really good for this jam after the huge positive reception my last entry (Rolla Grolla Arena) received but I decided to just go for it anyway.

My initial ideas were a puzzle platformer (you shapeshift into things to solve puzzles) and a stealth game (shapeshift into disguises) but I decided to reject those idea as in terms of mechanics and level design I wouldn’t be able to finish on time. The idea that I eventually decided to go for was an endless runner where the player would need to shapeshift into things to go past obstacles. At first I wasn’t too sure of that idea because I was already working on something with elements of an endless runner (My current indie project Balls) but in terms of mechanics and time constraints I knew that this was my best option.

Once again I decided to use Unity to develop my game after using it throughout most of the time I took part in a game jam (Aiming for the 72 hour jam as well I wanted to create something that was not only playable but very polished as well). I also decided that instead of making a 2D game (like most of my other entries), I wanted to do a 3D one instead (partly because the last time I made a 3D game for Ludum Dare I wasn’t fully satisfied with the result).

Day 1

As usual I started off the 1st day of the jam by implementing basic player movements. As this was going to be an endless runner game I also implemented a simple scrolling camera.


Next I started work on modelling the obstacles in Blender. This was the first time I used Blender for a game jam (Ironically I went through some simple tutorials for Blender a few day before the jam). To keep things simple I decided to have everything in a 1:1 scale for the player. This meant that in Blender, I would have to model my objects in half-scale in order to be consistent with Unity’s own scaling. Using Blender I created a few simple obstacles by scaling the default Blender cube into a slab and then cut a hole slightly bigger than a cube in Unity scale (about half the size of a Blender cube).


Eventually I also started work on creating some obstacles using the default Unity sphere as a reference and made a simple script to change the player from a cube to a sphere.


By the end of the first day I managed to get my game concept working properly and just started working on the collision logic.


Day 2

Carrying on where I left off last night, I started finishing off the collision logic for my obstacles.


I also started work on creating the obstacle generation code for my game.


Eventually I decided to change my obstacle collision logic so that they’re only destroyed when either the player passes through their hole with the correct shape or they go off-screen.


Once I finished with the mechanics for my game, I started work on the UI. For some extra effects, I also added a trail renderer to the player.


By the end of the second day I had come up with a fully playable game and just started work on its final look (I decided to go for a retro neon cyberspace/Tron-like aesthetic so I spent some time researching how to do this in Unity and managed to achieve my result using the Bloom filter script from the Image Effects package provided as part of Unity’s standard assets.


Day 3

I started the 3rd day of the jam by creating a simple skybox texture in Paint.Net and managed to find a suitable font for the game. I also changed the colour of the player and trail to something that would fit my cyberspace/neon look a lot better.


I also added a simple particle explosion effect to the player when it crashes through an obstacle.


After creating a simple main menu for the game, doing some last minute tweaks and managing to find a suitable background track, this was the final result.


Good Points

  • Time: I honestly felt that I used my time very all throughout all three days with no tasks that would be considered time consuming. I even managed to submit my game 2/3 hours before the deadline with enough polish.
  • Game Mechanics: As the game was in essence an endless runner (and I was sort of already working on one as part of my current indie project), the mechanics were relatively simple to do and the final results were very effective.
  • Graphics: In term of graphics, this is probably the best looking game I’ve ever made for a Ludum Dare despite my limited artistic ability (since I’m primarily a programmer) as I actually made an effort to improve on them and based on the comments on the game’s page, a lot of people have said that the art looks very nice.

Bad Points

  • Brutally Unforgiving Difficulty: Perhaps the most glaring criticism that my game has mostly received so far is its somewhat unforgivably hard difficulty (which to be honest I did not actually expect) because of the precise timing and reactions needed to pass through obstacles. Although there were a lot of things I could have done to make it slightly easier (Bigger holes, larger gap between obstacles, faster move etc.), I did state that it was very possible to get a good score in the game and even wrote a small guide on the Ludum Dare website with some tips and tricks on how to do so (although looking back I do realise that not everyone has very fast reactions). Ironically, when I was watching people play this on their livestreams/Let’s Plays (and constantly dying over and over again), I was surprised by how they didn’t completely give up and just kept on playing, trying to beat their personal best score  (So in a way, the challenging difficulty made it addictive to play).

What I could have added (but didn’t have time)

  • More Shapes: Along with the cube and sphere I wanted to add more shapes such as pyramids and cylinders but unfortunately I didn’t have time to implement them.
  • Colours: One mechanic that I had planned but didn’t have time to do were the use of colours, either as an extra obstacle (i.e. you pass through the hole with both the correct shape and colour) or as a visual guide (e.g. blue for cube, red for sphere).

Overall, this was a surprisingly enjoyable game to make and so far I am happy with the mostly positive reception it’s received so far. In terms of whether I’ll be continuing development on this (either post-jam or as a fully released game), I would very much like to although it depends on when I actually finish my current indie project (Not to mention that I have a few other previous Ludum Dare games that I’d also like to turn into a full game).

If you haven’t seen the game in action yet, here’s a video I recorded last weekend scoring 280 points on my own game.

One response to “SHAPE.SHIFT() Post-Mortem

  1. Pingback: Ludum Dare 35 Results Analysis | Jason's Dev Blog·

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