Programmer and Game Developer


Ludum Dare 38 – Post Mortem

First off, I didn’t actually finish in time for Ludum Dare 38. I woke up ill the 2nd day and didn’t feel confident in finishing, so I cut it there. I personally think it was the best choice, given my past experiences with illness. Throughout the post I’ll try to link directly to source code relevant to the subjects!

However I did spend roughly 16 or so hours actually working on the entry with relatively good progress. Most all of this code in some way or another can be found in the compo branch of my LD38 Repository.

What I had finished in the first day I was awake for it:

  • Working player movement
  • Large scale object display
  • Level loading of sorts
  • UI Usage / i.e Main Menu interaction
  • Audio/Music working and mostly made
  • Some sprites & placeholders

What I should have prepared before it all started:

  • Level Editor
  • Scripting
  • General Engine Polishing

I’ll start by addressing general engine polishing. This feels almost as if it’s blatantly obvious, however there are some very real problems that shouldn’t have occurred. One of the main issues was that I had forgotten to add a runtime queue for creating Game Objects. This lead to the game crashing due to ConcurrentModificationException in java. It’s a relatively stupid mistake that was easily mitigated, however it pointed at the rushed nature of the engine.

Following this would be general API decisions. I spent a lot of time focused on getting it running instead of understandable. This lead to a friend working with the code getting confused and having to often back track, or ping me for patches. This wasn’t a burden for me, however I strive to make usable code. It’s an important thing to realize as I wish to continue being an open developer.

The level editor would have vastly changed the turn around time for the actual jam. While I’m comfortable writing code for generating dungeons and whatnot (i.e for Beyond the Void) it’s been a good while where I’ve physically edited a level. Thus at the time of outlining the goals of the engine I had brushed off a level editor. I had left the “Level” object fairly barren and to be implemented per each level. Wouldn’t have taken more than a day or two at the pace I was working at.

Scripting would make the engine easier to test new ideas with. While I usually have a pretty reasonable grip on what my code can do, having to implement things on the fly, or write larger snippets of code, took up a good bit of time. The pace of me actually developing the API in the engine and developing the game were relatively the same speed. While this is alright when not on a time limit, the presence of the time limit makes game development at that pace feel sluggish.

TL;DR More tools equal less headache when time is important

I’ll be taking a few days to get back into working order and whatnot. I do intend on sharing some more of the code that I pile up over the next few weeks.

Until next time, I’ll see you later.


Programmer and Game Developer. Solo Developer on Beyond the Void.