Ludum Dare is a 48 hour and 72 hour game jam. The jam takes place this weekend (April 21st to 24th). The “compo” portion takes 48 hours and is for solo participants. The “jam” portion starts at the same time, extends for 72 hours, and people work in teams. At the time of this post it’s Ludum Dare’s 15th anniversary, and they're using entirely new software to host the event.
I've previously done Ludum Dare 10 times, and after taking a 2 year break I'm going to give it another shot. I've put togther this post to share some of the things I've learned over the years.
Before I jump in, I just wanted to remind you that we make some tweaks to itch.io during Ludum Dare to make it easier to submit and tag your games.
We love featuring games from Ludum Dare after the jam is over. Make your game easy for us to find so we can share it. Check out some games from Ludum Dare 37.
On the game page you'll find a button to quickly tag your game and provide your submission URL.
You can embed any HTML game you've uploaded to itch.io on Ludum Dare by going to Edit Game > Distribute > Embed game. Just copy the embed link into the Ludum Dare submission page:
Although I might not be the best game designer, I've done Ludum Dare quite a few times. Each time I've learned new things. Here are some tips that have been valuable to me:
48 (or 72) hours is not a long time. Get ready to abandon many of your ideas for the sake of getting the game out. I think it’s more important to try to finish a project than to start something you plan to finish later. Why? You have plenty of time outside of Ludum Dare to start the next big thing. Ludum Dare is your time to get experience finishing something. You'll get a lot more enjoyment out of the experience if you have something you can submit, and you'll be able to rate and comment on other people’s submission.
Regardless of whether it’s your first time using a set of tools, or you're reusing what you already know, you should spend some time preparing.
Know the basics about drawing things on the screen, importing assets, playing sounds, and responding to user input. Code a test project before the jam so the fundamentals are fresh in your memory. You'll be grateful for not wasting precious time trying to debug something that you could have figured out ahead of time.
Make sure you have a streamlined way to access documentation. If you think your internet connection might be spotty then download a local copy of any documentation you might need. If you're in a coworking space the internet might be slow, so you'll be happy to have a quick way to access reference APIs. (In the past I've downloaded the entire Love2d wiki for quick access). It’s frustrating to know you want to code something but you don’t know the function call because the docs aren’t loading.
Ludum Dare is about battling the clock to build a functional game. It’s easy to get caught up putting together a certain feature or component. For example, in one of my previous entries I wanted to build a handful of different enemy types with respective AIs. I ended up spending so much time on them that I didn’t have time to put graphics together for them. I had to scrap the additional enemy types and merge the code I wrote into existing ones.
I like to encourage what I call breadth first development. Don’t go deep in any one path. If you spend all 48 hours making an enemy, but never coded the player then all you'll have is a tech demo, and not a game.
Generally, you'll have a better end product if you dedicate a chunk of time to each core component. Make a list of the things that should be worked on . If you know you've been ignoring one during the jam then switch over to it for a bit. Here’s an example list of things I might block out time for:
Note: I would only come up with this list after I've already decided on my game design & mechanics.
The time you spend working is the most important time you have during the jam. Do not make any other plans, you will only put yourself at a disadvantage. I know in the past I've thought it would be cool to hang out with some friends midway through, but it always ends up taking time I could have spent polishing the game. If someone wants to hang out, just tell them another day. Additionally, avoid drinking, it just slows you down. If you do need some relaxation time consider taking a break and doing nothing. You'll be mentally prepared to get back to work after the break, instead of being distracted by something or someone else.
For many participants, sound is generally an afterthought, something that is either left out or is mostly missing. I think this is a huge mistake. Using tools like sfxr it’s really easy to make simple 8-bit sound effects.
I've remember many “Ah ha!” moments when I've added sound effects to a game, and it went from something that felt like a tech demo to something that felt like a game. Having a noise when your player attacks, bumps into something, blows up, or gets damaged can make the world come alive.
Adding music is also a huge plus, but it’s a bit harder to do if you don’t have the experience to create it. There are many procedural music generation tools online that can help you out though.
A big advantage of having the compo and jam start at the same time is if you decide you won’t finish your game in time you can still submit 1 day later as part of the jam. Don’t be ashamed, you'll be more proud of finishing something. As a solo participant, I always aim to finish for the compo, and only decide to go to jam on the last day. Don’t make the decision before the last day if possible because it might affect your motivation to work.
Make it easy for someone playing your game to figure out how to actually play it. The Ludum Dare submission page lets you write info about your game, but it’s common for people to download many games up front and close the page. They're probably not going to be reading your instructions when they start your game. If they can’t figure out how play it then they might skip rating it, or give it a bad score.
The easiest way to avoid this is to add a title screen that has clear instructions. If you have time, consider implementing a tutorial directly into your game. (Some games use this as a primary mechanic) A game’s onboarding can have a huge impact on how people perceive it, and may encourage them to play a bit more instead of moving onto the next one.
A timelapse is a recording that has a very slow framerate, commonly 1 frame every 10 to 20 seconds. This lets you compress an entire weekend into a 10 minute video. Set up software to take a screenshot of your desktop every 10 seconds and save it to a folder. If you have a webcam you can composite a snapshot from it on top.
After the jam is over you can convert all the frames into a video. I really enjoy going back and watching the timelapses I've created since they can instantly remind me of the experience I was having while making the game. They're also just fun to share. Even years later, I really value them.
You can use existing software to help you make the timelapse. On Linux I use a modified version of gLapse. If you have recommendations for other platforms leave a comment and I'll put them here.
Streaming development live is a fun way to engage with people as you're building your game. Personally, though, I tend to avoid streaming.
My biggest problem with is that it takes up your attention. Most streamers will want to interact with their audience, and that means they aren’t working on their game. I try to value my time and focus on development. I prefer creating a timelapse over streaming. A timelapse doesn't distract you and doesn’t lose relevance after the jam is over. It’s very unlikely you're going to want to go through 48 hours of video afterwards to pull out good parts, so steams are generally for the people who happen to be online that weekend.
Try not to stress out. As a game developer, doing Ludum Dare is a great way to grow your skills. It’s fine if life happens and you can’t finish your game, or your idea is too big scope for a weekend. You're still going to get some valuable experience regardless of what the end result is.
Thanks for reading