Assignment 5
Nondigital Prototype

Demo: Monday, February 18th at 10:10 am
Due: Saturday, February 23rd at 11:59 pm

In class, we talked about the importance of developing prototypes as part of the game design process. For this assignment, you will embark on your first prototype: the nondigitial prototype. This prototype should capture your core gameplay mechanics and give you some insight as to how your game will play. Other than the requirements spelled out below, we are giving you very little direction on this assignment. Game design is a creative process, and you do not become creative by us telling you what to do. So surprise us.

With that said, you should not worry if the final game for this course is nothing like this prototype; that is what iterative design is for. All we care is that you make a good-faith effort to come up with a reasonable prototype, since the earlier you are playing your game, the better your game will be. Your grade for this assignment will be based upon the clarity of your presentation and how easy it is to understand the rules. You will also be graded on whether your prototype makes a serious attempt to address the requirements below. You will not be graded on whether the prototype is "fun", or how innovative it is.

We strongly recommend that you read Chapter 7 of the text (Fullerton) before starting with your design. The prototyping chapters of the text are some of the best reasons to own the book. They cover a lot of ideas that we could not hope to cover in-class. Hopefully they will help guide the design of your prototype. In addition, the lecture on gameplay modeling the week before this assignment is due should give you some helpful ideas.

Creating a Nondigital Prototype

The primary purpose of this prototype is to test a gameplay mechanic to see whether it is fun, or at least interesting. It needs to be a gameplay mechanic that can be modeled discretely. Every year, we get some group that attempts to model a physics or skill challenge in their game (e.g. throwing a bean bag). Avoid these types of prototypes. They look cute, but you will learn very little about your final product.

The lecture on gameplay modeling should help give you some ideas on how to craft a nondigital prototype. With that said, here are some hints to help you get started.

Discretize your game mechanics

Recall that a game mechanic is a combination of verbs and interactions (though a verb by itself is an acceptable mechanic). Even in a non-digital setting, a game mechanic may require multiple steps. For example, in Chutes and Ladders, you perform your move first (e.g. the verb) and then change your position based on the presence of a chute or ladder at your current square (e.g. the interactions). This design-style is quite common in traditional board games; these interactions are referred to as "board elements". You should use them as inspiration for how to model an interesting mechanic.

With that said, the key feature is that your non-digital prototype should be discrete. Spatial mechanics should be implemented on a discrete grid or graph. If you have a team member with some experience with table-top RPGs, use this person as a resource to help you model. If your mechanics are complex enough that they involve multiple interactions over time, you may wish to consider using action points to condense everything into a single action or turn.

A related issue in discretization is timing. A strict turn-based approach is often best for a non-digital prototype. However, it is possible to use an asynchronous approach, such as in the card game Spit. In this style of play, each player takes discrete actions, but the players do not need to move synchronously with one another. If you decide to have a prototype that works like this, we recommend that you have a referee or game master that resolves any timing conflicts.

Keep the mechanics sparse and simple

You should focus on only the most innovative and important mechanics in your game. Mechanics that are well understood (e.g. those that are common to the genre of your game) do not need as much prototype experimentation; focus on what is new. If you need a challenge to show off the mechanic, limit yourself to one such challenge.

If your mechanics are multi-step (e.g. one or more actions plus one or more board elements), streamline them so that they can be resolved relatively quickly. If it takes 5 minutes to resolve a single action, the prototype is not going to be particularly useful. Similarly, avoid mechanics that rely to heavily on an iterated interaction loop (e.g. physics); it is infeasible to resolve these types of mechanics in a non-digital setting.

Include any resources present in your game

While non-digital prototypes are often difficult for spatial mechanics, they really shine for resource mechanics. That is because resource interactions are inherently discrete to begin with, even when there is an iterated feedback loop. If resources are going to play a prominent part in your game (and just about any game needs some collection of resources), then you should include them in your prototype.

Only employ randomness if it is strategic

This is a prototype, not a shipping board game. It does not need fully fleshed out mechanics like you would see in a polished game. Unless you are trying to capture some element of randomness that will be present in the final game, you do not need to add dice. However, if your game will involve strategic random decisions (recall the game of Pig discussed in the introductory course), then you should definitely have it in your prototype.

Prototype Requirements

