Short Game Design Documents

A short game design document will help us overcome writers’ block. A well-structured, short design document can help us finish our game. The design document for the Dungeon Crawler example in this game is in Design a Dungeon Crawler.

Let’s start with something that can help defeat writer’s block: making notes.

Make a note of each idea

As we play and create games, we’ll find ourselves brimming with ideas. Inspiration often hits at the least convenient moment: in the shower, at work, or while we’re trying to sleep. Keep a notepad, physical or virtual, always handy. When ideas pop into your brain, jot them down. You only need enough to remember what you were thinking about. “Pong, but with lasers” is a memorable note. “Metaphysical Monsters” is a great title but probably needs a little more commentary to remember what it means when you look back on your notes.

Use whatever note-taking system you like. From EMACS Org Mode to Evernote, Google Keep to Microsoft OneNote, there are plenty of note-taking systems to try. It doesn’t matter what platform we use. Even a pad of paper and pen is fine.

It’s a good idea to keep notes organized by game idea. A top-level note with the basic game idea and notes underneath for when we think of features is a good model. Consider how important they are to the basic game idea. For example, is our idea a core concept of the game or a fun visual effect to accompany another idea?

When we feel the urge to create something but aren’t sure what, we can open the corpus of notes and find something that sounds fun to write. Game idea notes aren’t a design document or plan. You’ll often find that you can combine ideas from different sets of notes—many of the more interesting game ideas start by pondering the combination of a few genres or ideas. Before turning notes into a design plan, let’s consider what our plan should accomplish.

Why we need a design document

A design document serves several purposes:

• It distills the essence of the game we want to make into an describable target.

• Compiling our notes into a more formalized document makes our brain ponder how the game actually works, rather than just a conceptual end-product.

• Creating a design document helps us determine which features are essential and which are optional.

• A well-structured design document breaks tasks into bite-sized chunks. So, when we find time to program, we know what to work on and can feel like we accomplished something in the available time.

There are many opinions on what’s required in a design document and what it should look like. What we need depends on the scale of our project:

Working Alone	Small Team	Working for a Studio
A short game design document	Keep everyone moving in the same direction.	Very detailed
Keep it simple.	Track sprint progress.	Producers, make it for you

This course is targeted at beginners, so it’s assumed that we’re working alone or with a friend. This gives us a lot of freedom. Our design document can be very informal, containing just enough information to remind us of what goes where.

Designing documents are alive

Design documents are alive We aren’t forced to adhere to what we plan in our game design document. Instead, these are living documents, edited constantly to match reality and our changing plans.

Let’s explore what goes into a minimalist, focused design document.

Design document headings

Keep our design document short. We need a few basic headings and some rough estimates of the tasks required to realize our idea. This section will walk through the creation of a focused design document, intended to help keep us on track as we make our games.

Naming the game

Names are difficult, and it’s unlikely that the first name we pick will be the final name of our game. It’s okay to start with something generic and come up with a fun name later. Start the design document with our working title on the first line.

Short Description

We should start our design document with a short description of the game. Flappy Dragon could be described as a Flappy Bird clone. A generic roguelike might describe itself as a dungeon crawler with procedurally-generated levels, monsters of increasing difficulty, and turn-based movement. The key is to keep it short. It’s similar to an elevator pitch in marketing; this is how we’d describe the game in passing to a friend who wants to know what we’re working on.

Story

Not every game has a story. Nobody really knows why Flappy Bird desperately needs to fly east. For a fun, simple game, it doesn’t really matter. If our game has a story, include a summary of the story. Otherwise, we can skip this heading completely.

Basic game loops

Games tend to feature a design loop. This describes the actions the player takes and the impact they has on the world. Flappy Dragon’s loop is very simple: the dragon flies east, avoiding obstacles. A turn-based dungeon crawler loop looks like this:

1. Arrive at a randomly generated dungeon level.
2. Explore the dungeon.
3. Encounter monsters and either fight them or run away.
4. Pick up any items along the way.
5. Find the level exit, and repeat from step one.

Our design may feature more than one loop. That’s okay, but it can be a warning sign that we’re making an overly-large or convoluted game. A real-time strategy game features a few loops:

1. Locate resources and task workers with gathering them.

2. Construct your base, considering resource use, unit creation, and defense.

3. Construct your armies.

4. Locate the enemy’s strong points and task your armies with their destruction.

Minimum viable product

It’s very easy to think of general ideas for our game. Whittling them down to the essentials can be hard. The smallest program we can make that fulfills our basic design goals is the minimum viable product, or MVP.

The MVP is our initial target. Build the chunks of our MVP and, once it’s together, we have a playable game. It may not be a finished game, but it’s something we can be proud of. It’s also something we can share with friends for feedback. We often don’t know whether an idea is a good one until we try it. Focusing on the MVP saves us from wasting many hours polishing what turned out to be a fun-sounding idea that just doesn’t quite work in reality.

