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 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
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.
Actions
Actions are the verbs that we talked about in the mechanics 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:
Verb | Input | Limitation | Outcome | Importance |
---|---|---|---|---|
Grapple | Click mouse on surface or object | Requires an unobstructed line between character and target (which is in range) | The character now has a rope connecting him to the target. If the rope was previously attached to another object, it is released. | Critical |
Climb | Press up or down arrows | Requires a connection to an immovable surface | The character moves up or down along the rope as appropriate. | Critical |
Swing | Press left or right arrows | Requires a connection to an immovable surface | The character swings back and forth in an arc on the attached rope. | Critical |
Release | Press space bar | Requires a connection to a surface or object | The rope disappears and the character can move freely. | Desirable |
Walk | Press left or right arrows | Requires that the rope is not connected to anything | The character moves left or right along the ground. | Desirable |
Pull | Press down arrow | Requires a connection to an movable object | The object is pulled towards the character, according the rules of the physics engine. | 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 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).
In addition, we made a major change with the mechanics section in recent years). 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 (pre-2017) do not have this format. Take that into account when looking at these examples.
Low-Control Mall Patrol
The 4v1 game Low-Control Mall Patrol was the most polished mobile game at the 2022 Showcase. As an assymetric multiplayer game, they had different actions and interactions for each player. In addition to using tables very well in this document, they have color coded them so that you know which mechanics correspond to which player.
Family Style
You have seen both the concept document and the nondigital prototype for the 2019 break-out mobile hit Family Style. Now it is time to look at their gameplay specification. Note the amount of detail that went into specify collisions, which is a large portion of their gameplay. Compare this document with their actual nondigital prototype.
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.
Cluck Cluck Moose
One more game from 2019, the mobile game Cluck Cluck Moose was effectively a card game, where the chickens had card-like mechanics. Because each chicken had its own unique set of mechanics, they had to have a separate section covering all the chicken types and what they did. Notice that this goes in the Interactions section. Playing a card is an action, but the effect of the card on the board is an interaction. All card-like games should model their gameplay specification after this approach.
Split
The puzzle game Split was the most polished mobile game at the 2018 Showcase. Again the mechanics are very straight-foward. But the tables are nice and they have some simple illustrations to show off the gestures for the various actions.
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.
Canon
The game Cannon was an audience favorite in the 2017 Showcase. Like Split they make use of illustrations in their tables. This time the illustration is in their Interactions table, showing off the various collision types. While not required, this was very informative.
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. The tables in this document do an excellent job of adhering to our writing guidelines for tables. However, this is not a modern document and you should not structure your document like this one (with actions in two different places).
Submission
Due: Sat, Feb 25 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.