It took me some time and several walks around the block to figure out what sort of game I wanted to make.  I had a lot of ideas, but all of them seemed a bit lame. Eventually I decided I’d better start something, so I took the least lame idea I had and began working on that.

My idea was to make a kind of infinite runner with a block dodging other blocks.  Dodging would be done by alternating between 2 discrete states: above the horizon and below the horizon.  This sounded a bit boring to me, but it fitted the theme, and I thought I could eventually make it more interesting by introducing some extra colour-based mechanics.  For example the enemy blocks could be different colours and the player could collect coloured orbs that would eliminate enemies of a certain colour.

Once I implemented the base idea I found it was quite fun on its own, especially when I ramped up the challenge by varying the speed of the enemy blocks.  I decided that I didn’t really need any other mechanics – they would just add clutter and go against the theme.

I wrote a simple text-based pattern parser so I could easily experiment with new enemy block patterns.  I thought it was important to have distinct, pre-designed patterns in the game, as opposed to just random sequences.  This would a) allow the player to improve by learning the patterns, b) make it easier to ensure there were no impossible sections, and c) facilitate a sense of progression by introducing new patterns as the player got further.

My initial control scheme was press and release the space bar once to change states.  I quickly realised that having space down represent one state (below the horizon) and space up represent the other state (above the horizon) was far more elegant and allowed for faster state changes.  This allowed me to increase the challenge even more while still keeping it playable.

On the second day I had the idea to introduce persistent markers at death points.  Initially I had thought to use gravestones for the markers, but later I had the idea of using flowers instead, which was a bit less morbid.  I also liked the symbolism of new life coming from each death.  This also lead to the name choice.  I was going to call the game “Monday” and only changed the name at the last minute to “Tulip”.

I made the music using Figure for iPhone, which is fantastic for quickly creating catchy loops.  I originally had more loops and arranged them randomly, but I found it difficult to get consistently good sounding results, so I just went with a few loops strung together in a predefined pattern.

I used my own engine (https://github.com/ianmaclarty/lotech), which worked quite well.  I think there are definite advantages to using an engine you’ve created yourself: you know exactly how it works, so you’re aware of its quirks; if you run into a bug you can just fix it;  if you need a new feature you can just add it.  Of course there are disadvantages as well.  I wasted about half an hour tracking down a bug in my .wav file reader (I had recently updated to the latest version of Audacity and it was adding an extra, unexpected, chunk to the .wav files it was generating).

Here’s the timelapse:

And the final product:

You can play it here: http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=20641


Leave a Reply

You must be logged in to post a comment.

[cache: storing page]