|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.
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:
Again, discuss each of these below.
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.
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.
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.
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.
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:
Unlike the previous communication lab, this exercise should not be limited to your core mechanic. Instead, you should give a comprehensive list of the challenges that you expect (so far) to have in your game.
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.
This is document that has undergone a lot of changes in the previous 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 this semester. 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 this year. In addition, we are now asking you to rate the importance of your interactions, which we did not do in previous semesters.
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 Reflexio) 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.
You already saw the concept document for the Spring 2015 game Arc en Ciel. Now you can see how they structured their gameplay specification. Not that this specification uses tables for actions, but paragraphs for interactions. The interactions are nice and easy to read.
You have also seen the concept document for the Spring 2015 game Dispossessed. 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.
Short Circuit was a puzzle platformer in Spring 2014. As a slightly older game, is similar to yours with a few minor details. In particular, we no longer want two different sections on actions, and challenges should now go at the end. With that said, this document does the best job of adhering to our writing guidelines for tables.
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.
The side-scrolling shooter Pirates of the Stratosphere was the winner of the 2013 GDIAC Showcase. While not perfect, the gameplay specification for this game is one of the best that we have seen so far. It has a good separation between actions and interactions, and is fairly detailed. Unfortunately, the tables do not follow our writing guidelines, but everything else is solid.
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.
The color-based platformer Blush was the winner of the Spring 2011 GDIAC Showcase. One of the reasons it did so well was this document. They locked down their game mechanics early and developed a very detailed specification. The approach is not what we are looking for this semester (they mix interactions in their action outcomes), but the format is solid.
The reflection-mechanic platformer Reflexio was the winner of the Winter 2011 GDIAC Showcase (the games courses were taught both semesters that year). Unlike Blush, this document went through quite a few significant revisions before they completely figured out their gameplay. This document is the version from the end of the semester. We include this document as a warning. The if-statements in the outcomes are a clear indication that it is mixing actions and interactions inappropriately.
Due: Saturday, February 27th 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.
However, all of this detail needs to be readable. When we evaluated the communication lab, we were only looking at the content of your mechanics, not the presentation. This time we will grade the presentation as well. 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.