Assignment 4
Nondigital Prototype
Due: Saturday, February 15th at 11:59 pm
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.
One of the things to be aware of this requirement for a testing script.
This was not a requirement in 3152 last year. However, Traci should have warned you about
this ahead of time, so you should be ready.
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, 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 lecture on
prototypes 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 class.
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 (e.g. tug-of-war, dot eating, or flower picking),
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.
Testing Script
The team needs to determine *what* needs to be discovered. This part of the assignment was
started last week in the ENGRC lab.
Each team knows that players will be challenged in a different way. The non-digital
prototype allows teams to assess if they are communicating well with the players.
Teams should brainstorm and write out (in the Google Drive document) what specifically
they are testing for with this prototype. Examples are below, but these are just starting points:
-
Do players understand the core mechanics?
-
Do players understand the goal from the moment the level opens?
-
Do players understand how to get to the next level or progress?
-
Did we have to intervene in order for players to “get” our game idea?
-
Was the game’s play clearly evident?
-
Is it clear how the characters/avatars should move?
-
Do the actions of the enemies make sense in the game’s context?
In that same document, the team should have a clear plan for responsibilities:
-
Who will explain the game to new players?
-
How will this be done? Out loud? Written instructions? Something else?
-
Who will remind players of the talk-aloud protocol?
-
Who will be watching the players (and not interferring or interacting)?
-
Who will take photos or video of the testing? Where will those artifacts be housed/uploaded?
-
When will the team changes tasks so that everyone has time to test some games in the room?
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 several years now, and there
have been real standouts over the years. Hopefully, everyone can learn from looking at
these examples.
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 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).
The puzzle game Magic Moving Mansion Mania! was the most polished mobile game at the
2018 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.
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.
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
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 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
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.
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 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. We will spread out throughout the classroom 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 13)
-
Singularity Studios (Group 1)
-
Panda Studios (Group 2)
-
Group 3
-
Group 5
Friday (February 15)
-
Group 4
-
OneWordStudios (Group 6)
-
Group 7
-
Group 8
-
Group 9
Submission
Due: Saturday, February 15th 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).
|