Ludum Dare 31
December 5th-8th, 2014

October Challenge 2014
Ending Soon!

ConstructionPlease excuse the site weirdness. Mike is making and fixing things. Clocks are probably wrong. Colors are place-holder.

What is Ludum Dare?
Rules / Guide

A late post mortem

Posted by (twitter: @aki_koskinen)
May 13th, 2012 2:37 am

Since it’s now the last day to judge the entries I think it’s time to write my post mortem which I was supposed to write a long time ago already.

The LD#23 was the first one I participated. I was successful in submitting an entry but it’s not a winner. So some things succeeded, some didn’t. In every case I had fun times during the compo weekend and will definitely participate in future LDs too.

My entry is off course still available so you can try it if you haven’t yet – even if the judging time has already expired when you read this.

What went right:

  1. Before the compo: I prepared well. I made sure I had all the tools installed and working. I made a simple stub for the game that just showed a white screen (it could have been black as well). I packaged it and asked people on the IRC channel to try it out – and people were helpful there and offered to try it: thanks for the help for everybody who participated. This way I made sure that my “distribution pipeline” was in good order. This was to ensure that people could run my entry after the compo.
  2. I used familiar technologies. I build my game with the Proton SDK which I have been using for the past several months now so I’m quite familiar with it. I didn’t have to study the technology too much during the competition which gave me time to focus on the actual game.
  3. At some point during the compo I realised that I was doing a 2D racing game. For that I needed some car physics. First I thought to implement the needed physics by myself. I was thinking that doing a simple bouncy car with some collision detection and springs would probably be a quick job (ain’t it always). But luckily in the end I decided to check Box2D first. I didn’t really have much experience with the specifics of Box2D before. I did know that it is a solid body 2D physics library. But I didn’t know the API or the specifics of it at all. But Box2D turned out to be really easy to use. In the examples that came with it there was also a car physics simulation which I was able to use as a starting point for my need. The end result is definitely better than what I would have been able to achieve with a home grown solution in the limited time.
    I really liked Box2D and will probably use it in some future projects as well. It seems a really good library and no wonder it has become the de facto 2D physics library nowadays.

What went wrong:

  1. I didn’t really manage to do a game in the end. My entry is more like a technology demo. After brainstorming some ideas what kind of game I would do I had a rough idea to what direction I would head. So I started implementing. But I never really cared to think what the game would be about. I thought that it will just materialize somehow in the process. Well, that didn’t happen. In the end I ran out of time and didn’t manage to do much of a game at all.
    Lesson learned: spend enough time in the beginning before rushing to implementation to figure out what the core idea of the game is. Then implement that core mechanic first so you’ll have the game in place in the end.
  2. The only headers coding convention I decided to try out didn’t really work out. As I suspected in the pre-compo post the compiling times with this approach grow quite a lot while the codebase grows. But I thought that one wouldn’t be able to produce that much code in 48 hours that it would be a hindrance. Well, boy, was I wrong about that. After the first day’s coding the compile times were still manageable. But during the second day the compile times were starting to be quite long. During compilation the HDD light on the computer was constantly on so I suspect that the time was spent on reading files in from the hard drive. I have a SSD on the computer which is at least supposed to be fast but still it seems that the compilation process got I/O bound.
    So as Mythbusters would put it: this coding convention idea is busted!
    Lesson learned: if doing C++ put your .h and .cpp files separately as they teach you in the school. The wise men know what they are talking about :)
  3. Music. I did manage to get some music to the entry and people have even given positive comments about it so I guess it wasn’t a complete failure. I’m not that much familiar with audio software so I didn’t really know what would come out as music. So in the end I’m happy with what I achieved with the music track.
    But where I failed with the music was the schedule. The compo ended here at 4am local time. So the last 4 to 5 hours everybody else in the neighbourhood were sleeping while I was doing the music track with headphones on. Earlier on the day I had recorded an acoustic guitar track. But I didn’t do anything with it until during the night. At around 1am I was adding drums and a bass track to the music in Garage Band. As it turned out the guitar track wasn’t quite in tempo all the time. It would have been an easy task to pick up the guitar and record the track again – this time with a metronome or the drum track on the background to get the tempo fixed. But in the process I would have woken up my fiancĂ©e and the neighbours so I couldn’t do it. So in the end I was only able to use less than half of the guitar track that I had recorded.
    Lesson learned: if using real instruments for music (or any foley artist kind of stuff to make sound effects) do those during day time while you won’t disturb other people’s sleep.

Those are the main points that I had in my mind. Overall I really like what I achieved and learned during the hectic weekend of Ludum Dare. See you next time :D


Leave a Reply

You must be logged in to post a comment.

[cache: storing page]