http://www.ludumdare.com/compo/ludum-dare-22/?action=rate&uid=7456

This was my first Ludum Dare and I must say that I enjoyed every moment of it. I rarely see my projects through to the end so having a time limit and some competition was very useful for motivation.

What went right?

• Time. I had plenty of time to work on this game, an empty house and no plans for the weekend meant that I could dedicate every moment I was awake/not eating to working on the game.
• Pre-planning. I planned every aspect of the game on paper and planned out exactly what order I was make everything in before I wrote a single line of code. Not a single feature in the final version wasn’t planned on paper first, a lot of features from my original plans were removed though.
• Knowledge. Every feature in my game had been made at some point or another, in some form or another, by me. The problem was trying to remember how I made them and then put them all together into a game that actually works.
• Notch. That man’s livestream had some great music. Plus, the rhythmic tapping of his keyboard was great motivation to keep typing.
• Gameplay. The idea was that my game would be hard. I wanted people to feel under pressure while they were trying to disarm the bombs, I thought that the time-limit, lack of a reset button and having to start the game from the beginning if they failed was a good way of achieving this. Plus, if no one can finish the game, no one can complain that it’s too short.

What went wrong?

• Gameplay. Apparently players don’t like to be infuriated by high difficulty levels and over-the-top punishments for making just one mistake, who knew?
• Over-estimation of my programming speed. A lot of stuff from the original plans were never in the final game, this is purely because I didn’t realize just how long it takes me to code even the most basic of features.
• Lockpicking. As a result of not having the foresight to realize how long these features would take to add, lockpicking wasn’t started until a few hours before the deadline. This resulted in lockpicking turning from the Tetris style puzzle that it was originally supposed to be and becoming a “Bash the buttons as fast as you can” minigame with awful graphics. It also meant that the option to place a previously disarmed bomb in the lock to explode it open, had to be cut completely.

Conclusion:
Overall, I’ve learned that difficulty is not a good substitute for longevity and that believing my programming skills to be god-like is never a good idea, especially before I attempt to make something against the clock and something that other people will play.

Tags: LD22, post-mortem, postmortem

This entry was posted on Monday, December 19th, 2011 at 6:35 pm and is filed under LD #22. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.