Hi folks, it’s my 3rd Ludum Dare, but I guess it’s my very first post mortem, for my LD 29 entry, Fish Goes Fishing (click here if you’re still to play it). So, with no further delay, my time lapse video, followed by the post mortem itself.

The Idea

When I first saw the them i was like “blergh”. I won’t deny it, I’m more an old school C/C++ programmer than a designer, and”beneath the surface” only ringed an underwater game to me. And that’s what I did, a game where you’re fish, constantly hungry, struggling to survive by eating other fishes and avoid being eaten by the fish you can’t eat at all. At first, I wanted to have a fisherman passing by a boat, which could mean an instant death in case the fish was caught, but this idea was scrapped along the way, as time was getting shorter. I also planned to have two gauges, one with the hunger factor (fish dies if maxed out), and another with an energy usage factor, that would be depleted when the fish moved, but would recover when the fish would rest. With that in mind and a very rough sketch on paper, I started my 3rd Ludum Dare.

The Code Base

Doing a full game in 48 hours is already challenging, leave it alone doing the full code to make the magic happen. Since I did Ludum Dare 26 I’m building a basic code framework over SFML. To bootstrap Fish Goes fishing, I had the menu system ready, plus a character hierarchy and controller code in place. This time I added character animation and very simple animated particles (the bubbles, plants and anemones). Maybe for the next Ludum Dare I’ll have tile map support with some physics library in place (Chipmunk, maybe).

Highlights

1. Mockup graphics: I wanted to have a sense of how things would play together as soon as possible. Both in sense of gameplay and how they’d look together on screen. For that I made characters that were simple rectangles to get myself going soon. This allowed me to focus on what I had to do first (the code) and to scale the time I’d spent to polish those resources later.
2. Do a game that your library or code base makes it easy for you: while we can have very complex ideas, it’s not useful if we can’t make them happen. It’s OK if we need to code something specific for the game, but getting it up from scratch is a hard task. use a library or framework if you can. If you’re old school and is starting out with a library like SFML or SDL, try to make a game that uses the libraries basic resources, and then, for the next time, you may improve upon that code base. I’ve been doing that for a while and it’s working well.
3. Generalize first, specialize later:when developing the game, I focused on creating the basic characters, and the other character were built upon those previous elements, by adding more states and changing animation frames.
4. Prioritize efforts: a game is much more a sum of parts, rather than only one individual aspect alone. Something I did was to question what’s required from here to get a build that plays like a game, even if we need to balance things to make the game more challenging. I was about 26 hours into the jam and the fish could eat other fishes, which was a good milestone.
5. Using well the right tools: I’m no musician, as I’m no graphics artist. But I can overcome those limitations (a bit, at least). Music and sound can always be generated by automated tools. For SFX, I used bfrx, and for musics I used Otomata. These can save a lot of time and effort, and give some mood to the game. Just for the record, I’ve also used in the past Punk-O-Matic, and I’ve also seen other procedural music generator apps that allow me to export files to MP3. As for graphics, Gimp is more than enough for pixel artist making, and also has very easy to use too to rotate layers that I used to make the scuba diver animation.
6. Not being afraid to scale back: the earliest we see something is too big for the original deadline, we need to remove it ad minimize impact. This goes well with number 2 above, and I had two occasions were this was important:
   1. Missing fisherman:I thought about the fisher man, but this character would have a moving part for the line and required a special hierarchy. To avoid expending too much time with this guy, I decided to drop it before I couldn’t finish the game. While it was hard, and a hit on my original idea, I fully understand it was for the best (as I’d complete the final build close to the deadline).
   2. Gauges mechanics didn’t work out:the idea to have two bars to control both how hungry and tired the fish was seemed awesome. Once I tried it out, it wasn’t working out as expected. To solve that, I change it to a single bar, which would go down faster when the fish was swimming, and slower when it was idle. Also, it was simpler for people to understand the game.
7. Life can get in the way: working at home to do a Ludum Dare and still having the regular responsibilities of a regular weekend is a tricky challenge. In my case, that meant shopping for groceries, taking kids to swimming classes or doing a BBQ for the family. This may manifest differently to each person (going to school, doing a report, whatever), the fact is that life is still there and we should be prepared to accommodate other activities rather than just doing the game. In other words, try not to procrastinate, as this time will be missing later ;).
8. Pressure can make simple mistakes become nightmares: when I was doing the Windows build (I only use Linux), i made a Makefile to cross compile the binary. And it wasn’t working at first. I had my entry in place, I had the source code uploaded, and it wasn’t before 5 minutes of the final deadline that I had my Windows binary after I found a small typo in the name of a file. Was under normal stress, I would have noticed and laughed this off, in the submission hour I couldn’t even see what was right or wrong anymore. Try to avoid the pressure of a ticking clock at all costs.
9. Oh, you may get sick as well: while normal life may get in the way, and I’m used to it by now, I wasn’t quite ready to deal with illness. I had food poisoning Sunday, and the last three hours were not fun to get over the final tasks. Had it happened earlier, I think I’d have retired from the compo. As most of the hard work was already in place I decided to push forward.

Conclusion

Every time I go through a jam or Ludum Dare I learn something, and I also enjoy the challenge to come up with something even if the theme is not the one I’d liked the best (like this time). I may try jamming with friends some time, as soon as we can match our schedules, but until then, I can get into the compo by myself and have some fun :).