|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:
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):
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:
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.
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!).
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:
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.
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.
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.