Paper Prototype 1
Due: Thursday, January 1st at 12:00 am
For this assignment, you will create a paper prototype of your game. This prototype should seek to answer some central design question. In doing so, you will test your core gameplay mechanics and gain some insight as to how your game will play.
You should not worry if your final game at the end of the course is nothing like this prototype.
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 quality of the prototype. 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 Paper Prototype
The primary purpose of this prototype is to test a central gameplay mechanic to see
whether it is fun. The lecture on
should help give you some ideas on how to make a prototype.
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 paper 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
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.
The paper prototyping will happen over two class days. On Tuesday, September 9th, we will test the prototypes in class. Groups will take turns between testing their prototypes and playing other groups' prototypes. You will then revise your prototype and consider a different design question during an additional day of testing on Thursday, September 11th.
Demonstration of Emergent Behavior
One of the most useful things to model in your non-digital prototype is evidence
of emergent behavior. Recall that emergent behavior happens when you can combine
actions (via interactions) to produce new and interesting actions for free. See
the guidelines on board elements above to see how you might
use interactions to combine actions.
It is okay if some of these interactions happen over several turns. For example,
platformer movement typically resolves horizontal movement across several turns
after the jump was performed (unless you are using
action points to resolve the
jump in a single step).
If you choose this aspect as the primary focus of the prototype, you should be
prepared to do the following for your game.
Identify the emergent behavior and how it is enabled by interactions.
Justify why the behavior does not need to be modeled as a discrete action.
Make an educated guess about how well this will carry over digital setting, which is less discrete.
This type of prototype is the easiest to implement. It does not require the deep
understanding of game economy for a cost-benefit analysis, or the regular playtesting
to understand difficulty levels. But it does require that you have a fairly deep
understanding of your mechanics early on in development.
If your game makes significant use of resources, then your best use of a non-digital prototype
is to use it for resource analysis. Identify 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. Strategy games and RPGs fit well to this type of prototype, as
demonstrated in the AstroWar example.
One of the primary purposes of resources is to create strategic or dilemma challenges.
Therefore, if you choose this aspect as the primary focus of the prototype, you should
be prepared to do the following for your game.
Identify several (e.g. more than one) resource-related challenges.
Identify how resources help you overcome the challenges
Identify the costs and benefits of resource expenditure.
If you game has a dominant strategy, or is in some way "unbalanced", then you should
identify that. If you believe that your game is balanced, then you should argue why
you believe this.
If your game is a pure puzzle game, you may not have neither complex mechanics nor
a lot of resources. In that case, your primary concern is player difficulty. This
means that you need a non-digitial prototype that (discretely) captures the primary
puzzle element of your game.
Because difficulty is your primary concern, we want you to come with more than one
puzzle "level", so that we can compare their difficulties. Therefore, in addition
to the rules of your game, you should present the following:
Explain the fundamental differences between the various levels.
Explain how they differ in difficulty, if this is indeed the case.
Identify guidelines to follow achieve a desired difficulty level.
As we discussed in class, difficulty analyis requires that you play your game. The
ideal approach is for one person to design a level and have another person to play it. It
does not tell you anything to have a level played by the creator.
Runaway Rails was an endless runner for Android in Spring 2013. This nondigital
prototype is to date the most clever example of nondigital modeling, and it is a major
part of our gameplay modeling 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.
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.
Angry Bunny was a mobile (Android) game from CIS 4002 in Fall 2010. They had a very unusual
movement mechanic that relied on the touch screen. There nondigital prototype was used to explore
this movement mechanic — to see how natural it was and what types of puzzles it could be used
AstroWar was a turn-based strategy game developed in this course three years ago. This was
made before nondigital prototypes became mandatory, and it was constructed as part of their gameplay
prototype. However, in their case, a board game was a natural prototype to use. They actually
had a physical board for their prototype (which is not pictured in the link above); however,
the rules are enough to understand the basic principal.
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.