Stretch goals

Once we’ve finalized our MVP, list all other features we’d like as stretch goals. Try and rank them by importance; we may not get to all of them. Ideally, we want to pick goals that fit within our overall design and can be added in bite-sized chunks. Completing small features incrementally is far more satisfying and realistic than focusing on large-scale goals that may take weeks or more to accomplish.

Skip through the forest, don’t march to Mordor

If you’ve worked in the software industry, you’ve probably suffered through a death-march project. Everyone’s exhausted, and the more hours you put in, the further away you feel from a working product. That’s not fun, so try not to inflict it upon yourself. If a goal is causing you stress, cut it from your design. This is especially true if you’re working as a lone hobbyist. If you hated making it, your players will probably notice and hate playing it.

We don’t need it

If we want to finish our game, be brutal. Move everything that isn’t in the minimum viable product into a stretch goal. Once we start enjoying game development, we’ll find ourselves coming up with many ideas. Some ideas are good ideas and some aren’t. Note them down, but before adding them as another task on our game development document, ask yourself, “Do I really need this?” The sad truth is that beyond our core mechanics, we probably don’t need it. If it looks like an add-on we can make, add it to our stretch goals. Otherwise, keep it in your notebook; maybe we can incorporate it into version 2.0, or into another game entirely.

Sprints and motivation

Now that we have our top-level design document, it’s time to turn it into a plan. Divide ideas into bite-sized chunks. Does our game involve the adventurer wandering around a dungeon? That’s a good-sized chunk: make a basic map and move around it. Is our game turn-based? Setting up the turn structure is a good sprint.

As we come up with sprints, consider dependencies. We can’t implement combat until we have a map, an adventurer, and something for them to fight. Health potions aren’t useful until the adventurer has a health statistic. Explosions in games are cool, but they require a target, a reason to use them, and a way to represent the damage they inflict.

Keeping sprints short is an important motivator. A short sprint, preferably one we can finish in one or two sessions, gives us a solid feeling of progress. We can play our new feature and be proud that we made it. This is really important. Avoid the pattern of writing everything and then integrating it together and not seeing any meaningful progress for months. There’s a high risk of becoming disheartened and losing interest in the project.

Don’t be afraid to admit when something isn’t working and abandon some code, but keep it somewhere, even if it’s tucked away in a Github branch. We may think of a use for it later.

Long-term benefits of design

Keeping notes gives us a ready pool of ideas when we feel like writing some code. This can help avoid writer’s block—there really is nothing worse than staring at an empty text editor wondering what we should try to create, rather than creating it. Take an idea, create a quick design idea, and throw together a prototype. It doesn’t matter if it’s terrible. Everyone started by making terrible games. The important part is that we tried to make something and learned along the way.

As we become better developers, projects both abandoned and completed start to add up. We develop experience and a better feel for what will and won’t work through this process. We also begin to develop a body of code to draw on. If our game idea requires something from an old project, there’s nothing wrong with borrowing it.

Assess yourself realistically

If you visit game development forums or Discord servers, you’ll quickly learn that everyone has some big ideas. Every new developer proposing their massively-multiplayer online game or huge role-playing game, or pitching ideas for massive, big-budget projects is greeted by a chorus of “Why don’t you start with Pong?” Despite appearances, the experienced forum dwellers usually aren’t being mean. You really do need to start small and gradually build up your experience. That’s why this book starts with Flappy Dragon; you can complete it in a single chapter and build foundational knowledge along the way. One day, you and a large team may be ready to make the next World of Warcraft. Starting with a project of this scale will almost certainly follow an all-too-familiar cycle: initial enthusiasm, despair when you discover how hard it is to write good net code for thousands of players, and a decision to either write something smaller or quit game development altogether.

Keep the notes you make describing your dream game. Just be aware that it remains a dream until you’re ready for it.

Fail fast

When we design a novel game, there’s a chance that it will be missing one vital element: fun. The problem is, we won’t know that until we’ve tried it (although experience helps). Create an ugly prototype that exposes the basic game loop of your idea and show it to some trusted friends.

If the core game is a good idea, it’ll quickly become evident when they enjoy themselves. If the core idea turns out to be a dud, that’s okay, too. File it away in your notes as a nice idea, but move on. You may find a use for it as a mini-game inside something else in the future. Worst case, you’ve learned not to try that exact idea again.

Don’t stress about deadlines

Note: I love deadlines. I like the whooshing sound they make as they fly by.

— Douglas Adams

In making games as a hobby, don’t get hung up on deadlines. There’s nothing worse than a fun project making you miserable because you feel you are late on a task. If you use a project management app, give yourself plenty of time and, if you miss a deadline, reschedule.

Between making notes and the short design document template, we have everything we need to plan smaller game projects. We don’t need to spend hours writing a massive design tome, but a quick outline at the beginning can help keep us on track to finish our project.