This past weekend I participated in what was not only my first Ludum Dare, but my first game jam ever. By the end of those whirlwind 72 hours working with my artist teammates, I publicly released my first game (outside some toy projects almost 7 years ago), had my first experience building a project with Unity, and learned a heck of a lot in the process.
Before we dig too deep into my experience in the jam, you can find our itch.io page here and our LDjam page is here.
The Team
The core team I worked with was myself doing development, my friend Trmrddr creating 3D assets (and helping me out with Unity stuff throughout), and Giraffalope doing 2d asset creation and art direction.
In addition to those core team members, we pulled in two ringers to make music for the game. My friend Progs threw together some synth chirps to use for sound effects, and Trmrddr‘s friend Oscar put together two incredible little music loops for us.
Three Heads are Better Than One
Giraffalope’s initial sketch that kicked off our culinary super-star’s journey 
A second sketch that we found so funny it became central to sending orders
The problem I always have when trying to make games is that initial idea generation is nightmarish when you’re alone with no restrictions. Luckily, Ludum Dare provides a restriction in terms of a theme. Unluckily, the theme for this jam was the unhelpfully vague “Start With Nothing.”
Getting an idea we were all interested in and felt comfortable with still took us a decent amount of time, but having other people to bounce ideas off of and other ideas to expand on made that a way quicker experience than if I had tried to do it on my own.
Learning Your Tools Beforehand is Probably Smart
Like I mentioned: I hadn’t used Unity for anything more than half-following a tutorial or two almost a year before starting this, and I hadn’t written in C# for even longer. Did I do any brushing up/learning beforehand? Not really. Would it have saved me researching silly things all the time, and given me noticeably more time to implement features? Almost definitely.
You want your 72 hours to be as effective as they can be: you’ll have your hands full with actually building things, you don’t want to be learning everything else at the same time.
Try and Keep Your Scope Tight. Then Cut it in Half
If you’re anything like me, 72 hours simultaneously sounds like all the time in the world and no time at all. We thought we were keeping our scope pretty tight since we knew we only had one developer, and we still ended up leaving a decent amount of content on the cutting room floor.
The amount of unused assets we had sitting around, and unimplemented ideas that “shouldn’t take long for me to implement” number in the dozens. Even if you know the tasks are small, the time adds up. Which brings me to my next point:
Writing Good Code Will Save You Time
When I sat down to start building our first level, I knew we’d want to build a bunch of them, and since I was the only dev (and had to work at my day job the last day of the jam), I knew we needed the systems to be in-place for levels to be added and tweaked without writing any code.
Setting up the systems I needed to make took a little more time than if I had just hard-coded everything in the first time around; but it meant that with pressure mounting and the clock nearly up, we were able to go from a single difficult level to four levels that actually teach the game.
More so than anything in the jam though, I think it’s set us up nicely for expanding on the game afterwards.
But Be Prepared to Duct Tape Over it
Look, you only have 72 hours. You have even less if you take breaks and sleep (and you should, no one does good work while exhausted). You don’t want to spend three hours trying to track down a fix for a random issue, or implementing a tricky system for a one-off effect.
Be ruthless. If something’s not working, find the shortest path to get it done, even if it’s bad code. If that means dropping the feature, so be it (in the above case, I gave up on having the tongue stick out to show what item Frogbert is holding).
Build Your Game Early, and Often
I’m sure this advice is obvious to every developer who’s actually released a game before, but we made the mistake of not trying to build our game until we were preparing to release, at ~10pm on Sunday night. As it turns out, that’s a great way to end up tearing your hair out until 1am trying to get things working.
Don’t be like us, don’t get surprised by last minute build errors.
Get People to Playtest Early on
This is obviously tough to do mid-jam, since you’re so busy with everything, but managing to get some outside hands on your game before you’re finished can help out quite a lot with finding pain-points before the judges do.
You know your game better than anyone else, so things feeling good to you might not translate to intuitive handling by random players. However, getting feedback won’t do you any good if you don’t –
Leave Time To Tweak
We aimed pretty high with Frogbert, both for features and for polish. As a consequence, a lot of random numbers I put in during development (waiting 0.5s between movements, or spawn speeds/times for ingredients for instance) didn’t see the fine-tuning they needed.
You don’t have tons of time to do this, but if you’re taking time to juice up your art and sound, make sure you’re at least spending a bit of time sanity checking your game-play balancing levers.
Overall Impressions
The jam was an unbelievable amount of fun, and I’m incredibly proud of the game we managed to turn in. The rating process is looking like it’ll be a fantastically supportive time to get feedback from other game makers and see other rad interpretations of the theme. I’d absolutely do this again, and hopefully can only get even better from here.
