ENGRC Lab 1
Due: Saturday, February 4th at 11:59 pm
At the start of this lab, you should get together according to your
assigned groups. For
some of you, this will be your first official meeting with your group. The lab
today will be focused on two important topics: starting your
Team Workflow Document
and brainstorming ideas for your game.
When you meet with your group, check to make sure that everyone is there. If
anyone is missing, let us know immediately. If someone is missing group meetings
this early, it does not bode well for the future. If a team member must be
replaced, we need to know early while we can still add new people to the class.
At the very beginning of class, Traci will talk to you all about group dynamics
and what is expected of you this semester. She will go over the purpose of the team
workflow. She will also talk about what to do if you think you need to revise your
We do not want you to finish the team workflow in lab time. That should be completed
outside of class, and we want you to spend the majority of the time brainstorming.
However, you should spend some class time thinking about
Everyone should have some sort of role. However, there are three roles that
are very important:
This person is in charge of assigning tasks and keeping the group on top of deadlines.
They are also responsible for gathering together the information for the bi-weekly
reports (though everyone is expected to contribute). This should be someone who can
get along with everyone on the team.
This person is in charge of the architecture decisions on the project. They lead
the design of the architecture specification, and have final say on all class
interfaces. They also assign programming tasks to the other members of the team.
This should not be the same person as the Project Leader.
In the case of multiple designers, this is the person who sets the visual aesthetic
of the game. They have final say on the artistic style of the game, and the other
designers are expected to conform to this style.
Activity: Brainstorming Ideas
You should only spend 10-15 on the team workflow document. The majority of this lab
should be spent brainstorming the kind of game you want to make. For this lab you will
use some, but not all, of the formal design elements that we talked about in
You will focus on your core gameplay mechanics, but you will do so by framing it
in terms of the player experience. This is the approach favored by Ernest Adams,
who uses it in his game design tutorials. We have also found that it is one of the
most successful approaches for beginners.
As you work, write down answers to the questions below. You will turn in
your answers, and we will critique them for you. You will use this critique
to form your
It is possible that you will not answer all of the questions. Answer as many as
you can. In addition, you do not need to answer them in order. Different designers
find it easier to begin with different starting points. Some people like to begin with
verb brainstorming from the very beginning. Others need to
understand all the goals and challenges before they understand the verbs. As with
everything else in this course, treat this as an iterative exercise. Answers to
some parts may cause you to go back and revise other parts.
While you work, several TAs will be moving about the room. They will listen in
on your groups and occasionally give you some feedback (though they will not
directly give you ideas). If you have any questions about this activity, please
ask the TAs. The are all alums of this course, and have been through this process
Before you formulate your core gamplay, you will first define the thematic focus of
your game. This is not the same as genre. Unlike a book, a game genre does
not define a setting or theme; instead it implies a common set of gameplay mechanics.
You will not worry about mechanics until you have defined your theme.
Defining your theme consists of answering the following questions:
What dream are you satisfying?
As we discussed in class, many games are about wish fulfillment. That is, they are a
response to a statement of the form "I want to ______."' This can be a role (e.g.
"I want to a be a crime-fighting zombie"). It can be be an activity or experience
(e.g. "I want to explore a land where I do not know the language"). It can even
be an emotion (e.g. "I want to feel lonely, but content"), though these
are, by far, the hardest to achieve.
What statement are you responding to? Choose carefully, as the rest of this activity
will be critiqued according to how well it supports this theme.
What is your setting?
The setting is what your player sees. Is your game a virtual (albeit 2D and primitive)
world, or is it some mathematically abstract landscape? If it is a world, what kind of
world is it? This should expand on your dream mentioned above.
It is possible to get too carried away in this step. Keep your description short and
limited to a few sentences. We are not looking for an unabridged history of your game
What is your perspective?
The perspective is how your player sees the game world. If your game is set in a
virtual world, is the perspective top-down, side-scrolling, or isometric? If it is
an abstract mathematical world, how is the abstraction represented visually to the user?
Player mode diagrams are particularly useful for explaining perspective. You may wish
to draw a picture to answer this question. However, we are not requiring any pictures
at this stage of the design.
Now that you have some ideas for the theme of your game, you can start work on your
core gameplay mechanics. This is a process that does not end with this communication
lab; you will be refining and redefining your mechanics over the course of the semester
through your various prototypes. However, to get you started, you should answer the
What are the player's goals?
You have provided us with a theme. Now try to distill this theme into concrete goals.
In doing so, you should certainly keep in mind the formal types of goals mentioned
in class or in
the assigned reading. However, you
should always start with informal goals that directly match your theme, and then figure
out how they correspond to more formal design elements. Never start with with the
You do not need to limit yourself to a single goal. Secondary or optional goals are
also okay. However, try to keep this list relatively short, as too many goals will
make the rest of the exercise complicated and unfocused. In particular, limit
yourself only to goals that are mandatory for the player to complete a "level"
in your game.
What are the player actions?
As we discussed in class, games are an interactive medium, and that means that players
can do something other than watch the game. Actions (or "verbs") indicate what the
player can do. These actions may be tied directly to an avatar, or they can be the
result of a disembodied entity (e.g. as in many "God games").
For this step, tell us your most important actions. Follow our
guidelines below. Focus on the outcomes of the actions, and
not the user input or how it is animated. Furthermore, if your game fits within a
genre, you should simply mention that (e.g. "we have standard platformer
movement") rather than describe each verb individually. You should only spend time
describing a verb if it is relatively unique.
In coming up with your verbs, you do not need to separate actions and interactions.
It is okay for you to think of composite mechanics, like stomping a Goomba, as a single
verb. That can make your design a lot easier. We will worry about actions and interactions
in a later exercise.
What challenges does the player face?
Challenges prevent the player from achieving the goal(s). Describe some of the
challenges that you expect to have in your game. You are not expected to come
up with all of your challenges right now, but you should describe at least 2 or 3.
In describing your challenges, you need to be aware of the type of challenge.
We have talked about challenge taxonomies in class. For this activity,
we want you to focus on classifying your challenges as one of two types.
An extrinsic challenge is one that does not depend on the actions themselves, but
instead depends on how well the player performs the actions. Timing, rhythm, or
hand-eye coordination are the primary types of challenges in this category.
While these types of challenges can be fun, it is important that these are not your
only type of challenge. Games limited to these types of challenges tend to get old
very, very quickly. They can also be frustrating for players not committed to your
game (e.g. pixel-sensitive platformers).
An intrinisic challenge is one that the player overcomes via game mechanics (e.g. actions
and interactions). This can include enemies, where the associate mechanic is either
combat or stealth. It can also include spatial obstacles. Lock-and-key or resource
challenges also fall into this category.
When you have finished describing your challenges, you are done with the exercise.
Feel free to go back and revise your answers to any of the previous questions.
Suggestions: Describing Actions
One of the biggest challenges that students have with game design is properly defining
actions. If you do not understand your core actions (both primary and secondary)
from the beginning, your gameplay will be very shallow. And then you will be tempted
to compensate with this by adding even more features and actions. This "verb bloat"
is a guaranteed way to get a lower grade on your game.
There are two important things that you should keep in mind when defining your actions.
You should avoid the "verb proxies" that we talked about in class. "Use an item" is
never a core verb, as each item can have a different effect, and thus represent a
different kind of activity. To ensure that your verb is suitable, we find it is best
to describe the outcome. For example "hurt an enemy" or
"hurt an enemy from a distance" is often much better than "shoot".
As a general rule, a verb should correspond to a single outcome. For example, if
your game has weapons with different types of ammunition — such as freezing
ammunition or fire ammunition — the effects of each one of these corresponds
to a different verb. However, these lines are not always clear-cut. If you have
ammunition types, but the only difference is the amount of damage that each types
causes, or the defenses that each type can overcome, this is just one verb.
In addition to being more descriptive, this approach to actions allows you to be
more flexible in your artistic design. Whether you are attacking with a gun,
a magic wand, a bow-and-arrow, or throwing stars, the attacks all create projectiles
that cause damage and so are essentially the exact same action. Yes, there may be
differences in attack speed, damage, or resource usage, but these are additional
mechanics that you do not worry about during the initial design process.
Another important feature of being outcome-oriented is that you do not define
actions in terms of input control. In most platformers jump and double jump are
not the same action, even though they use the same action button. However,
determining what is actually a separate action can be a bit of an art form. For
example, in platformers, a long jump is a combination of a jump with forward movement.
Is this actually a different verb, or is it just what you naturally get when you
combine the upward movement of a jump with forward movement? This is not
immediately clear. Make your best guess when deciding what needs to be its own verb.
One of the greatest resources for understanding outcome-oriented actions is the
Hero System. This is a
pen-and-paper RPG that is famous for its flexibility in designing character abilities.
Absolutely everything is described in terms of what it can do. Want a fireball spell?
That is just a 10d6 ranged killing attack with area effect and no normal defense.
The fire aspect is a "special effect" that describes what the attack looks like,
but has no significant effect on the game mechanics.
If you are interested in learning more about this approach, we have provided a copy
on reserve in Uris Library. Chapter 5 (Powers) is the important chapter to read.
A game genre is a set of actions and challenges that are common to games of that type.
For example, most platformers have side-to-side movement and jumping (though some replace
jumping with wall-running or other forms of vertical movement). If your actions are those
from a recognized genre, feel free to say that (e.g. "our game uses standard platformer
movement"). This is concise, and it allows you to focus on the different elements of
If you are leveraging an existing genre, we recommend that you pick one with a relatively
small number of actions. Lots of verbs means lots of controls to implement. This is
difficult for you, as a developer, to implement, and difficult for the player to learn.
There is a reason why a large number of indie games are platformers plus an additional
(often secondary) action.
Another option with genres is to start with a genre and "strip it down", removing
actions so that you get a smaller mini game. Many of the deconstructive games that
we talked about in class fit into this category. For example,
Help the Hero
takes an RPG and removes everything except for inventory management, while
My Pet Protector
concentrates entirely on leveling.
Due: Saturday, February 4th at 11:59 pm
You do not need to submit anything about the group roles. We will see that as part of
your team workflow
at the end of the week. The only thing that you need to turn in for this lab is the
result of your brainstorming. We will critique your ideas so that you know what to
put in your concept document
We will also grade this submission, though the grade will be pass/fail based solely
upon whether your group was present and took the assignment seriously. This lab
will be part of your
To submit your answers, create a file called ideas.txt
which answers all of the questions above. If you drew a picture, scan the picture
and submit the document as a PDF instead. You only need to submit this file once
for the entire group.