Ludum Dare 36 Notes
I made a game prototype called Rushed Dinosaur Dare for the Ludum Dare 36 48-hour compo. Since it was so much fun I thought I'd write a few words about it here.
Beginning#
Ludum Dare 36 was the first fast-paced game jam I took part in. It's also been about seven years since I started a new game project from scratch, so this was a chance to snap out of that lull and work on something fresh.
LD36's theme was Ancient Technology. Let me tell you, coming up with a new game idea under a pressing deadline was a lot more difficult than I thought. I doodled and jotted ideas, but did not decide what to make until the next morning at 9.
Now I understand the importance of small and frequent works to complement never-ending forever projects. Can't come up with something on the fly in two days if you've been working on the same couple of things for years, it's a different skill.
Inspiration#
I always wanted to make a game with CGA Palette 1 graphics like Sopwith and Alley Cat:
With this in mind I opened my sketchbook and started doodling:
After I had an idea of where this was going, I fired up GIMP and did some pixel art. This would be a side-scrolling game with randomly generated terrain and scenery:
The idea was time traveling in a buggy back to the Jurassic period to steal dinosaurs' technology. Unfortunately the 48 hours ran out before I got the chance to include any dino tech in the game...
Coding Starts#
Looking at my git log, I started coding Saturday at 3pm, 21 hours after the event started. For future Ludum Dares I will limit brainstorming to 12 hours and begin programming the first morning.
I wrote Rushed Dinosaur Dare in C with my a2x framework. This was a good ad-hoc test for a2x, and it helped me not waste any time with boiler plate code or anything else unrelated to the actual game itself. Familiarity helps when time is tight.
I tried to keep the code base clean and well organized for as long as possible. This is easy at the beginning, but gets progressively difficult as the deadline nears and you rush to add things. That being said, starting with a clean architecture and consistent code style helps keep things under control when the chaos begins.
Even when you hurry, it's still faster to copy the pattern of a well-implemented feature you did yesterday than it is to write all-new spaghetti code from scratch. More importantly, clean code is easier to read and easier to reason out: throughout the Ludum Dare weekend, I spent less than 30 minutes fixing bugs.
Here's a screenshot timeline of RDD starting to come together:
Time Runs Out#
48 hours were not enough to make something beyond an idea prototype. I considered submitting RDD to the 72-hour jam instead, to buy myself more time, but ultimately my goal is to improve and accomplish more with each subsequent 48h compo.
Now I plan to develop this into an actual game, which definitely wouldn't have happened had I not participated in LD36. Cheers to everyone involved and see you next time in December!