4 Ludum Dare Mistakes to Avoid


Ludum Dare 41 is just a one week away, and while there are many tip lists out there for surviving Ludum Dare, I wanted to share a list of mistakes I see people make far too often.

About me: I am a Game Developer and founder of Friendly Fish Games. I was previously a professional software engineer at Google and before that at Nvidia. I created Current for LD 39, which later became a released mobile game called Schemata. For LD 40, I created Asteroid Crasher, which was also well received. I am proud of how both submissions came out, considering I did them both in about 24 hours each (I have a bad habit of forgetting about the jams till day 2).

During the judging phase of LD, I stream critical feedback for games, focusing on gameplay, game design, and mechanics. These streams have helped inform this list.

1. Give the player a level select or equivalent

I have judged numerous LD submissions where I play the game for 10–20 minutes and then lose right before the final segment, or sometimes even the halfway point. Then, the game will start over at the very beginning. No one has time for that, especially streamers who want to show your game off but don’t want to show their viewers the same previous 20 minutes of gameplay. What’s more, I’ve played many games that had game breaking bugs that completely prevented me from progressing and seeing the end. You are making a game in 48 to 72 hours; you cannot be certain you will catch every bug.

The solution to all of these problems is simple: give the player a level select or equivalent for your game that allows the player to quickly see all the important sequences of your game. Do not make them unlock levels first. It doesn’t need to be in the player’s face, but providing an option on first load of your game to get to all of the major levels/moments in the game is a smart thing to do for LD. Most players will start at the beginning and play through to the end if they can. If they can’t get to the end for whatever reason, they can skip to where they want to go and you can show off all the great stuff you made. What’s more, if they later want to go back and play a segment they really enjoyed, they can do this without having to play through the parts they may not have enjoyed.

2. Games don’t have to be hard to be fun

“I didn’t want to make it too easy!” is the response I am always given when I play someone’s game and the difficulty curve takes a huge spike for no apparent reason. Games don’t have to be hard to be fun. You made the game, you know how it works, if it is hard for you to beat, it is probably too hard for a LD submission. If you want to have hard content, keep it optional.

It is also important to have a sane (gradual) difficulty curve. Many submissions I have judged simply don’t give the player any time to learn or experiment with the game before a time limit runs out or the player dies, and then they must start back at the very beginning. Teach the player one mechanic at a time through gameplay, and gradually increase the challenge. It is okay for the first level to be easy. Most games will start you off in a sandbox area for you to play with the mechanics. If your game has a time limit constraint, figure out how long it takes you to complete a level, and double or triple that time for your limit.

Good game design allows the player to make mistakes and learn. Look at classic Mario: you don’t fail a level immediately when you get hit by an enemy. If you have a power-up, you lose the power-up and can keep playing. Power-ups are also given pretty regularly in levels allowing the player to make many mistakes and still be able to beat the level. Even games designed to be very challenging (eg. Super Meat Boy) allow the player to make mistakes in the levels, and don’t always kill you when you miss a jump.

3. Use Version Control

Most new devs that I talk to are scared to death of git and other version control tools. I cannot tell you how important it is to use version control, especially for new devs just learning Unity, Unreal, or your game engine/programming language of choice.

Here is the simplest way to think about version control tools: Imagine a button that saves a backup copy of your project that you can restore at any time. Every time you hit the button it makes a new backup and keeps all the old ones. Also, imagine having tools that allow you to see what changed between these backup copies you have made. This tool is great for when you break your project and don’t know why it doesn’t work anymore. You can pull up your version control and look at all the lines of code that have changed since your last working commit (backup). This helps track down problems extremely well.

For those of you afraid of using version control, I suggest trying the github desktop app. It has a nice UI for those who are intimidated by command line tools and can do all the basics that you would need to do with a git repo through the UI controls. The simplest workflow I can suggest for someone new to version control is to initialize the repo the moment you start your project and make a commit every hour. As you get more experienced you will find it useful to do more commits based around specific feature additions or bug fixes. This allows for rolling back of specific broken features instead of all of the work you have done in the past hour, but the beginner workflow is fine for LD.

4. Time Management and Finishing Your Game

This is the big one. It is very hard to scope a project or have an idea of how long things will take. The mistake to avoid here is not finishing your game. You need to know when to stop working on something and cut it. Because I streamed the entirety of the development of Asteroid Crasher, I was able to go back and document how long each step took and break down the development work. This is specific to a one-person team and obviously this isn’t a one size fits all approach but this information should give you a rough idea of how you should plan your LD.

The short of it is that you should plan to spend half of the development time building what a lot of programmer/dev types think of as “The Game”. This is the core engine, mechanics, and levels — all with the most low effort art and sounds you can create or use. The other half of the time will be spent on the “Content” or “Polish”. This includes creating all the visual assets, sounds, music, showing it off to people to get feedback (this is invaluable!), and doing the publishing work (screenshots, description, hosting, etc).

