CS/INFO 4152: Advanced Topics in Computer Game Development

Assignment 3
Nondigital Prototype

Due: Saturday, February 20th at 11:59 pm

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

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.

As with the introductory course, you should not worry if your final game at the end of the course is nothing like this prototype; that is what iterative design is for. However, you should 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.

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 prototypes should help give you some ideas on how to craft a nondigital prototype. As many of you have taken the introductory course before, 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 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.

Interactions are a major component in mobile games, since the amount of player input is very limited. 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.

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


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 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.


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 lots of levels long before they wrote any software.


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.

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 (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.


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 or five presentations in each class. We will pair off groups so that each group will have 20 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.

Wednesday (February 17)

  • PuppyCloud (Group 1)
  • Fission (Group 3)
  • Sounds Gouda (Group 6)
  • FlameĀ­ingos (Group 7)

Friday (February 19)

  • Irrelevant Turtle Presidents (Group 2)
  • 6Sum Studio (Group 4)
  • salt&paprika (Group 5)
  • Groop (Group 8)
  • Spectrum Studios (Group 9)


Due: Saturday, February 20th 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.