Blasteroids is a game made for the Godot Wild Jam #71. We had 9 days to work on a game with the theme "Unexpected Consequences". During the jam, we lost a lot of time on ideas we couldn't develop and therefore we had to scrap a lot of progress. The ideas we came up with were:

• A Phoenix Wright-like detective visual novel about a time traveller who altered the course of time in the past (Initial idea)
• A Papers, Please-like game where you have to check who is allowed access to a time machine (2 days into the jam)
• An asteroids clone with the ability to blow up the UI, which became Blasteroids! (6.5 days into the jam)

We learnt a lot about project management from the rocky development for this jam. This devlog is meant to show the main points we've learnt from this jam so you and your team won't fall into the same pitfalls!

1. A good plan is half the work

So our first idea for the game was that visual novel. We worked on the implementation of the core mechanics and created some concept art, but after two days we had to drop the idea altogether to go with another. Why? Because the team roles weren't clear to everyone and we ended up without a writer. If we talked this through at the start, we would have known that this idea wouldn't work and we'd have 2 extra days for the jam.

It sucks to face sudden oversights during the development of your game. Maybe your game requires more art than you thought, or a simple sounding game idea turns out to be much more difficult to execute. Therefore, it's worth spending time to plan out what you need before tackling the game itself. Some notes you can make for yourself are:

• Determine who will do what during the jam
• Determine whether the game idea you have is possible with your current team members
• Check how much time everybody has available to spend on the jam
• Determine what tools and documents will be used
• Write down an estimate of how many things (items, npcs, dialog) will be in the game max to set a scope

It's also good to leave a margin for error. If you think you can draw 10 sprites per day, don't expect that you will be doing that every day throughout the jam. Life will always get in the way, and your sanity will thank you.

2. Keep ambiguity low

The Papers, Please-like game sounded like a fun idea on paper. Having stuff change on your desk if you let the wrong people alter the course of time? Brilliant! I was drawing some concept art for the first draft of the game. All I could come up with was a top-down perspective of a desk with some papers and some props that we might turn into gameplay later. It was enough to get something going, but it did not  scream 'futuristic' or 'time travel'. Hell, it didn't really scream 'fun' either. Oh well, I thought, we'll come up with something later!

We  did not come up with something later.

We also thought about the puzzle mechanic for the game. For what reasons can people be sent away? Are certain items illegal? How do we determine what is illegal? Is it too easy to tell if their clothes are too futuristic for the time they travel back to? What clues are too hard or too easy to figure out? We had... documents, I guess, but we had no idea with what information to fill them with. Well, I'm not sure if any of these ideas work, but better ideas will surely pop up later!

Not to spoil the movie or anything, but you can expect what happened. No ideas popped up. 

As a result of keeping these important gameplay elements ambiguous because "we'll come up with better ideas later", we had no idea how to steer the gameplay halfway throughout the jam. It would have been better to think this through at the start and determine that we had too little ideas to execute this sort of game. Aside from that, thinking deeper about your idea at the start shows whether the game is executable and fun enough. Of course, it's important to give ideas some time to develop, but if it's hard to answer questions about your game now, there's a high chance that they will be hard to answer later in development as well. Rather you spend 4 days on an idea that you feel confident with than 9 days on an idea whose accessibility is up in the air.

A way of preventing ambiguity is through storyboarding or creating simple concept art. Talk an idea through while keeping an art program open in the background, or hold a sheet of paper in front of you. Can you fill the canvas in with a game/story that looks fun to experience, or can you comfortably fill in information without wanting to procrastinate on it? No? Then it might be better to go for a different idea.

3. The Sunk Cost Fallacy

5 days into the jam and with 4 days left to go, we figured that the Papers, Please-like game just wasn't fun to play. Nor was it fun to work on. It felt more like an administrative simulator. Aside from that, the game looked bland, we still weren't sure what information would show up on the documents and nobody in the development team had any motivation left to keep working on it. The choice was either to change course to another idea or try to see if we can make something out of this game. We went with the latter option at first to see if we can keep any of our current progress, but the motivation for it dwindled quickly. Afterwards, we threw in the towel and went with a simpler idea. We're glad we did that.

It's hard to give up 5 days worth of work. Wanting to continue work on a project that has a low chance of succeeding because you've poured so much time and energy into it is called the Sunk Cost Fallacy. It is known to be very, very demotivating. It's not bad to think about ways to see how you can fix a project if you're not sure about the way it's headed. Throwing in the towel too quickly is a thing as well. However, I can't describe how much weight is lifted off your shoulders when you can let a project go that has weighed you down and work on something more fun. You might be able to use those assets in a future project, who knows?