Assignment 6
Gameplay Specification

Due: Saturday, February 23rd at 11:59 pm

Now that you have finished your concept document, it is time to work on your gameplay specification. This is where you specify your objectives, game mechanics, and challenges. The goal is to help you clarify what your game will look like before you have had a chance to implement anything in your game.

We are still early in the semester, so you should not consider this a binding document. We expect you to change your game mechanics over the course of the semester. In fact, the final product may look very little like what you proposed in your first draft of this specification. The goal of this document is simply to get you thinking about your gameplay now, so that you have some direction for the initial prototypes. In fact, because we moved this document to after the non-digital prototype, you should have already started to incorporate some of those ideas into this document.

As we continually stress in this class, each document has a different audience. The audience for this document is your team. In past semesters, the gameplay specification was part of the course wiki. However, we found that no one ever actually updated their wiki, even as their gameplay changed over the semester. Gameplay changes were often agreed upon informally, either in team meetings or through e-mail. We found that this document was necessary to ensure that everyone is on the page.

Document Contents

The beginning of the gameplay specification should look a little like your concept document. It should begin with the name of your game and your group name, just as before. However, the sections are bit different.

As a bit of a warning, we have retooled this document a bit so that it is different from years past. Be careful when copying the format of the examples below.

Core Vision

This is your high concept statement restated for a different audience. Instead of addressing a publisher who wants to give you money, you are now addressing the other members of your team. You can and should go into more detail. Explain your setting and core vision of the game.

With that said, you should still limit yourself to just a few paragraphs. Do not go into details about the mechanics (that is for later). Just explain the type of game and what the player is supposed to be doing.

Design Philosophy

This is another element to take from your concept document. What is it that makes your game unique, and what are the most important design goals for your game? The difference this time is that we want you to prioritize your design goals. Identify which ones are the most important. If you can drop any of these goals in order to guarantee that the game ships on time, tell us which ones those are.

Objectives

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

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.

You should list all of the actions that you expect to have in your game. 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?

We discuss each of these below.

Input

This is what the player has to do instruct 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.

Limitation

This is 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

This is often the hardest thing to specify. As we said above, each action should have at most two outcomes: the success and the failure. However, when you look at several of the examples below, you will see that they have lots of outcomes for each action. That is because many of those outcomes are the result of that action plus an interaction. In the past, we let that slide because we wanted to encourage the player to think about the different ways the action could affect the world. However, we have now decided that we want these documents to be much more precise, and that actions and interactions should be separated as much as possible.

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 (walking, jumping). 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.

Importance

Game development is a matter of give-and-take. You only have so much time, and you may not be able to implement everything that you want. Therefore, you should always have ranking of what game features are more important than others. For each verb, you should label it as 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.

Please be honest. Every year we get someone who lists a critical or desirable verb as valuable because they think the professor is expecting some verbs to be only valuable. If all your verbs are critical, then say so. So long as you do not have too many verbs, this will be okay.

An Example

This way of listing the actions is different than previous semesters. Therefore, we thought it might be helpful if we presented an example. While you do not have to use a table to display the information, it is a very common way for people to write this document. For example, the following table could be used to present the actions for a rope platformer:

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 game would feel like a Spiderman game in that case.

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.

If you do make a table like the one above, please be sure to follow the writing guidelines for tables. Each column is essentially a bulleted list and should therefore have a uniform presentation. This means everything in a column should either be a complete sentence or have the same part of speech.

Interactions

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

Again, discuss each of these below.

Trigger

The trigger event is just some game state that causes the interaction to happen. This is very similar to input for actions, except that it is not something as simple as a button. Examples of interactions include collisions, proximity, line-of-sight, having too many or too few resources, and so on. You do not need to be too formal here; simply describe the basic event.

Outcome

As with your actions, you should be as precised as possible. What is the immediate outcome of the interaction (e.g. next animation frame)? Is the effect a change in character state like mushrooms that makes Mario small? Or is a change in the character's position?

Avoid trying to guess what happens several animation frames in the future. Those outcomes will be the result of other interactions. For example, Mario growing large again after the mushroom wears off is a separate interaction from growing small.

