Article: Game Jamming 4 Rapid Development

Would you prefer to listen to the post? Download a recording here!

You've got an extensive design document, a few scribbles on your idea board, or something in-between. Now it's time to make the game.

We call this game development for a reason. Games don't spring fully-formed from a genius design straight into the hands of players. Development involves twists and turns, risks and failures, serendipity and deep reflection.

Whatever your design says now, it will differ from your final game. But that's okay, because you will (at least try to) change it for the better.

(1) Start with the beginning and end.

The best games are complete experiences. Whether is a feeling delivered through narrative, a prototype of a mechanic, or a journey over several levels, an unexpected and sudden ending can sour the result.

To avoid this problem, develop the beginning and end of the game first. Start with the smallest possible game flow, then expand from the middle. That usually looks like this:

![]({.wp-image-385} \

Your game may have multiple endings, several ways to achieve a game over, a pause menu, etc. but this is the bare minimum flow. One could even argue to get rid of Options if necessary.

Start by setting up bare-minimum scenes to achieve this flow. Think of it like an outline. You can even save the result as a template, then skip making it in your next game jam, if this falls within the bounds of the rules.

Then, start building. Add content to each of the pieces. Since you already have this "outline," like magic, your game works from start to finish. Regardless of how little content your game has, no one can claim it's incomplete, because it has these pieces.

Finally, flesh out the center with core mechanics and levels. Build on those with media and narrative. You're well on your way to creating a full game!

(2) Test early, test often.

Rapid iteration is the name of the game, and there's no point in creating rapidly without knowing the results. Test on every small change. This is good not only to make sure the code is working, but to make sure the design is working.

Sometimes, playing the game can spark new ideas. The more often you play it, the more likely this will happen. You can also think more clearly of upcoming additions or changes in the context of the game's current state.

Making a ton of changes without testing the game can be dangerous. Maybe one of the features you added works on its own, but with both of them in there, the whole thing falls apart. Make very small moves between testing.

Create a final build long before the jam ends. Sometimes, the final build can differ from a testing environment, whether it's a debug mode or run in an editor. Particularly if you are planning a mobile or web build, make sure these versions work identically to the stand-alone versions, because moving to a different system can introduce new bugs.

Jams are a crunch for time, but if you have the chance, get someone else to play your game. This could be a friend, relative, or random stranger on the internet. You can trade games with a fellow jammer to get early feedback in addition to testing - and possibly make a friend in the process.

(3) Don't be afraid to throw things away... but keep your trash.

Nothing that happens during the jam is set in stone. If a mechanic isn't fun, or it doesn't fit other mechanics, or it breaks systems and you don't have the programming knowledge to make it work, get rid of it.

However, always keep what you've done. If you finish everything else, you can cycle back to the "trash" and see if there's a way to fit it back in, once everything else is in place. The final game may give you new perspective.

Take a look at the website The Cutting Room Floor. It offers fascinating insight into pieces of games developers left behind after scrapping ideas, mechanics, or levels. If these are the pieces still left in the disc or cartridge, imagine how many other things they threw away in the development process.

(4) Remember: your design is always flexible.

Anything written in your design doc or notes is free for changing. Sometimes these changes have a ripple effect and you need to correct a lot of pieces to accommodate a change, but if it's for the better, go ahead and do it.

Games are immensely complicated and involve several interconnected systems. The design doc or notes were your initial run at the idea, but once it's working, try it out and see if it's fun. You may be surprised to find ideas that sounded good on paper are dull and boring, or ideas that sounded silly are the best part of the game.

Remember to keep up with your documentation or notes. Although it takes time to rework the written design, you'll save time and confusion later when you refer to it during development, especially in the later crunch stages of the jam.

(5) Instead of stopping at hurdles, use them to your advantage.

During the jam, a situation will Inevitably arise where it feels like nothing is coming together and you made a terrible, fundamental mistake in your design. This might be some difficulty with the technology, a realization that the scope is much larger than you initially believed, or life events that limit the amount of time available to work on the jam.

Use these to your advantage. Steer the course to use the limitation as a creative music. Many times, a problem in the game that looks like a bug can become a mechanic instead.

Maybe you wanted a double jump, but the character jumps infinitely and you can't figure out how to fix it. Or enemies walk through walls that should be solid. Consider making these intentional mechanics in your game. Allow the "problem" to open up new possibilities. In other words, "It's a feature, not a bug."

My game Elemental Puzzle has a mechanic that came from a bug in how I had programmed the elements to destroy each other. The original plan was for opposite elements to destroy everything in the row or column they touch, but it turned out that an row of elements on a matching crystal would only clear one at a time. For instance, a fire element on two water elements touching a water crystal would only clear one of the water elements. This turned out to be a pivotal mechanic in the game.

If something is taking longer than you expected, try simplifying. Use fewer colors, smaller graphics, or simple shapes for art. Make one short music loop instead of unique music for each level. Repeat sound effects. See if switching from 2D to 3D (or vice versa) will save you time.

For many jams, you can also consider free-to-use assets from the internet. They may not match your vision, but think of them as temporary placeholders that you can replace in a post-jam version.

Next Steps

Once your game is a complete, playable experience, it's time to package and upload. We'll look at how to do that in the next article, including a checklist for making sure the game is ready to head out into the wild.