My ludum dare 38 entry is a game called Mini-Shaders. A programming puzzle which borrows from the idea of shader programming.

This is my first time making a puzzle game, never mind a programming puzzle game. It was a pretty fun experience, although I realised towards the end that I was missing a couple of commands to make the patterns truly interesting (such as abs). There were also reports of some bugs here and there, which I guess is somewhat to be expected as I was really pushed for time.

This was also my first compo entry, which means that all the art (which was really just a bordered square made in inkscape), sound, and programming had to be done alone and within 48 hours.

The game can be found here.

Gotta Herd’em All

I worked on Gotta Herd’em All with creative630 and rawhed for Ludum Dare 37. The gist of this game is that you had to herd patients into a waiting room.

Truth be told, this game is pretty bad for many reasons, but at the same, it is the most fun that I have had on a technical level in a game jam.

The reasons for the above is because the game resides (except for the sound) in shaders and textures, where all the game logic, rendering, and game state were handled inside a few shaders that were joined together in a graph. Although the sound wasn’t generated in shaders, it was also created entirely in code. The reason we decided to do things this way was because we were inspired by some of the really crazy and amazing things people have done on ShaderToy.

We encountered a tonne of problems when making this game, which resulted in a pretty poor final game. Many of these problems were down to a lack of preparation, for example, I spent half a day writing a system to render numbers to the screen instead of having it implemented already. In addition to these types of problems, one other major problem we encountered was poor performance.

After some investigation, I found out that the actual cause for this was the c# code checking the game state in order to trigger sound effects. The reason why this was so slow was because it required a GPU->CPU copy of the game state texture. Normally this would not be much of an issue, as the texture’s dimensions were only 32×32, however, Unity has no option for asynchronously copying textures. This meant that every frame where we copied the texture to the CPU, a pipeline stall would occur. This was a very big problem for us since our game was so shader heavy.

I spent some time after the game jam thinking about how one would get around this issue, and came to the conclusion that you could just write a native unity plugin that did this. It would just take in some texture, do the copy natively, and then when the data is available, return it to the managed code.

Overall, despite this submission not being a good game, I believe we all learned a lot during this game jam, which I feel is much more valuable than just making a decent game.

Gotta Herd’em All can be found on the LD37 submission site here.


Janissary was my entry for Ludum Dare 36. The description for the game is

You are a member of the Janissaries, the elite fighting force of the Ottoman empire. The empire has come under attack from a massive fleet of airships, but no worries, as an elite fighting member, you have the trusty musket. Explode the airships with your musket to defend the empire’s honour!

Truth be told, the game was initially just supposed to be a shooter where the user has to manually reload a musket. The actual theme came along when I realised that my scenes were looking too plain, so I was using the sandstorm particle effect to hide that fact and I needed a theme to match that.

Props to my buddy who wishes to remain anonymous for both the musket and blimp models. I am somewhat artistically blind, so I didn’t realise how bad the models I made were before comparing them with his.

Janissary can be found on the LD36 submission page here.

Quad Flingers

Quad Flingers was my entry into Ludum Dare 35. This was both my first Ludum Dare, as well as the first Game Jam where I worked alone. To quote myself on the description of the game

Quad Flingers is a 2D top-down local 2-player shooter, where you each play as n-sided regular polygons which are capable of flinging quads. The aim of the game is for you to CRUSH your opponent. In order to achieve this, just fling quads at them until they die.

To be able to fling quads, you need to collect the various yellow quads scattered across the map, these also double up as your health. The number of sides you have indicates both your health and available ammo. Be careful however, as once you collapse to a 1 dimensional peasant (less than 3 sides), you will lose the game.

In addition to the quads scattered across the environment, there are also various powerups to improve damage, speed, and rotation rate. You can use these to improve yourself.

I found that working alone was a lot more challenging than in a group, as it wasn’t possible to concentrate on just the parts I was working on. This made prioritisation of features a lot more important in order to get an actual working game out.

Quad Flingers can be found here.

Solemn Dong

Solemn Dong was my team’s entry into the 2016 Global Game Jam. As per description on the website

Many of us have experienced the difficult nights out ritual where we are pissed, and need to piss. Solemn Dong allows us to re-experience these precious, but often forgotten, moments by allowing you to relieve yourself in a variety of environments, and onto a variety of objects.

It is, for the lack of a better description, a drunken pissing simulator, where the player uses the Thalmic Myo to control the phallus in order to try direct the stream of urine into the toilet or urinals.

The one challenging thing about working on this game was the actual physics of the phallus (yes I’m being serious here). We sort of hacked it with some spring joints and assigning those to bones, but this did create some weird physics glitches at times. I feel like, if given more time, a better approach might be to model the phallus as a single spring, and then tessellate to get the actual geometry.

It was pretty amusing working on this game, although that is probably because I act half my age.

Super Massive Crate Dash

Super Massive Crate Dash is a game I worked on along with a few friends during the 2015 Global Game Jam.  To quote the description from the GGJ website,

Super Massive Crate Dash is a massive multi-player local single button infinite runner game. In SMCD, people can join on the fly by pressing a button (any keyboard button). Players are tasked to avoid obstacles, pick up power-ups, and avoid falling behind the camera. Dead players can still play by playing as crate obstacles, which can impede existing players.

This was the first game jam that I’ve participated in, and I was really pleased with the result, both in terms of the final game as well as how much fun I had during the jam. Huge props to both Paul for the art, and Ivo for the music, really helped create a cool atmosphere for what was otherwise a somewhat simple game.

Since the game was quite popular, and we decided to further improve it by adding more levels, powerups, and music.

The last build of the game can be found here.