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.
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:
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.
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.
Rest
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
Well, hopefuly I'll have a free week-end for the next Ludum Dare!