CS 4154: Analytics-driven Game Design

Assignment 2
Paper Prototype 1

Due: Wednesday, August 30th at 11:00 am

For this assignment, your team will create a paper prototype of a 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. 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. The prototype will not be graded, but you should at least make something you can get useful information from trying. You will lose participation points if you do not show up to class and try other prototypes.


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 paper prototyping 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 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, then you should definitely have it in your prototype.


Prototyping Process

The paper prototyping will happen over two class days. On the first day, we will test the prototypes in class. Groups will take turns between testing their prototypes and playing other groups' prototypes. You will then revise this prototype, as well as create a completely different prototype, for the second day of testing.


Examples

Zombify, 2014


Pyrokid, 2014

Epic's Epic Epic, 2014