February 6th, 2019   // Ludum Dare 43: Post mortem of Panquetzalt

A bit late as usual, here is what I learned, what worked and what didn't while attempting for the first time the Ludum Dare. As it was my first LD, my only goal was to submit something completed, even a very bad game.

The event

But first let's talk about how it went. The goal of the Ludum Dare is to create a game in 48 hours, all by yourself. Litteraly everything (music, images, etc...) must be created during the event. At the start of the event a theme is given: your game have to comply to it.

This time the theme was: "Sacrifices must be made".

So I decided to take this to the letter and create a game that literaly makes you sacrificing people to satisfy an angry god. It's called Panquetzalt and you can find it on itch.io. If you want to see how it's made, here is the repository. Elysia Griffin, a twitch streamer also tested the game live.

Here are the ratings the game received:

  • Overall: 206th (3.5 average from 30 ratings)
  • Fun: 303rd (3.107 average from 30 ratings) -> Worst category
  • Innovation: 82nd (3.679 average from 30 ratings)
  • Theme: 57th (4.107 average from 30 ratings) -> Best category
  • Graphics: 145th (3.696 average from 30 ratings)
  • Audio: 177th (3.232 average from 30 ratings)
  • Humor: 179th (3 average from 30 ratings)
  • Mood: 167th (3.37 average from 29 ratings)

Considering there were around 750 games submitted, this means that the game did quite well. It certainly is not a "hit" and the ratings for the "fun" part are not good. The overall feeling was that the game is too hard too quickly.

How it went

Pretty good ! But it took me the whole week to recover :D

Below is my schedule during the event:

Day Time Activity
Saturday 03:00 - 04:30 Finding the idea / Drafting a mockup
Saturday 04:30 - 07:00 Main spritesheet drawing
Saturday 07:00 - 09:00 Unity bootstrapping
Saturday 09:00 - 10:00 Family time
Saturday 10:00 - 19:00 Main loop coding
Saturday 19:00 - 21:00 Shower / Food / Youtube break
Saturday 21:00 - 01:30 Main loop coding
Sunday 01:30 - 03:00 Youtube / TV / Relaxing / Checking how it's going for everyone
Sunday 03:00 - 09:00 Sleep time
Sunday 09:00 - 10:00 Soundmaking
Sunday 10:00 - 12:00 UI rework / polishing
Sunday 12:00 - 12:30 Food / Youtube break
Sunday 12:30 - 13:30 Music rework
Sunday 13:30 - 20:00 Adding context (main menu, tutorial, ending scene)
Sunday 20:00 - 21:30 Food / Family time
Sunday 21:30 - 22:30 Preparing the Itch.io and LD entry
Sunday 22:30 - 01:00 Balancing, adding variety, final touches
Monday 01:00 - 02:00 Publishing the game / Testing
Monday 02:00 - 03:00 Relaxing / checking how it's going for everyone

On the 48 hours, 35 hours were used for working and 13 hours were used for resting.

What I learned


48 hours can be a long run, and depending on your physical condition, you might collapse if you try to work 48 hours straight. The key to success it to have real breaks where you think about something else, eat, wash and sleep. It allows you to maintain higher speed of work and a clearer mind in the long run, making you faster on the overall.

Be dirty

The goal is to complete a game within a very small timeframe. Making good code takes time, and you have none. Some people told me this before when I asked for advices but I found it myself very useful in order to complete the game. I stopped working 1 hour before the deadline and did no refactoring. If I had stopped to clean the code I might not have completed the event.

Given the game did not become the new Minecraft, I will never sell it, so I will never improve the code. But who cares? :)

Complete the main loop as quickly as possible, then iterate

My main fear was to fail to submit a finished game. It didn't matter if it was a bad game, my only goal was to publish something finished enough to be considered as a game. This approach saved me a lot of trouble by forcing me to drop every non necessary feature. After the first 24 hours I had an ugly game with no music, no UI, no tutorial and very little user feedback: but it had a start, an end and a complete game loop. From there I just had to make small iterations of improvements until the end. Every hour I had a version I could submit anytime. This created a feeling of being safe about the deadline and allowed me to focus on being productive and creative.

Beware of the difficulty bias

This is what caused the greatest flaw of my game : being too hard. As you build your game you become really good at it. Because you know how it's made, how the internals works, but also because while testing it you get trained for it. This is what happened for my game. I scaled the difficulty based on my own feedback and ended up creating something I am the only one to find easy. I have no good advice to give you for that given I made the mistake too. So I can only tell you to be aware of that phenomenon! :D

What's next ?

Well, hopefuly I'll have a free week-end for the next Ludum Dare!