The next Ludum Dare session is coming.
Ludum Dare, also known as LDJam, or LD, is one of the largest worldwide game jam events.
Within a few days, thousands of developers will release thousands of games. They can join in the jam mode, working as a team, with 72h to build a game, and being able to re-use some assets. Or they can choose to participate in compo mode, aka, making everything alone from scratch in 48h.
The announcement of the theme launches the event, and the clock starts, you have to submit your game before the clock stops.
I love game jams; it's a demanding, messy, but always vibrant experience. I do prefer the jam mode. We regularly participate will a small crew, a few jam veterans, welcoming at least a new member at each session.
What can we learn from this kind of hackathon?
What can inspire us when getting back to our day to day work?
Preparation and communication
When starting, we dedicate the first morning of the jam to brain-storm on ideas to fit the theme. We draw on a whiteboard; we don't touch a keyboard.
We're looking for an idea, a concept, a game design we're comfortable with as a team, that will keep us excited for the upcoming days.
Each teammate says what he'd like to do, game design, programming, graphics, sounds, etc. We can then pick a concept fitting what each of us we'll enjoy doing during the upcoming days. We also write down our availabilities; someone can join for half a day, one day, or three days.
Once we picked our concept, we dedicate the rest of the first day to get a working prototype, validating our idea. And during the jam days, we'll over-communicate on the progress. Doing a break together every few hours, to assess our progress, looking if someone needs help on a task.
Energy management
The exercise is very demanding. The first-time jammer often falls into the trap of coding 24h per day.
This desperate attempt to use each available minute to deliver value quickly burns you. The first day is ok. Then you struggle with even the most simple stuff.
Balancing your energy and doing proper breaks is critical. Sleep for real, make time to eat correctly. And for our summer sessions, the game jam barbecue became a tradition for our crew.
Hard-core prioritization
You have only a few days. Prioritization, hard-core prioritization is a must. But keep in mind that you need to deliver a great experience to your users. Storytelling. Game design. Mechanisms. Feedback.
You can quickly get trapped into something looking simple to do, but that will take far more time than expected, too much time. Not part of your core design?
Stop it, trash it. It's an excellent scoping exercise.
Be laser-focus
Given the time frame, you'll not be excellent at each aspect that makes a great game. Our very own trick is to pick one key point, one core aspect, and be laser-focus on it. We can choose the atmosphere, the narrative, the graphics, etc.
We often pick one aspect where the first-time jammer in our crew is comfortable with or can contribute. For instance, we made a game based on the audio atmosphere when we made a jam with a sound engineer. Or a game based on the narrative with a new jammer who is an actor.
By locking this constraint, we make sure everyone in the team will push on this key differentiator. You can't be the best in all categories, but you can deliver an intense experience by picking your fights and being excellent on your differentiator.
Collaboration & team-work
It can be very tempting to parallelize all the tasks, and for each mate to build a different piece. We noticed it's far more efficient to do some pair programming, at least, on foundations. Or to have one mate being always available to join and give a hand to any other mates. It becomes easier to parallelize the work once the foundations have been built together, with a shared understanding.
Polishing
What makes a great experience is the level of polish. It seems counter-intuitive in a game jam, but we dedicate 30% of our time to polish the existing mechanisms and features, usually the third day of the jam.
Adding small user feedback, fine-tuning the sounds effects, the fonts, the graphics effects. Making sure the user onboarding is right, the difficulty well-balanced, that the game goals are clear.
Technical debt
You ever heard or suffered from technical debt? A game jam is a fertile context to experiment on tech debt. Your jam team will quickly turn into an efficient tech debt factory. While rushing to add capabilities, by cutting every single possible corner, you'll soon suffer from your messy code.
And this, only after one or two days! Which is fine, you'll never touch again this codebase (hopefully). The aim is to ship a game experience, a polished prototyped, not to build a game you could sell.
Accidental successes
Sometimes magic happens.
During a jam, we were building a platformer. Our hero wears eyeglasses, and a bug with sprites integration led to having only his glasses floating in the air. We had a lot of fun with this bug. And we discovered we could make something cool with it.
We changed our platformer to include sections in the dark where you see only the glasses of the hero. It was so good that we pivoted our concept entirely to make it the central aspect of our game, and we adapted the storytelling accordingly.
As in any project, unexpected things will happen, and a problem can become an opportunity. It could have been a boring game, and it became a unique concept, a blind platformer, on which we had great feedback. (here is the game)
Last words
I highly encourage you to try to participate in a game jam once.
It's an exceptional experiment. It gathers all the emotions you can feel when building a product but packed within a super short time frame. The real reward is not into what you ship at the end but in the journey of trying to do it.
Cheers to my jam mates! 🎮