You will be presenting your prototype in class. In addition to explaining how the prototype works (and giving some of us the opportunity to play the prototype), we expect you to justify why you made the prototype that you did. In the design of your prototype, we are looking for two important things.

Difficulty Progression

One of the problems with mobile games is that you have a good idea for a game mechanic, but you can only think of one type of challenge for it. So you fall back on a survival mode or "beat the high score" type of gameplay in hopes this will get you enough replay. The endless runners and flicking games fall into this trap. We want something a little deeper than this.

Because of this, it is critical that your prototype show off some type of progression. This will require that you have multiple "levels" of your game. Levels can mean completely different game elements. They can also mean the same game elements, but slightly different rules or game parameters. You can have static pre-made levels, or you can have a completely reconfigurable prototype that allows you to make levels on the fly. It is completely up to you.

The minimum requirement is three levels, which you can think of as easy, medium, and hard. In your presentation, we want you to answer the following questions:

• What are the fundamental differences between the various levels?
• How do these game differences create differences difficulty?
• How can the player train to solve the highest level of difficulty?

Meaningful Choices

In the prototype, we also want to see some evidence that your game is not just a reaction time or hand-eye coordination game. The player needs to be able to make some interesting choices. We are not saying you have to make a strategy game. Think of the example with Dash that we showed in class.

The choices should be interesting in that they are not just the difference between success and failure. You should have two choices that can both eventually lead to the goal. They do not have to be equally desirable; one can be "harder" than the other. Furthermore, the success of the choices can depend on the obstacles present. Different obstacles favor some choices over others. Therefore, in your presentation, we would like you to answer the following questions:

• What are the most interesting (successful) choices in your game?
• In what context can each of these choices successfully reach the goal?
• In what context are some choices easier than others?

There are many different ways that player choice can occur in your game. If spatial or tactical positioning is a major component of your game, then this may be enough. However, if you are having trouble, there are two important concepts that are very good about creating player choice.

Emergent Behavior: Recall that emergent behavior happens when you can combine actions (via interactions) to produce new and interesting actions for free. If you have a lot of interactions, then one of the main challenges of the game is for players to put themselves in a state where they can most benefit from this interactions. If your game has a lot of interactions, we highly recommend that you model them in your prototype. See the guidelines on board elements above to see how you might model interactions in a nondigital setting.

Cost-Benefit Decisions: If your game makes significant use of resources, then your nondigital prototype is a great way to explore the game economy. What are the prominent sources, syncs, coverters (and if they exist, traders) that give rise to your game economy. If you have a significant resource conflict (e.g. tug-of-war, dot eating, or flower picking), you should try to model that as well. Remember that economies are a good way to create strategic or dilemma challenges.

Organization

Your presentation will be a formal playtesting session. Later in the semester we will talk about what that entails -- what you should be measuring and testing. At the very least, you should be thinking about how your presentation addresses the issues covered above. But for this first presentation, we are mainly asking that you come prepared with a clear idea of who is responsible for what in the presentation. In particular,

• Who will explain the game to new players?
• How will this be done? Out loud? Written instructions? Something else?
• Who will be watching the players (and not interferring or interacting)?
• When will the team changes tasks so that everyone has time to test some games in the room?

You are expected to write out these responsibilities (in a Google Drive document) before you come to present.

Examples

For some students, this is often the hardest part of the course. While everyone says that designers should make non-digital prototypes, no one ever gives any guidance on how best to do it. Even the Fullerton text from the introductory course, which has the absolute best chapter on non-digital prototyping of any text available, has no more than a chapter on case studies.

With that said, we have been doing this activity for several years now, and there have been real standouts over the years. Hopefully you can learn from looking at these examples.

Runaway Rails

Runaway Rails was an endless runner for Android in the Spring 2013 CS 4152. This nondigital prototype is to date the most clever example of gameplay modeling, which is why it is part of our lectures. The prototype models reaction time as a hidden information challenge. If you think that your game is too fast paced to have a nondigital prototype, look at this example.

Trino

One of the most recent games on this list, Trino was the audience favorite game at the 2018 GDIAC showcase. It was a stealth game with transformation mechanics. You will notice that their prototype makes heavy use of board game elements and focuses not just on stealth, but also the resource limitations of the game.

Trino

