Nondigital Prototype

Those of you who took the introductory class have solid experience with prototyping. We use prototypes to test out the various aspects of each game, including game play, technology, and user interaction.

For this assignment, teams will embark on the first prototype: the non-digitial prototype. This prototype should capture the core gameplay mechanics and provide some insight as to how well the game will play. Other than the requirements spelled out below, we are giving teams 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.

As with the introductory course, do not worry if the final game at the end of the course is nothing like this prototype; that is what iterative design is for. However, teams should make a good-faith effort to come up with a reasonable prototype, since the earlier teams are playing and testing the game, the better the game will be. The grade for this assignment will be based upon the clarity of each team’s 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.

Table of Contents

• Prototype Design
• Prototype Requirements
• Examples
• Class Presentations
• Submission

Prototype Design

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, there is at least one 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 the final product.

The lesson on gameplay modeling should help give you some ideas on how to craft a non-digital prototype. Many of you have some experience with non-digital prototypes. 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 your team has a member with some experience with table-top RPGs, use this person as a resource to help create the model. If the team’s mechanics are complex enough that they involve multiple interactions over time, 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 the team decides to have a prototype that works like this, we recommend having a referee or game master that resolves any timing conflicts.

Keep the mechanics sparse and simple

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

If the 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 five 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 include them in the 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 in a polished game. Unless the team is trying to capture some element of randomness that will be present in the final game, there is no need to add dice. However, if the game will involve strategic random decisions (recall the game of Pig discussed in the introductory course), then definitely have it in the prototype.

Prototype Requirements

Each team will be presenting its prototype in class. In addition to explaining how the prototype works (and giving some of us the opportunity to play the prototype), we expect each team to justify why it made the prototype in the fashion shown. In the design of this prototype, we are looking for some important pieces.

Difficulty Progression

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

It is critical that the team’s prototype show off some type of progression. This will require multiple “levels” of the game. Levels can mean completely different game elements. They can also mean the same game elements, but slightly different rules or game parameters. Teams can have static pre-made levels or a completely reconfigurable prototype that allows levels to be made on the fly. It is completely flexible.

The minimum requirement is three levels, which can be thought of as easy, medium, and hard. In the team’s presentation, 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 the 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 “make a strategy game.” Think of the example with Dash that we showed in the lesson gameplay modeling.

The choices should be interesting in that they are not just the difference between success and failure. 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, answer the following questions:

• What are the most interesting (successful) choices in the 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 the game. If spatial or tactical positioning is a major game component, then this may be enough. Remember that 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 multiple 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 these interactions.

Interactions are a major component in mobile games, since the amount of player input is very limited. If the team’s game has multiple interactions, we highly recommend modeling them in this prototype. See the guidelines on board elements above to see how to model interactions in a non-digital setting.

Cost-Benefit Decisions: If the game makes significant use of resources, then the non-digital 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 there is a significant resource conflict, try to model that as well.

Game economies are extremely important to mobile games, as you cannot design a free-to-play game without understanding the core resource loop. Economies are also a good way to create strategic or dilemma challenges.

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 almost a decade now, and there have been real standouts over the years. Hopefully, everyone can learn from looking at these examples.

Beam

Beam was the most polished in 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 to create many levels long before they wrote any software.

Split

Split was the most polished mobile game at the 2018 GDIAC showcase. This prototype is very similar to that of Beam, in that is flexible and shows of a lot of their mechanics. The write-up is also very nice, as most people tend to just give us a bulleted list of half sentences for their rules (we do not like that).

Magic Moving Mansion Mania!

The puzzle game Magic Moving Mansion Mania! was the most polished mobile game at the 2017 GDIAC showcase and later went to win the Student division at Boston Festival of Indie Games. Like Beam, it has a fully configurable prototype. But also notice that they payed close attention to the size limitations of mobile in their design. To many people ignore screen real estate in their early designs.

Family Style

The 2019 Showcase audience favorite Family Style had a card game for their nondigital prototype. While card game prototypes are common, what is far more interesting is how they made use of physical placement of the players. The game “board” recreated the virtual real estate of players passing items from phone to phone. This is a major aspect of their gameplay and the prototype does a good job of capturing it.

Mesmer

The 2017 puzzle game Mesmer was a 3D game written in CUGL the first year we used the engine (the lead programmer had taken CS 5625). The puzzles depended on the 3D geography of their world, and so they had to capture that in their nondigital prototype. In addition, they have so many pictures of this prototype that it is easy to understand it even though the props have long been lost. Too many groups skimp on the pictures!

Runaway Rails

*Runaway Rails was an endless runner for Android in Spring 2013. 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.

Squeak & Swipe

Squeak & Swipe was the most innovative mobile game at the 2016 GDIAC showcase. This team had a very clean prototype that shows off the most important parts of gameplay. In terms of configurability, it was not as flexible as Beam, but it was still flexible enough for them to test several levels.

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 its own and the player has to time snowballs to change its path. But the choice of which snowball to use–and where to roll it–is a strategic one. That allowed the team to create a useful, reconfigurable prototype.

Class Presentations

Right now, we have two days scheduled for this session. While this is the typical amount that we give, this means that the class has to run smoothly for everything to work. In particular, everyone must be to class on time. If your group is presenting that day, come early, set up, and be ready to go at the start of class.

Presentation Format

Your presentation will be a formal playtesting session. While not all of you took the introductory course, this means that you should be measuring and testing something. At the very least, you should be thinking about how your presentation addresses the issues covered above. But more importantly, we are 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 and recording the players (and not interferring or interacting)?
• When will the team changes tasks so that everyone has time to test other games?

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

Class Format

On each day, we will identify a number of you to present your prototype (see below). If your group is presenting on that day, you will find a table and set up your prototype on that table. Students who are not presenting should line up against the wall, where they will be broken up into groups. These groups will be evenly distributed about the number of prototypes.

At the start of your presentation you should show off your prototype and explain how it is played. Given the limited number of time per presentation (15-20 minutes), this presentation should take no more than 2 minutes. After 2 minutes, we want someone in the audience playing the game. This may mean that you need to explain more of the rules to the player as they are going along.

You will have 15-20 minutes to show off your prototype before we rotate a new group in. We will rotate groups twice (for a total of three groups experiencing your prototype) over the course of the class session.

Presentation Schedule

Right now, we have two days scheduled for this session. So that you are prepared, the schedule is as follows:

Wednesday (February 16)

• First Topic (Group 1)
• oops (Group 3)
• Team Pixl (Group 5)
• Sticky Keys Studios (Group 7)

Friday (February 18)

• Pirate HR (Group 2)
• Nintendon’t (Group 4)
• Humblegends (Group 6)
• Sashimi Software (Group 8)
• Name Pending (Group 9)

Submission

Due: Sat, Feb 19 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, we would like the following submitted:

• The rules for your game as a PDF file
• A representation of the gameboard, if you had one
• A write-up of what you have learned from the prototype.

In addition, you are welcome to send us the following (though it is not required):

• Any other artwork that you used in the prototype
• A picture of your team playing your game!

A designated team member or the Project Lead should gather all these files together and zip them together in a file called prototype.zip.

For this assignment, grades rest on the quality of the presentation in class. We expect teams to have thought hard about all of the questions in the requirements even if they do not know the answers to them. We also expect the prototype to look somewhat presentable (not something that you threw together that morning).