\n"; if ($dueTime != null) { echo "Due: ${dueTime}
\n"; } else { echo "Due: Not Turned In
\n"; } if ($extTime != null) { echo "Extension: ${extTime}
\n"; } echo "

Today's discussion should be spent on two activities, both of which are meant to help you with your "; ?>gameplay specification due at the end of the week. This document is meant to finalize(ish) your mechanics in time for your first software prototype.

For many groups, this document will make heavy use of tables, and we have very "; ?>specific requirements on how to use tables. In fact, this document often has the worst violations all semester, particularly because students do not use tables properly. Therefore, Traci will begin the class with a presentation on dos and don'ts on this document. When this is done, you can move on to the class activities.

Nondigital Postmortem

Before you start work on the document, we want you to think about the lessons that you learned from your prototype and how to incorporate them in your gameplay specification. We are not asking for any extra work here. We simply would like you to have a 10-15 minute discussion about what worked with your prototype and what did not. If you know that a mechanic is going to require a lot more playtesting, we would like you to specify that in your gameplay specification.

One area in which your nondigital prototype is extremely helpful is in setting priorities. We asked you to assign each mechanic a priority, indicating how important it is to make it into the final game. If a mechanic was not working in the nondigital prototype, maybe it is not so important. But if it was key to making the nondigital prototype fun, you should give it a high priority.

Gameplay Specification

After you have the postmortem, you can get started on the "; ?>gameplay specification. We recommend that you spend most of the time on your actions, interactions, and challenges. Design goals can be addressed outside of class (particularly because they are similar to what you did in the "; ?>concept document).

Actions

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. For each action, you should answer the following four questions:

• 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?
• How important is this verb to your game?

Interactions

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. 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?
• How important is this interaction to the game?

Challenges

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. We want you to have several sample challenges 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 or interactions to overcome the challenge?
• How does the challenge involve skill, uncertainty, or risk?

Submission

There is nothing to turn in for this communication lab. Instead, you should submit your "; ?>gameplay specification this weekend.