Another recent game on this list, Out of Sync was the most innovative game at the 2018 GDIAC showcase. It was a clone-based platformer where the player was challenging with avoiding clones (instead of cooperating with them, as in most games of this genre). Notice the interesting usage of yarn to capture their time-based mechanic.

Squeak & Swipe

The most recent game on this list, Squeak & Swipe was the most innovative mobile game at the 2016 GDIAC showcase. They had a very clean prototype that shows off the most important parts of their gameplay. They were highly configurable, and able to test several levels.

Ersatz

Ersatz was the most innovative CS 3152 game at the Spring 2015 showcase. This stealth game included a time-travel cloning mechanic. The nondigital prototype does an excellent example of creating simple, medium, and hard levels and is exactly what we are looking for here.

Dodgeball Damnation

Dodgeball Damnation was an audience favorite at the Spring 2015 showcase. This CS 3152 game was an action game where you caught projectiles and threw them back at your opponent. This prototype is great because it has discrete mechanics without using a grid. Instead, every piece has an attached piece of yarn or string indicating how far it can act. This allows a lit more flexibility in the design.

Beam

Beam was the most polished mobile game in Spring 2014. It was a discrete puzzle game that did not have any physics or complex AI. This meant it was extremely crucial for this game to have a solid progression. They had a very simple prototype that did not need more more than grid paper and color pencils. However, it was extremely configurable, and allowed them lots of levels long before they wrote any software.

Over the Arctic Hills

Over the Arctic Hills was another one of the top mobile games in Spring 2014. As you can see from the game trailer, the final game did have a reaction-time component; the snowman walks on his own and the player has to time snowballs to change his path. But the choice of which snowball to use, and where to roll it is a strategic one. That allowed them to create a useful, reconfigurable prototype.

Crisis at Swiss Station

Crisis at Swiss Station was a puzzle platformer from Spring 2011. It is notable because they had a nondigital prototype that was very close to their final product. Their nondigitial prototype is a textbook example of how to use a prototype to account for resources in your game.

Elly

Elly (called Psychic Prison in this prototype) was a game that relied heavily on physics. It was a top-down game where the player had powers very similar to an Adept in Mass Effect. Despite this, they had a great nondigital prototype, as they were able to simplify the physics and create something that still showed how the player could use psychic powers.

Bounce

In Bounce, the player is an astronaut navigating a weightless space station. In addition to the heavy use of physics, Bounce had a resource: oxygen. The player needs oxygen to live, but can also use oxygen as a jet pack to move about the room. This board game does an excellent job of modeling this resource.

Presentation Format and Schedule

As you can see from looking at the calendar, this presentation will take place over two classes. That means that we will have four presentations each class. Each group will have 15 minutes to show off their prototype

So that this goes smoothly you must be to class on time. If your group is presenting that day, you should be set up and ready to go at the start of class. That means it is a good idea if at least one person (the person with the prototype) shows up a little bit early. We will spread out throughout the class and make use of all the tables.

So that you are prepared, the presentation schedule is as follows. The studio names and working titles are taken from your group charter that you submitted the second week.

(By the way, as you can see from the group names below, several groups in the class refused to come up with a group name. Please be more creative!).

Monday (February 18)

• Super Glue Studio (Tower Offense)
• One Fortune Games (Kamachi)
• LUMEN Studios (YoyoBoy)
• 7Studio (Undetected)
• OneWordStudios (Flourish)
• Triton Games (Prism Break)

Wednesday (February 20)

• FlashLight Studios (Amaris: Realm of Dreams)
• Ralph Studios (Far-Fetched)
• HEDG (Roasted!)
• FXN (Loxodonta)
• The Syndicate (I Want to Steal)
• Snapback Studios (Clerical Error)

Submission

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

In addition to the presentation, we expect you to turn in your nondigital prototype. We understand that this is difficult, as it is nondigital by definition. However, at the very least, you should provide us with the rules of your game; you should submit these rules as a PDF file. In addition, you are welcome to send us the following:

• A representation of the gameboard, if you had one
• Any other artwork that you used in the prototype
• A picture of your team playing your game!

You should gather all these files together and zip them together in a file called prototype.zip.

For this assignment you will be graded on the quality of your presentation in class. We expect you to have thought hard about all of the questions in the requirements even if you do not know the answers to them. We also expect the prototype to look somewhat presentable, and not something that you threw together this morning.