CS 4154: Analytics-driven Game Design

Assignment 6
Game Design Document

Due: Friday, September 19th at 10:10 am

The purpose of this document is to keep your project on track. It will include a detailed description of your game and it will clearly outline your plan for the development process. You should add a section to your group Google document. You will want to consult this document throughout production.

Document Format

Your design document should have the following sections.

Game Name

So I can call your group something other than "Group 2". Don't worry, you can change this later if you want.


Write two paragraphs describing the high-level vision of the game. What are you hoping to achieve? What is it that makes your game unique? Why do you think it will attract a broad audience of players?

Keeping your project focused around the goal is critical for both finishing on time and making your game feel cohesive and well-built. Use your goal to keep your feature list as targeted and focused as possible; every feature in your game should contribute directly to the goal. Anything that doesn't is extraneous, and anything that actively fights against the goal will actually make your product seem unfocused and sloppy.

Remember to keep your project goal in mind during the entire course of development. When deciding how important/useful a feature might be, the first question should always be "How does this contribute to the project goal?"


Provide a single paragraph describing the primary player objective in your game. Explain how it fits into your core vision of the game.

If your game has other objectives, mention those in additional paragraphs. For each one, describe how important it is to your core vision and whether it can be dropped if necessary.


Actions are the verbs that we talked about in class. Identify the most important verbs in your game. These verbs should be those that either bring the player closer to achieving the objective, or overcome the challenge. Remember our discussion about the differences between core verbs and verb proxies. A core verb should have an outcome that directly makes progress; it is not a verb that causes another action to happen.

Do not use this section to specify the mechanics of your verbs; that will come later. Simply list the verbs and give a one sentence description of each. For each verb, you should identify how important it is, namely critical, valuable, or desirable. A critical verb has to be implemented, else there is no game. Valuable verbs are likely to be implemented, and their loss will probably require some major changes in gameplay. Desirable verbs are the ones that you are most likely to drop if you run out of time. Be honest. If all your verbs are critical, then say so. Do not list a critical verb as desirable just because you want a verb of each type.

You may want to use a table to present this information. For example, a rope platformer may present its information as follows:

Verb Description Importance
Grapple Attach rope to a surface or release it Critical
Climb Move the character up and down along the rope Critical
Swing Swing back and forth on attached rope Critical
Walk Move left or right on the ground Desirable
Pull Pull an object towards the character Valuable

Note that we do not have a verb for jump. That is because a rope makes jumping redundant. In fact, we have even said that walking is simply desirable, but not critical. If we can swing on the rope, then it is possible to move without walking if we really had to.

The verb pull is another interesting challenge. We do want to make pulling objects towards us the a key part of the game. However, it is unclear whether it is a distinct action from climb. There is a possibility that we might want to distinguish these actions via interations, but have the basic action the same. For example, the actual verb might be retract. If the rope is attached to an anchored object, this pulls the character towards the anchor; on the other hand, if it is attached to an unanchored object, retracting the rope pulls it towards the player.

How do we know whether we want to separate climb and pull? The answer depends on whether we want to be able to climb up when attached to unsecured objects. If so, they must be separate verbs; otherwise, we can replace them both with retract. We are unsure of which choice we want to make yet, so pull is listed as valuable, but not desirable or critical.


It is still a bit early to know all of your challenges. However, if you have some challenges already, this is going to make your gameplay prototype much, much easier. List several samplechallenges in your game. For each challenge, mention the following:

  • What objectives (primary, secondary) does the challenge block?
  • How does the challenge block the player from the objective?
  • How can the player use the verbs to overcome the challenge?
  • How does the challenge involve skill, uncertainty, or risk?

This information is harder to represent in table format. We recommend that you list each challenge as a subheading with a short, one-paragraph description underneath. After this paragraph, answer the three questions above in either bullet (if short) or topic paragraph (if longer) form.

For the last question (skill, uncertainty, or risk), remember the lessons from class. If it is a skill-based challenge, what skill does it use? It is a timing challenge or a hand-eye coordination challenge? Puzzle challenges that do not involve hidden information are also a skill-based challenge. If there is hidden information involved, we show know that. Finally, let us know if there is a random element that makes the player outcome somewhat unpredictable. You do not need to be too formal here; just answer the question the best you can.


Once the actions and challenges are identified, you can focus on the mechanics. Again, you should not to restrict your mechanics to your main verb. If you have multiple verbs, we are interested in the ways that they can interact. Ideally, a programmer should be able to read this section and understand exactly how to implement the gameplay.


List your actions again, as in the previous section. But this time tell you should answer the following three questions (possibly in table format):

  • What is the input to activate this action?
  • What are the limitations (if any) for the action?
  • What is the immediate outcome for this action?

Input is what the player has to do direct the game to perform the action. For example, a platformer may use the space bar, the up arrow, or even the A button on a game controller to perform a jump. A tablet game may require a tap on the screen or a finger swipe. Tell us the exact input or input sequence; if there is more than one input for the same action, let us know.

Limitations are anything that must be satisfied in order for the action to occur. If a limitation is not satisified, the action will fail; the game will either do nothing, or it will perform a second action penalizing the user for violating the limitation. For example, in Sneak Beat Bandit, the limitation is a rhythm challenge; the player must touch the screen when a beat is being played. If the action is performed to the rhythm, the chacter moves one step; if the action is attempted out of beat, the character does not move and the game destroys a clock on the current level.

