Gameplay Specification

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 go after the nondigital 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.

Table of Contents

• Document Contents
• Examples
• Submission

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 over the years, so that it does not always have the same format. 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. Describe your character in third person. Do not use second person at all.

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. It is not necessary to have additional objectives. Only add more objectives if they reflect your core vision.

Actions

Actions are the verbs that we talked about in the design elements lecture. 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, we 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).

Again, we are providing you with examples from both this class and 4152. The 4152 examples are particularly instructive because mobile games have to rely more on interactions than on actions.

CupDrakes

The strategy game CupDrakes was the audience favorite among the introductory class games at the the 2022 Showcase. This document makes heavy usage of tables, but they show how to do it correctly. The tables only contain summary information, and details are pulled into paragraphs below. Because they had a crafting system, they also broke up the interactions seection into multiple tables to make it more readable.

Plume

The puzzle platformer Plume was the most innovative game from the introductory course at the 2022 Showcase. The presentation is very clean and shows good judgement on when to use tables (for the actions), and when to use topic paragraphs (for the interactions). This is a good document to emulate.

Pig Life Crisis

The most polished mobile game at the 2019 Showcase was actually Pig Life Crisis. It was a very professional looking puzzle game that showed what you could (visually) do with the CUGL engine.The had extremely simple and streamlined mechanics as you can see in this document. Not all gameplay specifications need to be an exhaustive list of possibilities.

Starstruck

The rope game Starstruck won most polished game at the 2019 Showcase. Like Plume, this document used the right tool for the right job. They used tables for actions, but switched to topic paragraphs for interactions.

Trino

Trino was the the audience favorite in the introductory divison at the 2018 Showcase. 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 throughout this document.

Arcane Tectonics

The puzzle/strategy game Arcane Tectonics was the most innovative mobile game at the 2018 Showcase. Unlike all of the other examples, they do not use tables. They break their mechanics into sections with topic paragraphs. This is a perfectly fine approach; you do not have to use tables. But please use complete sentences if this is how you wish to present your mechanics.

Aiden

The game Aiden is from the introductory class in 2016. 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.

Arc en Ciel

You already saw the concept document for the Spring 2015 game Arc en Ciel. Now you can see how they structured their gameplay specification. As with Starstruck, this specification uses tables for actions, but paragraphs for interactions. The interactions are nice and easy to read.

Submission

Due: Sat, Mar 04 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.

While your concept documents were long, they were light on text. That is different this time. We are looking for details. We expect this document to be 3-5 pages and can even grow as large as 6 pages if necessary.

However, all of this detail needs to be readable. Now that you have gotten back your first concept document draft, you see how we count off for issues with presentation. Expect us to grade this document in exactly the same way.