Escaping Ludum Dare

Posted by
August 24th, 2011 5:24 am

I guess I’m going to write a bit of a post-mortem here about Escape the Fate. My other blarg post focused on bugs, this is more about the development process.

See, I’m a first-timer on Ludum Dare. I initially didn’t think I’d have a finished game in the end, I just wanted to try it out and see how far I’d get in two days. It turns out I can work quite efficiently under pressure. Simply having a submission exceeded my expectations, but not being ashamed of it was even more of a milestone.

I did know about Ludum Dare before, but I hadn’t thought about entering. The TIGSource community mentioned it shortly before it started, and this time I went with the flow. There were some promising themes in the voting; I was hoping for something specific enough to narrow down the entries a bit, but also something general enough to not produce gimmicky games. Waking up and finding out about the “escape” theme was satisfying in that sense.

The event started at 5 AM local time, so luckily I had gone to sleep early enough to wake up at 7 AM. Didn’t even need an alarm clock; it’s as if my body was ready for the competition.

I realized most games would take the theme literally, as in there would be a threat you’re escaping from. I wanted to do something different, and the idea of “escaping your body” by killing yourself quickly struck me. It took me just about half an hour from getting up to getting down to business.

I decided to follow others’ advice and do most coding on Saturday, leaving the fancy presentation stuff for Sunday. Since I’m still a bit hazy in the C++/SFML department, I went for the safe choice of Python/Pygame. Once I had a basic engine running, I started designing levels.

So indie.

Then ideas just started flowing, and I repeated the cycle of adding a level/programming a game mechanic for the rest of the day. Moving platforms, switches, blocks activated by them, collectibles, springs… They’re very universal and recognizable features, but in the context of a suicide game, I managed to give them whole new meanings. It was interesting trying to prevent the player from killing himself before the intended part. I paid special attention to the level progression: the first levels are more puzzle-like, the later ones require more reflexes.

I found myself ahead of the schedule, so I started making graphics and music in the evening. It was an okay decision for me. Meanwhile many other people, even previous participants, were still only trying to think of an original idea at this point. This reaffirmed my previous beliefs that schadenfreude is motivational.

I went to sleep early and quite optimistic, with something playable and occasionally fun on my hands. But as you might expect, Sunday was more problematic. My code was fast becoming unreadable, and even worse, broken. The pushable blocks in particular caused incidents that were hilarious when they happened, but tragic when I realized I have to fix them somehow.

Luckily, I managed to avoid that for a while by derping around on IRC and polishing the presentation to what it looks like now. I fell into a coding trance in the evening and escaped my own body, but I did eventually have something to submit. Little did I know it wouldn’t work on anyone else’s computer.

I’m impressed by how py2exe packaging was still incomplete after all the added weight. I did manage to isolate the cause to the freaking font and repackage painfully, making unnoticeable perfectionist tweaks after each upload.

The consensus on my game seems to be “polished and challenging” in a nutshell. The concept is distinctive, the levels are memorable, the controls are responsive, the graphics are a step up from programmer art, and the audio suits the mood. However, people have asked for more instructions on the experimental game mechanic. While figuring out level solutions is in the spirit of a puzzle game, I think it’s a reasonable response, and I now know what concerns to address if I ever do an improved post-compo game.

What I regret most is that I had a bit of a rough release. At least I’ve tried to swiftly fix any game-breaking bugs that didn’t show up on my end. If I could do something differently, I’d make more people test my game before submitting, so I would have to do less patches afterwards. Even though bugfixes are allowed after the deadline, I’d love to have just tossed the game on the site before running away and not looking back.


Leave a Reply

You must be logged in to post a comment.

[cache: storing page]