This means after you have brainstormed and picked a basic idea for the game you want to make, you need to take the remaining time you have in the jam and divide it by two. Any features not completed by that halfway point need to be cut. As the halfway point looms, don’t think about making the ideal game you have in your mind, think about the best game you can make with the time you have remaining. Of all your crazy ideas, which take the least amount of time to implement and which are the most special/unique? Prioritize those and cut the rest.

For the art side, if art isn’t your thing, don’t be afraid of making something bad. Allocate a set amount of time to each asset and just make something. This should be a learning opportunity. I spent two and a half hours working on music for Asteroid Crasher, and most of it was spent going through an LMMS tutorial to learn how the software works. Use the LD as an opportunity to familiarize yourself with a tool you’d really like to know better.

If you have time left over after you think you are finished, get your game in a submittable state and show it to as many people as you can. Even more than you have already shown it to! Get all the feedback you can before you declare yourself done. It is okay to ignore all the feedback, submit the game, and go to sleep. But, if you have the energy and spoons, make a decision as to whether it is worth it to make the fix/improvement or if you are still happy with the game as-is. I can say that Asteroid Crasher would not have the sick music transition it has in level 3 if I had not taken this step, but I did not have the energy to improve the art. There is only so much you can do in these jams and that’s okay!

Thanks for reading!

I hope your next Ludum Dare goes great and that you keep these pitfalls in mind when developing your game. For those interested, below is the timeline for creating Asteroid Crasher with timestamps to the stream for the segments available.

Timeline for Asteroid Crasher:

Day 1:

6:00 pm — (Ludum Dare 40 Starts, I am oblivious)

Day 2:

4:00 am — Learn Ludum Dare 40 has been going on for 10 hours by tuning into a game dev twitch stream

4:00 am — 4:30 am — Discuss with wife if I should participate

4:30 am — Decide I’m not participating

4:30 am — 5:00 am — Brainstorming ideas while trying to sleep and land on a game idea I think I could do without spending too much time on it

5:00 am — 2:00 pm — Sleep

2:46 pm — 6:40 pm — Streaming game dev, working on basic engine

Stream breakdown:

0–0:25 — Working on rough art and initial project scaffolding

0:25–0:45 — Working on rough movement

0:45–1:05 — First pass at asteroid movement and having them stick to the player

1:05–1:23 —First pass at asteroid spawner/object pool system

1:23 — Discover asteroid approach isn’t performant

1:20–1:41 — Made performant asteroid system with non physics asteroid and physics asteroid

1:41–2:37 — First pass at mines, still have lots of bugs with blowing asteroids up

2:37–3:54 — Trying to solve bugs regarding blowing up asteroids

6:40–9:00pm — Walking dog, dinner

9:00 pm — 12:30pm — Streaming, working on game

Stream breakdown:

0–1:22 — Working on blowing up asteroid bugs

1:22–1:34 — Changing movement physics, first getting asteroid count on player

1:34–1:47 — Finally fixing the asteroid explosion bug (explanation got audio muted by music choices)

1:47–2:34 — Adding exit gate

2:34–2:45 — Giving viewer feedback on his game

2:45- 2:57 — Working exit gate and basic level 1

2:57–3:20 — Building title screen, and instruction screen for level 1

3:20–4:08 — Working on victory condition logic, resetting position and game after win and tweaks to movement. Also, lots of conversations about programming jobs

4:08–5:08 — Lots of toilet humor, more career conversations, adding more failure state logic and resetting level on failure

5:08–5:19 — Debugging bug in removing asteroids from player on reset. (starts with a snack)

5:19–5:54 — Adding failure state for breaking gate, testing all failure states

5:54–6:11 — Working on second level and level code scaffolding (audio muted for a lot)

6:11–6:57 — Adding asteroid types and level 3

6:57–7:45 — Working on levels 4–7, also tweaked movement more

7:45–8:03 — Adding thank you/credits screen

8:03–8:28 — Adding starfield

8:28–9:03 — Changing asteroid art and picking color pallette

9:03–9:59 — Changing mine art

9:59–11:04 — Changing ship art and adding particles

11:04–11:44 — Adding particles to gate and explosions

11:44–11:55 — Getting frustrated with music and music software

11:55–13:01 — Making sound effects

13:01–15:27 — Trying to make music

15:27–16:51 — Testing, publishing, screenshotting

12:40pm — Start publishing game (still streaming)

12:40pm — 1:50pm — Publishing first draft. Taking screenshots, making pages for game

1:50 pm — Stream end

1:50pm — 3:00pm — Show off game to lots of friends get feedback.

3:30–4:30 — Add music transition and a few final touches

4:54pm — Final build is created and uploaded to itch.io

6pm — See that deadline was extended an hour. Look at adding camera shake then decide it is too much work for the last hour

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store