There are essentially three different ways that actions can have limitations. Sneak Beat Bandit illustrates a limitation that is attached to a skill or timing challenge. Other limitations are determined by the game state. For example, platformers have a spatial limitation where the character must be on the ground in order to perform a jump. Limitations can also be determined by resources, such as the necessity of ammo in order to shoot a weapon.

Outcome is often the hardest thing to specify. As we said above, each action should have at most two outcomes: the success and the failure. This means that the outcome must be specified with exactly what happens when the user performs it. For example, one possible outcome of a jump action is that the character gains an upward velocity. This tells us exactly what happens when we press the jump button; everything else is a result of an interaction. It also indicates to us that this is a physics based platformer. A truly old school platformer (e.g. one that does not implement gravity, and which keeps all velocities constant) might add a value X to the character indicating that it should move upwards for the next X frames, or until it collides with an obstacle.

As a general rule of thumb, if you find yourself listing more than one outcome for an action, figure out what those two outcomes have in common. That is the action. Everything else should be determined by interactions.

Some of your actions will be common to your genre. For example, those of you working platformers may use common WASD keys for movement. Technically, these are multiple actions as each key is bound to a different action. However, if the actions are common and well understood, you can group them together as a single action. We really want you to focus your effort on the unique actions in your game.


We have talked about interactions quite a bit in this class. Interactions are not controlled (directly) by player input. Instead, interactions are a response to a triggering event, such as a collision, a line-of-sight detection, or a resource being acquired.

We want you to list all of the interactions that you know of so far; unlike actions, it is relatively easy to keep adding interactions as you work on your game. Indeed, as you add challenges, you might be tempted to add new interactions. Though you should avoid this, as interaction bloat is almost as bad as verb bloat.

For each interaction, answer the following question:

  • What is the trigger event for this interaction?
  • What is the immediate outcome for this interaction?
  • What actions allow the player to control this interaction?

The trigger event is just some game state that causes the interaction to happen. We gave examples of these above. You do not need to be too formal here; simply describe the basic event.

For the outcome, again you should be as precised as possible. What is the immediate outcome of the interaction (e.g. next animation frame)? Do not try to guess what happens several animation frames in the future. Those outcomes are the result of system feedback (such as in a physics game). The Challenges section of this document was your chance to be informal about this step; now we want you to focus on what really happens. A large part of your prototyping will be making sure that this gameplay allows you to overcome the challenges in the way that you envision.

Your answer to the final question can simply be the name of the verb. You do not need to tell us exactly how the actions control the interaction.

Game Mockup

Include pictures of three levels of your game. You need to show the range of your game: there should be an easy level, a medium level, and a hard level. These pictures should include the user interface. These can be rough drawings done by hand or pictures of your paper prototype (highly recommended!).

Feature Priority List

The reality of any project is that there is always a lot more features you'll want to put in than you have time to implement. Therefore, before actually starting on production, you should triage all your desired project features and sort them by importance, then implement your project features in that order.

You must divide your features into 3 general categories:

  • Must Have: These are features that absolutely must be done in order to meet your project goals, i.e., you would consider your project a complete failure if one of these are missing. This must include all of your "critical" verbs. Typically just your core mechanics and a minimum number of levels, and probably an internal level authoring tool.
  • Should Have: Features that contribute significantly to your goal, but you'd still be willing to say you met your project goal if dropped. This must include all of your "desirable" verbs. You may end having to drop some of these to focus on the must-haves.
  • Could Have: Bells and whistles that make your project more polished and appealing, but do not actually help with your project goal much. This must include all of your "valuable" verbs. Expect to end up dropping most of these due to time constraints.

This list should be constantly referenced and re-evaluated as the project evolves. As you rethink your project focus or discover certain features are taking longer than expected, you should do another triage and prioritization of your features.

Development Plan

Once you have your prioritized list of features, you need to break these down into doable tasks and assign them to project members. We want to see a four-week plan for your development. You need to plan to produce a first prototype in two weeks that includes everything necessary for a playable version of your game with at least five levels. You then need to plan for a second prototype due two weeks later that has all of the intended content and logging. You should give estimates (in hours) of how long you think each task will take to complete. This makes work distribution easier and helps to get an estimate of just how many features you can expect to accomplish. For even better results, during production you should track exactly how long you ended up taking on each task and change future estimates accordingly. Like other sections of this document, you should be reading/adjusting this all the time during production.

Playtesting Questions and Potential Problems

While you hopefully answered a lot of design questions during the paper prototyping stage, you should still have a list of the questions you want to answer once you have a computer prototype working. Figure out the biggest potential problems that your game might have in its computer incarnation and focus your feature priorities to answering those questions as soon as possible. It helps to have contingency plans for each of the potential problems. If a feature ends up failing and not being salvageable, what can you do to still have a fun and engaging game? Also, remember that you have not yet tested the actual computer-based input methods for you game, so interface usability should definitely be on your list of questions to address. You should also include any your ideas for features you want to a/b test during the iteration process here.


Due: Friday, September 19th at 10:10 am

Add a section to your group Google document called "Design Document" with the above information.

This is not the final draft of your concept document. You will have later opportunities to revise your concept. However, you should take this assignment very seriously, as we will use this assignment to evaluate the suitability of your game (e.g. is it feasible, is it suitably difficult, etc.). If your proposed game idea is rejected for whatever reason, then you must address all of our concerns in a revised concept document within one week. If the game proposal in your revised concept document is not acceptable, your group can no longer receive an A for your project grade.

With that said, this almost never happens. We always try to provide extensive comments on this assignment so that your group can be back on track by the revision.