Control

Interactions are hard to control. You do not press a button to cause an interaction. You have to be in the proper state. Is there anything that the players can do to put themselves in this state? If it is a collision, can they move their character to cause the collision? If it is a matter of resources, what can they do to gain or lose resources. This is often the trickiest part of the specification to write, and it is okay if it is less formal than the other parts of this document.

Importance

This is the same as it was for the actions. However, interactions are more likely to change than actions are. Therefore you will have very few critical interactions. On the other hand, collisions are always important, and line-of-sight is critical to stealth games. Again, be very honest about how important you think your interactions are.

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?

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.

Examples

This is document that has undergone a lot of changes over the years. We are constantly working on improving it. Some of the examples here still confuse the outcome of a verb with the results of combining a verb and interaction (which is why the verbs in these documents have multiple outcomes). Several of them violate the writing guidelines (this document is notorious for the worst violations of the writing guidelines).

In addition, we made a major change with the mechanics section recently. We used to have two sections on actions: one where you described the actions informal and listed their importance, and one where you listed them formally. This completely confused students, so we decided to merge the sections. Some of the older documents do not have this format.

With that said, you should look at these examples as a source of inspiration. In fact, it is a useful exercise to look a the older documents (like Blush and Black Friday) and figure out how to rework them in the more precise language of our current format. Reword the actions to have only one outcome, and present the interactions so that the trigger and outcome are clear. Doing this will help you with your own document.

Canon

The most recent game on this list, this 2017 mobile game was an audience favorite. It is a very straight-forward document. However, not the usage of illustrations in the tables. This can be quite useful when your game relies on non-standard touch controls.

G.M.P.

This 2016 mobile game was another audience favorite. This document follows the modern guidelines for the gameplay specification, so you can make your document fairly close to this one. Note the very clean use of tables in throughout this document.

Aiden

The game Aiden was also from Spring 2016, though it was a game in the introductory class. This is another example of a very straight-forward document with a clean use of tables. However, Traci is not happy that the fire elemental is made male by default.

Division 12

Division 12 is another game from the Spring 2016 introductory class. This document is notable in that Division 12 is a complex strategy game with a lot of building elements. Therefore, they added an additional section to explain these elements before expanding on their actions and interactions. While this is not always required, you may find this necessary if your game has a lot of complicated features.

Over the Arctic Hills

We used the 2014 game Over the Arctic Hills as one of the examples for the nondigital prototype. It is interesting to compare this document to that prototype. In addition, this document does one the best jobs of adhering to our writing guidelines for tables. However, your document will still be different. We no longer want two different sections on actions, and challenges should now go at the end.

Dispossessed

The possession game Dispossessed was created in Spring 2015 for CS 3152. This gameplay specification uses tables for both actions and interactions, but is well-formatted and easy to read. If you want to use tables, this is the format you should emulate.

Black Friday

The action game Black Friday was the winner of the Audience prize at the 2014 GDIAC Showcase. This is a solid gameplay specification, with the caveat that it is different from what we are asking you to write. The standout feature of this document is that it does not use tables, but instead uses topic paragraphs to present all of its gameplay information. This is an acceptable alternative.

Mooncat

The physics puzzler Mooncat is another game from 2013. True to most physics puzzlers, much of the gameplay occurs in the interactions; there are very few actions. This shows off what such a gameplay specification would look like.

Apsis

Apsis is a 4152 game from 2013 that was eventually released as Gathering Sky. It won the Indie Prize at Casual Connect 2014, and was an honorable mention at IGF this year. Like Mooncat, it has very few actions (it has one). While the table formatting could be improved, the descriptions of the outcomes in this document are very good.

Submission

Due: Saturday, February 23rd at 11:59 pm

You should submit a PDF file called gameplay. Again, we ask that the file be a PDF so that we can annotate it in order to return it to you with feedback for possible revision. It is fine if you create the document in a program like Microsoft Word, but you should convert it to PDF before submission.

We expect this document to be longer than the concept document. While most good concept documents are 2-3 pages without the player mode diagram, this document should be 3-5 pages and can even grow as large as 6 pages if necessary. We are looking for detail this time.