Due: Saturday, February 18th 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
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
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
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.
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.
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?
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.
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.
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
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.
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.
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. In terms of configurability, it was not as flexible
as Beam, but still flexible enough for them to test several levels.
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
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
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
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
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)
One Group (Group 1)
CUGL Buddies (Group 3)
aglow (Group 4)
The Spoopy Squad (Group 5)
Friday (February 19)
SampleCo (Group 7)
Due: Saturday, February 18th 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
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.