Post-mortem of Meow for MUTATION!

Posted by
August 28th, 2012 7:26 am

Okay, before I start with my post-mortem, some advertisements.

If you’re interested in playing the original Meow for MUTATION! and rating the game, visit the entry page. There’s also the updated, post-compo version there, but I recommend trying it after rating the original. If you’re interested in timelapse, check it out here. Thanks!

This game contains kittens. In fact, mutated ones!

The Good

  • Game design document. It’s very good to write what you want to do – even if just for future reference.
  • Using a genetic algorithm. Generally it’s good to use stuff that you know best – and I did use such algorithms a lot some time ago. It’s a very simple implementation, but it took me very little time to code. It works neat, too.
  • Graphics. Wow, 5 mins of searching in google “how to draw a cat” and I had a general idea of how I want my mutating cats to look like. Modular graphics were a great idea (although a little complicated in implementation), and honestly, I’m still impressed by my mad skillz. 😛 First drawings were made with real pencil on a real paper and that was also quite a good idea (later I used a tablet).
  • Forums, community, overall help one can find on the web. FlashPunk forums especially.
  • Employing event tracking in google analytics. This was quite easy, actually. Now I’m able to track how many people play my game, what’s their average score, and many other things. I will try to post some statistics later.

The Bad

  • Reading “Game Coding Complete” and thinking (too much) about structuring my code just right (just stick to your framework!). I blame the authors.
  • Not testing. This seems more important with every LD I take part in. My game is completely untested – and again, unbalanced and too hard (too few means of controlling the population; the easiest way to fix it is allowing the player to select specimens for reproduction, not deletion – this is done in the post-compo version). I keep forgetting that games need to be fun and playable, not concept-accurate.
  • Trying to make something in FL studio for the first time without creating anything before (I managed to record myself saying “meow”, modify this sound into beats and stuff, create some simple, annoying loop, but it was just too much work) – I generated something with GreaseMonkey’s autotracker. It’s an awesome piece of code.
  • Thinking too big for the compo. Wow, I was bold enough to think that I could also do a tower-defense part to the game. Like, on top of the general GA idea. I decided to cut the tower-defense idea after the first day.
  • My mood, when I figured my idea might bee too much for me. Just in the middle of the compo, I was pretty sure I won’t make it. I even wanted to resign already, but kept coding anyway, just for the sake of it. After some substantial cuts to the idea, I was able to complete something playable.

The Ugly (truth)

  • It’s a 48 hour competition: don’t waste time on semantics. Know what to do with your code structure and how you’re supposed to do it.
  • In fact, try to not waste time at all: the simpler the idea or the more you’ve had experience with something similar before, the better the result. It’s great to learn new things during the compo, but this can reflect badly on overall quality of your game.
  • Get some utils ready before the compo. Some basic stuff, some helper structures, etc. For example, I wasted too much time on coding Entities able to contain child Entities in FP, just to create some screens with messages. I wasted a great amount of time on reading the code of punk.ui and had to hack&slash it to make it work in my environment.
  • If you don’t code games everyday, or you plan to use a language you don’t use very often, warm up before the compo!

Overall, this was a great weekend and I look forward to the next Ludum Dare!


Leave a Reply

You must be logged in to post a comment.

[cache: storing page]