ITERATIVE GAME DEVELOPMENT
What goes into making an effective game and the lessons learned from making two
games.
by
Nicolas Goller
A Senior Honors Thesis Submitted to the Faculty of
The University of Utah
In Partial Fulfillment of the Requirements for the
Honors Degree in Bachelor of Science
In
The School of Computing
Approved:
______________________________
Professor Robert R. Kessler
Thesis Faculty Supervisor
_____________________________
Professor Ross Whitaker
Director, Department of Computing
_______________________________
Professor Erin Parker
Honors Faculty Advisor
_____________________________
Sylvia D. Torti, PhD
Dean, Honors College
April 2016
Copyright © 2016
All Rights Reserved
TABLE OF CONTENTS
INTRODUCTION .............................................................................................................. 1
SPIRE OF THE SULLEN – TEAM SPITE......................................................................... 4
The Arrow ................................................................................................................................... 11
Player Movement ........................................................................................................................ 13
Boss Battles................................................................................................................................. 15
APLOWCALPYSE – TEAM BACKFIRE ......................................................................... 19
Player Movement ........................................................................................................................ 23
Team Motivation ......................................................................................................................... 24
Testing ........................................................................................................................................ 25
COMPARISON ................................................................................................................ 28
Motivation Is Key........................................................................................................................ 28
Be Agile, but Not Too Agile ........................................................................................................ 31
Disagreement Versus Constructive Criticism ............................................................................. 33
Pain and Struggle is Often a Good Sign ..................................................................................... 34
CONCLUSION ................................................................................................................. 35
i
1
INTRODUCTION
Imagine you are told you have two semesters to make a game. You have a team of
over ten people ready to help out. You even have the basic idea of what the game will be
about. How hard can it be?
Well, it is not that hard to make “a game” in two semesters. A competent coder can
hack together a game over a weekend. You basically just need a set of rules and a
framework in which players can play the game. Now, what if you wanted to make an
effective game? A game that really affects the player. Well, this whole one weekend project
is not going to suffice. All of a sudden two semesters seems like an incredibly short period
of time.
An effective game can be realized in many ways. One way is through imparting a
feeling of satisfaction upon the player. Perhaps players leave feeling incredibly satisfied.
Or maybe the game allows someone to come to terms with relationship struggles or
divorce. Or maybe the grueling competitiveness of the game makes the player feel
challenged and invigorated. There are clearly many options, yet creating an effective game
is not easy.
A game is a piece of software. There was a time when software was developed in a
waterfall style. The waterfall development methodology has a rigid structure. First you lay
out the requirements. Then, there is a design phase, followed by implementation,
verification, and finally maintenance. “The waterfall model is not a good framework to
control the development process for products that have so much new content or so many
2
uncertainties to resolve that changes in design are inevitable and often desirable”. 1 A game
requires an extensive codebase to control everything ranging from the artificial intelligence
of the enemies and non-player characters to the databases that keep track of high scores.
And a game is just that - it is uncertain.
As a result, a less deterministic development methodology is more fitting. You may
have the greatest idea, but if you do not adapt, the game will not come together. Even a
seasoned game designer needs to test their ideas out and iterate on them. Iteration is the
process of realizing that your game is not perfect, but that by incrementally building and
refining it, you can create a powerful product.
In agile development, the focus is on creating a meaningful product through the
agile process. You start by building a quick minimalistic version of the product (the
minimum viable product).2 From there, you test and see which aspects of this base idea are
effective and which do not work. You deal with the features that do not work and keep
honing in on the aspects that bring out your game’s effectiveness. Often you are looking to
see what is fun and bringing that part of your game up to the forefront. The goal is to not
spend too much time on tasks that do not move the product forward.
The development cycle is broken up into short sprints (often two weeks long).
Sprints are development periods in which the team attempts to comprehensively move a
product forward through iterative development. At the end of a sprint, the product can be
demoed and tested with potential players. As a result, you are not bogged down by
1
Cusumano, Michael A. “Beyond the waterfall.” (Sloan School of Management MIT 1995).
“Minimum Viable Product (MVP),” techopedia, 4/22/16,
https://www.techopedia.com/definition/27809/minimum-viable-product-mvp.
2
3
unnecessary paperwork or design documents, though some big picture design can no doubt
be useful.3
In what follows, I will go over the trials and tribulations of the last two semesters
as I have tried to make two different games using the Unity 3D game development engine:
Spire of the Sullen, a 2.5D skill-shot-based platformer, and Aplowcalpyse, a local
multiplayer alien killing bumper cars game. 4 First, we will look at the two games in
question.
André Godoy and Ellen F. Barbosa. “Game-Scrum: Agile Game Development.” (Proceedings of
SBGames 2010)
4
See “Unity,” Unity, 4/21/16, https://unity3d.com/; “Spire of the Sullen,” Google+, 4/21/2016,
https://plus.google.com/114184448784526004092/videos; “Aplowcalpyse,” Steam, 4/21/2016,
https://steamcommunity.com/sharedfiles/filedetails/?id=622026349.
3
4
SPIRE OF THE SULLEN – TEAM SPITE
Figure 1. Spire of the Sullen Poster
Our story begins late September of 2015 with a group of three students deciding
they want to work on a game. This was a personal project outside of any class deadlines,
and as a result, we were often limited to working during breaks from school. The premise
of the game? Archery. Why? Well, because arrows are cool. We decided to individually
make a quick prototype over the course of a week. It is important to have some
understanding of the technology you are using. By each making a prototype, we were able
to get a grasp of the Unity game engine and also see where our own ideas took us.
So what did we make? First, I made a dark three-dimensional game where you
shoot projectiles and try to get to a gate at the end (see Figure 2 and Figure 3). The player
tries to evade the giant rocks thrown by weird red lights atop towers either by dodging them
5
or shooting them before they land. The main premises of the game were minimal visibility,
skill shots, and fast-paced action.
Figure 2. My “arrow game” prototype, a dark game where you try to get to the gate (pictured).
Figure 3. The player needs to make it through a dark forest while being bombarded by strange red lights in towers.
6
The prototypes from the other students were an arrow game where you can
manipulate time and a 2.5D (built in a three-dimensional world for aesthetic quality, but
the actual game is limited to two dimensions) timed arrow skill-shot game. While our
prototypes were not amazing, they did help us nail down some fun game aspects.
As a synthesis of these three prototypes, we started building a 2.5D platformer
where you use arrows to get through the level with some focus on hard to hit, rewarding
shots. That was the premise. We did not write up a big design document. Instead, in
standard iterative style, we jumped to work trying to make a first level (minimum viable
product). After a couple of weeks, we already had a playable product and as an
acknowledgement of the successful completion of our first sprint, we went to the EAE
undergraduate lab at the University of Utah and asked people to try the game out. 5
Unfortunately, this first test told us that the game was a long way from being effective. We
still needed to figure out what the proper direction for this game was.
As a next step, we took inspiration from games we had played, focusing on the
mechanics we found really fun, and discussing why they were fun. We recognized that
Mirana’s sacred arrow ability from the popular game Defense of the Ancients (DotA) is a
well-designed ability.6 The player fires a large mystical arrow in the direction of the mouse
that travels across most of the game map. If the arrow makes contact with an enemy, it
inflicts damage and stuns the enemy based on how far it has travelled. Sacred arrow has
unpredictability and anticipation all culminating in a rewarding feeling of accomplishment
when you manage to hit someone. The ability almost feels like you are breaking the game
“EAE,” University of Utah, 4/22/2016, http://eae.utah.edu/.
See “Mirana,” Valve, 4/21/16, http://www.dota2.com/hero/Mirana/; “Dota 2,” Valve, 4/21/16,
http://store.steampowered.com/app/570/.
5
6
7
when used correctly. We realized that Windranger’s powershot and shackleshot (see
Figure 4) are also very rewarding abilities to use. Shackleshot inflicts a short stun on an
enemy. If you manage to line up two enemies, it becomes a very powerful stunning spell
that affects both targets.7 The abilities we liked all had a major skill component to them.
They were by no means easy to use, but if used correctly, they could be incredibly potent.
Figure 4. Shackle shot in action in a game of DotA 2.
We also really liked arrows in most of the games we played: Baldur’s Gate, Warcraft,
League of Legends, Trine, the list goes on and on. 8 We drew inspiration from all the games
we knew and tried to bring together aspects we found really fun. In the end, we were a little
ambitious with some of our plans for customization and dynamic paths through levels, but
we realized that we could not include everything and still maintain the integrity of the
game.
“Windranger,” Valve, 4/21/16, http://www.dota2.com/hero/Windranger/.
“Baldur’s Gate,” Beamdog, 4/21/16, https://www.baldursgate.com/; “Warcraft III,” Blizzard
Entertainment, 4/21/16, http://us.blizzard.com/en-us/games/war3/; “League of Legends,” Riot Games,
4/21/16, http://na.leagueoflegends.com/; “Trine Enchanted Edition,” Frozenbyte, 4/21/16,
http://www.frozenbyte.com/games/trine-enchanted-edition.
7
8
8
We began our first sprint by getting a cube to move around in a level. Then we quickly
made a mockup (a quick diagram) of level one (Figure 5). Our first level design involved
shooting arrows to release swinging platforms and collect the flying moths on the level. At
the very end of the level, we intended to show off one of our favorite mechanics: arrow
climbing. The player can shoot their arrows into wooden objects and climb on them!
Figure 5. Spire of the Sullen - First level mockup.
9
Figure 6. First Level Revised Mockup
After building most of the level, we found that puzzles like the swinging platform
would be very well contrasted with combat as well. Our first attempt was adding in two
bosses (labeled enemy 1 and 2 in Figure 6. First Level Revised Mockup). It is important to
keep gameplay fresh. As a result, we tried to have a sinusoidal pattern of combat and
platforming. This gives the player moments of intense action and calmer periods of
deliberation where they can hone their shooting skills. An early test run, revealed that
people were really impressed with arrow jumping. As a result, we tried to make it a more
prominent aspect of the game. We brainstormed ideas and decided that arrow jumping was
a mechanic that we could build an entire game around. And then things slowed down a bit.
We became busy with school. Over the course of this project, we added two more
team members (also friends) and now Team Spite is composed of five individuals:

Nicolas Goller – Engineer
10

Anson Li – Music Composer/Play Tester

Ngan Nguyen – Producer/Engineer

Oliver Scholle – Engineer/Animator

Bryan Sorenson – Environment and UI Artist
We all did some design work, although it was mostly Ngan and I who discussed and
decided on final directions. Our first major session of work and discussion actually resulted
in a playable level. This is thanks in part to Unity. Our game engine of choice, Unity is a
fully featured game engine that allows for quick development. It is very user-friendly and
has great documentation. It allowed for quick iteration and development, and is thus highly
recommended for early development and prototyping.
Around this time, thanks to a friendly email from the EAE program, we became
aware of and signed up for the Imagine Cup. 9 This is Microsoft’s student innovation
competition. As we progressed through the competition, the milestones of the US
qualifying, semifinals, and finals provided real deadlines that allowed our team to stay
motivated in the midst of a busy semester. These deadlines were critical in getting us
together to work on the project. Despite the deadlines, we still did a majority of the work
during breaks (Winter break being the longest dedicated period of time). Even though we
had a somewhat erratic work schedule, we were still able to iterate effectively on gameplay
elements.
9
“Imagine Cup,” Microsoft, 4/21/2016, https://www.imaginecup.com/.
11
The Arrow
The arrow is the key element in the game. It needed to sound, feel, move, and interact
like an arrow. Our first iteration was a stick with a rigid body attached that was propelled
by a force upon firing. In Unity, a rigid body is a component that allows the object to
behave under the influence of the physics engine (PhysX). 10 Unity uses a component-based
system. An object might have a rigid body, a collider, a renderer, and a movement script
that converts keyboard input into motion through the rigid body. 11 Our first arrow was not
very arrow-like.
Next we changed the arrow to have two rigid bodies - one on the arrow head and
another on the shaft. Slowly, through much iteration, our arrow became more and more
arrow-like and more and more of a reusable effective game mechanic. I won’t go into all
technical details, but we continued hacking away at how we built the arrow. We added a
script that made the arrow face the direction of its velocity so that when shot straight up, it
would flip around as it came back down.
The arrow was not flying properly, so we interpolated between its facing velocity
behavior and its initial trajectory to allow it to be shot into objects at close range without
looking bizarre. After this, we noticed that due to the position where the arrow was
spawned when the player shot the bow, they could shoot it through thin walls and other
obstacles. Figure 7 illustrates how we used ray casts from the player’s center to see if there
was an object that the arrow would hit. If there was, we moved the arrow starting point
back so the arrow would collide with the object in front of the player rather than pass
10
11
“Unity Rigidbody,” Unity, 4/12/2016, http://docs.unity3d.com/ScriptReference/Rigidbody.html.
“Using Components,” Unity, 4/22/2016, http://docs.unity3d.com/Manual/UsingComponents.html.
12
through it. The red ray fragment in the image shows the initial arrow position, while the
green fragment is the adjusted arrow starting position to prevent the creation of objects
inside other objects and the shooting of objects past obstacles.
Figure 7. Arrow initial (red) and fixed (green) positions.
Other iterations on the arrow resulted in us manually adding more mass once it got
stuck into an object so it could support the player and wobble a bit. We added specific
enemy colliders that acted as weak points and incurred bonus damage. We also added
special arrow movement as I’ll describe more in the next section.
I have not even mentioned the visual and aesthetic aspects of the arrow, which are also
incredibly important. The team spent an embarrassingly long time trying to record a bow
shooting noise. We went out into the woods with a couple of bows and other tools and
eventually managed to make something that sounded right. Arrow impact noises are also a
really important sound for the game. We still are not happy with the current state of our
impact noises. The look of the arrow is also something that has undergone several
13
iterations. It started out as two stretched ellipsoids and since has switched between three
different models. One cannot simply ask an artist for an arrow and integrate it into the
game.
In order to create a meaningful, immersive world, you need to craft every element to
promote continuity and your overall goal. Our goal was for arrows to be amazing. There
are a lot of aspects that go into making an arrow fun to use. Sound, visuals, challenge, and
progression are just a few. Through iterative development, we were able to create an
effective arrow.
Player Movement
Movement is another critical game element, especially in a platformer. We wavered
between root motion and purely programmatic motion and eventually decided on root
motion because it made things look and feel better overall. Root motion is character motion
based off how much the root bone of the skeleton moves during animation. 12 Essentially,
you are allowing the animation to move the center of the character instead of
programmatically moving it directly. This can make precise control of the character tricky
in some situations. Our air motion did not use root motion and we still overrode it in some
cases for ground motion. Movement went through many iterations.
We started with a cube that could slide on the ground. From there, we added a
temporary character that could walk using Unity’s third person character controller. We
“Root Motion,” Unreal Engine, 4/22/2016
https://docs.unrealengine.com/latest/INT/Engine/Animation/RootMotion/index.html.
12
14
could move, but the movement was not suitable for a platformer game. It was too - the
turn-speed was slow and the jumping was very awkward. Slowly, we iterated and added
more elements, such as much better air movement, sliding down steep inclines, and giving
the player the ability to jump for a short time after leaving an object. Together, these
resulted in a more responsive, intuitive gameplay experience.
The character’s interaction with arrows also needed to improve. We added ray casting
above and below the character, as well as extra collision layers, so the player would pass
through the arrows above her on the way up and collide with the arrows below. Designing
all of these interactions in a waterfall style would not have been feasible. We barely even
knew that the arrow jump was our most effective gameplay element, let alone how it should
feel and work.
If we had had more time, we would have looked into adding the ability to swing on
arrows and we would also have made movement even more smooth and seamless. For both
movement and arrows, we started simply and iterated, adding and revising as we went.
Sometimes we did this based on user feedback and other times we realized that something
could be improved through internal testing. Testing was very important for realizing
movement deficiencies. An early tester realized that the controls were very sluggish. We
had become used to them and had not noticed something was wrong. Once we responded
to this feedback and decreased the delay in controls, gameplay had undeniably improved.
15
Boss Battles
Boss encounters are another example of an aspect of the game that has undergone
intense adaptation. Our first boss was a blob that shot other blobs. In the most recent build,
Goth the Tainted is no longer a mere blob (see Figure 8). He even gets his own theme song!
Figure 8. Goth the Tainted Boss Encounter
At first, the boss room was just four flat planks. It now has moving platforms and
carefully placed trees to allow the player cover and multiple avenues of attack (see Figure
9).
16
Figure 9. Boss Room Right Before a Special Attack hits.
In addition, during his special attacks, the room actually changes as platforms
vanish, making the player more vulnerable to the rain of spiked balls from above. Figure
10 and Figure 11 show another boss fight. In this encounter, the player needs to use the
boss’s own wooden shield as a platforming device to evade his lethal charge ( Figure 11).
Figure 10. Cut Scene Introducing the Second Boss
17
Figure 11. The player shoots an arrow into this boss’s shield and uses it to evade over his lethal charge.
Working with Team Spite on Spire of the Sullen has been a very challenging
experience. The iterative development process we adopted was paramount in creating a
game that lets the player experience what it is like to be Legolas Greenleaf. 13 This can be
seen through the successive iterations we applied to movement, bosses, arrow behavior,
and level design. Even the sounds have changed drastically over the course of our
development. They have transitioned from a couple of loud banging noises to a balanced
combination of ambient torches, quiet water, and drones making up the background
The iconic elvish bowman from Lord of the Rings: “Legolas,” Wikia, 4/22/2016,
http://lotr.wikia.com/wiki/Legolas.
13
18
soundscape, along with a vast assortment of impact and reactionary sound effects. There is
no doubt the game has come a long way since its conception.
19
APLOWCALPYSE – TEAM BACKFIRE
Figure 12. Aplowcalpyse Poster
We worked on our arrow game during breaks from school, but as members of the
EAE program, we also had the pleasure of working in a larger team on our senior project.
This project was broken down into a couple of stages.
Pitching
• Brainstorm
and narrow
down to about
ten game
ideas.
Prototypes
• Form teams
and prototype
those games.
Final Teams and
Development
• Knock off a
couple ideas
and form final
teams. Restart
development.
Figure 13. Senior project process.
We started with everyone brainstorming ideas. Then each person chose their best
idea and pitched it to a group of students. The groups chose the two best ideas and pitched
those to the entire class. Then we voted and formed prototype teams. There was one more
20
pitch to an industry panel of local individuals who work in the games industry to select the
final seven or eight ideas (teams of about twelve).
My pitch about a little fish did not make it past the first pitching phase and I ended
up on Team Backfire working on a game called Aplowcalpyse. Our first task was to remake
the game that had been used as the prototype. What did we have? We had a game where
you are a ship that deflects bullets and kill enemies while unlocking the exit to the map.
What followed over the course of the next two semesters is illustrated best by
Figure 14. Over a couple of months, we pivoted between different game directions and
eventually decided on a multiplayer arena showdown. A pivot is an acknowledgement that
something is wrong with the current state of the game. It is a change in overall game
direction, designed to test a new idea. 14
The process of agreeing upon this game type was not smooth. We pivoted because
certain team members had doubts that the direction the game design was going would result
in a fun end product. There was not always a lot of discussion accompanying a direction
shift and this caused some team members to lose faith in Aplowcalpyse. In the end, we
finally settled on a fast-paced alien smashing game.
14
Eric Ries. The Lean Startup (New York: Crown Publishing Group, 2011), 172-173.
21
1. Bullet Hell
• Bullets keep on bouncing forever. You are thus on a
timer of sorts to make it through the level.
2. Twin Stick
Shielder
• Use a rotating shield to deflect bullets and get
through the level.
3. Shield vs.
Aliens
• Fight aliens with your shielded ship.
4. Avenge Earth
• You are inside the very alien that destroyed your
planet. Avenge Earth. Campaign based shielded ship
adventure.
5. Bumper Cars
vs. Aliens
• You have a plow. Destroy the aliens and avenge
Earth.
6. Local
Multiplayer
Bumper Car
Alien Showdown
• Fight in arena and try to amass the most points by
slaying aliens and staying alive.
Figure 14. The Different Design Plans of Aplowcalpyse
22
Aplowcalpyse has been quite the journey. At times it felt like we arbitrarily changed
directions. This is probably partly due to the fact that I was not directly in control of the
design decisions. Figure 15 shows how the game looked after phase four of game
development.
Figure 15. Phase Four Screenshot (see Figure 14). Avenge Earth Single Player Campaign.
It is not immediately clear what happened, but it was unfortunate that so many
people became unhappy with the direction the game was going. Aplowcalpyse took many
forms. At times, the process we went through to try and find an effective game almost felt
like tossing darts at the dartboard and waiting for one to stick. Several of the earlier ideas
seemed to stick for a bit, but then they either fell out later or were pulled out. What I mean
to say is that the process was not as smooth of an agile development experience as it could
have been.
23
Player Movement
Player movement also went through some changes throughout development. The
ship in stage 1 of Figure 14 used direct positional movement. In this type of movement,
you set the position of the player directly based on keypresses, though they are still
obstructed by obstacles and such. It results in very smooth responsive movement, though
it can be a little trickier to add more physics interactions later. During phase two, we
switched to a momentum-based model where we increased the velocity of the ship as the
player held down the thruster key. We continued to flip-flop as we tried to decide if we
wanted it to be difficult or easy to fly the ship.
There are games like QWOP that are notorious for the difficulty of the controls.
These games can work; they just have a different focus. 15 The point of the game is not
necessarily to immerse the player. In Aplowcalpyse, we did not really know what our goal
was, or perhaps different individuals had conflicting goals. We ended up wavering on a lot
of decisions. Eventually, we went with a compromise and implemented a movement
system using momentum-driven motion with heavy drag. This allowed movement to not
feel too drifty, while still allowing for fairly intuitive physics-based interactions with
obstacles.
Later, we iterated on this movement by adding a boost ability that allows the player
to dash forward and damage enemy aliens. This was necessary after we pivoted away from
a moving shield because the player could now only do little. Through some more iteration,
the dashing mechanic became the focus of the game. We realized that dashing was fun and
In QWOP, the player uses the Q and W keys to control a runner’s thighs and the O and P keys to move his
calves: QWOP. https://www.foddy.net/Athletics.html.
15
24
added a system where the player could dash more often if their dashes successfully killed
enemies. We also added a plower-up that let the player dash as often as they would like for
a short period of time. 16 Aplowcalypse is now a game based around dashing. You dash to
collect plower ups, kill enemies, escape danger, and even kill other players (Figure 16).
Figure 16. Plow dashing to slay an enemy.
Team Motivation
We ran into some problems with work ethic. A big team of fourteen that works
effectively can get a great deal done in two semesters. Unfortunately, not everyone was
working effectively. In fact, people who did work effectively seemed to be the exception,
rather than the standard. As a result, we needed a way to keep everyone on board and
moving forward, so we held weekly all-day game jams on Saturdays. This helped
accomplish work, but it did not exactly inspire more team members to devote themselves
to the game.
16
The player controls a plow. So in Aplowcalpyse, instead of the generic term power-up, the player collects
plower-ups.
25
The Game Developers Conference was the biggest deadline of the two semesters
and we worked a great deal before it to get the game in a decent state. 17 This crunch time
was great for our motivation, even if it was not a sustainable source of motivation. The first
semester ended in an EAE expo day, which applied some extra pressure to get a lot of work
done.
Testing
We did not test the game with others very often. When we did, we immediately
realized problems with the game. At the end of the first semester we tested with outside
groups and we immediately realized some key points:

It was not clear that enemy turrets were un-killable.

Players were a bit confused as to what they were supposed to do.

Green enemies confused people (Figure 17 demonstrates how enemies have
become a bit redder).

17
Controls made some people happy and others angry.
“Game Developers Conference,” UBM, 4/22/16, http://www.gdconf.com/.
26
Figure 17. Final Production Phase Heart Level Screenshot.
Later in the second semester, we went to the gaming charity event Respawn Ready and
got more feedback with potential players. 18 By this time, we already had a multiplayer
game. We received the following criticisms:

There are not enough boosts. Maybe add a boost when you kill an enemy or a
relevant plower-up.
18

There is still ambiguity. Players do not know they have to boost into plower-ups.

Text is hard to read.

The arena spawning system does not seem to be working perfectly.

There are various bugs.
A gaming charity event: “Respawn Ready,” 4/22/2016, http://www.respawnready.com/.
27
These two events taught us one of the most important lessons. What does someone
who has never heard of your game see and think when they first try the game? This is
incredibly important! One important thing we learned was that it is hard for a new
player to know what is going on. New games are confusing. As a result, it is often a
good idea to stick with some standard practices to ease players into the game.
Figure 18. Two players fight off the aliens!
Figure 18 shows the latest build of the game. In the final version of the game, each
player controls a plow with a gamepad controller. Players try to kill aliens and amass points
while disrupting the other players from getting too many points. Sometimes, players need
to work together to bring down a powerful adversary.
28
COMPARISON
The process of working on two games over a relatively short period illuminated some
truths about group work, the agile process, and game development. Team Spite was a small
group of friends, while Team Backfire was a larger group of students working on their
senior project. One important thing to consider when working with large unpaid teams is
motivation.
Motivation Is Key
It comes down to determining what motivates people to do things. Extrinsic
motivators such as money and grades are a good way to get people to do things, but what
if you cannot play those cards to motivate your team? 19 How do you keep everyone
working effectively?
This was an issue we ran into with both projects. On Team Spite there was no
obligation to do work, apart from the fact that we were infrequently pressured by each other
to get something done. With Aplowcalpyse, we were motivated by our grades, the desire to
make something cool, and each other. Neither team was excited and motivated for the
entirety of the project.
It is not surprising that over the course of a year, one’s dedication and ambition can
waver a bit. This brings to mind a notable quote from Albert Einstein himself: “Genius is
1% talent and 99% percent hard work...” Edison made the markedly similar comment that
19
Brown, Lois, Psychology of Motivation (New York: Nova Science Publishers, 2007), 8.
29
“Genius is one percent inspiration, ninety-nine percent perspiration”. 20 To make a good
product you need to put in the hours. It is as simple as that. Agile development was key to
making both projects become more effective games, but to enable agile development, you
need a team that does not falter in the face of problems. A team that is willing to change
yesterday’s work and move on with new ideas.
Actual physical team meetings ended up being a strategy that provided both games
with an extra kick to keep thing moving along. For Aplowcalpyse, they provided a weekly
check-in and extended work session. If you are working with a team and having a hard
time getting people to do work, hold team meetings and work sessions in person. They can
help.
On Team Spite, we also found this to be a useful way to get a lot of consolidated
work in before a deadline. This brings up another powerful motivator. Deadlines. The
sprints for senior project seemed new and scary at first, and as a result, they served as
powerful motivators for the team. By the end though, nobody seemed to care too much
about our bimonthly presentations.
As someone who has a bit of experience with procrastination, it is no secret to me
that deadlines increase productivity. This was also true for both projects. We found that
strong deadlines that carried significant weight were key to keeping people motivated and
getting a good amount of work done. The Imagine Cup deadlines allowed us to move Spire
“Albert Einstein,” goodreads, 4/14/2016, http://www.goodreads.com/quotes/115696-genius-is-1-talentand-99-percent-hard-work; “genius is one percent…,” dictionary.com, 4/14/2016,
http://www.dictionary.com/browse/genius-is-one-percent-inspiration-and-ninety-nine-percent-perspiration.
20
30
of the Sullen forward dramatically. GDC and the EAE open house for Aplowcalpyse were
also powerful work catalysts.
There is one last aspect of motivation that seems too important to leave out. It
seemed that no matter how hard we tried to motivate team members or even ourselves, if
people did not care much for the product, they did not work very effectively. For the senior
project, we had a big group of fourteen people. It was hard to please everyone and keep
them motivated. As a result, some individuals who might otherwise have done more work
never became effective contributors. This could have been addressed by better team
building. Individuals would be more open to hearing others’ opinions and to stating their
own concerns.
We spent a lot of time arguing about what direction the game should go, but
eventually people just sort of made decisions without consensus. This led to unhappiness.
It would have been good to get a general opinion of the change before making an executive
decision that it was the new direction for the game.
Unfortunately, there are some people who do not have the attitude or time to help
out. The lesson we learned was that you have to work with what you have. If you can find
a place where this person might be able to become an active contributor, great! If not, keep
moving forward… Sometimes, some individuals are just difficult to work with. There are
also options though. You can pressure people to do things by assigning them tasks, or a
team leader can sit down with them and try to work out how they will become an active
contributor. The problem with the first approach is that when people do not care about their
task, their work can be full of errors that other people then have to go and fix.
31
The surprising thing is that with Spire of the Sullen, a game made by a group of just
five friends, we still had individuals who were not super engaged. At times I had my doubts
about the direction we were going and the scope of the project, and this did hold me back
a bit. In projects similar to these, it is no surprise that determination will waver. Team
members need to feel they are making the product and they need to become invested in the
product. You do not want to have to be a slave driver.
Be Agile, but Not Too Agile
In a game, if something does not feel right, it probably is not right. In Spire of the
Sullen we had an issue with our controls that we did not immediately address. As a result,
we became used to this control scheme. When we tested with new players, they
immediately found that something was wonky with our controls. It is easy to become too
attached to your ideas.
At the same time, in Aplowcalpyse, we made some huge directional changes that
might have been too much. In essence, we were turning around so quickly that we did some
work for no reason at all. With Spire of the Sullen, we had much less chaos. Instead, we
iterated on our initial design over the course of the entire project. We should have tried to
iterate a bit more with Aplowcalpyse. A rapid prototyping phase at the beginning of
development is a good time to try out various directions. It might have been worthwhile to
do a bit more rapid prototyping on Aplowcalpyse. Instead, we went from puzzle top-down
game where you deflect bullets, to a plow-ramming game where you smash stuff, to a
multiplayer game in what appeared to be a somewhat random fashion.
32
Testing was key in both games. It taught us how other people see our game and it
seems like you cannot do it enough. You do not have to smooth out every little bump in
gameplay and give the player a super easy time. What is important is that you watch them
play and gauge their reaction. Are things progressing as you expected? If so, is the integrity
and experience of the game maintained? With Aplowcalpyse, we tested a lot less than with
Spire of the Sullen, though we probably still did not do enough testing for either game.
Team Backfire pivoted so much that we felt we needed to have a playable game before we
could test, but at the same time we needed to test externally to iterate effectively. There
was also a lot more internal testing for Spire of the Sullen, which is surprising given that
the team was a lot smaller.
It is true that people will play your game differently than you expect. We tested a
lot of gameplay and really tried to hone the arrow mechanic in Spire of the Sullen. I thought
movement was feeling really smooth. Then someone else tried to play the game and they
kept awkwardly bumping into their own arrows. They somehow had the intuitive
expectation that they would be able to maneuver around their arrows more fluidly. As a
result, we added directional arrow collisions. If you jump at your arrow from below, you
pass right through it. This allowed for much smoother gameplay. It would not have
happened without external testing.
In both projects, every time we tested with potential players, we learned a great deal
more about how our game actually played. However, it is important to take what you hear
with a grain of salt. Players do not always know what specifically is wrong, but they are
good at finding that something is off.
33
Disagreement Versus Constructive Criticism
Having everyone make decisions about where the game goes is not always wise.
Everyone has different ideas. While some discussion is warranted, you need dedicated
designers that the team can trust. At the same time, it is good to bring up problems you
have if you playtest. As for game direction, go with your reliable designers as long as the
team can remain strong.
There is a deadly balance between letting people make decisions and involving
them in the game’s direction, keeping them motivated, and moving the game forward in a
meaningful way. If everyone has their say, chances are the game is not going to work too
well (at least for larger teams).
Just as we recognized with Aplowcalpyse, everyone had a different idea of what
they wanted to see in the game, based on the games they had played and made. This resulted
in a lot of talk and little action. Several team meetings were grand arguments that did not
go anywhere. This is partly the problem of having a large team. Eventually, a couple of
designers started making decisions, leaving a lot of people unhappy, even though it might
have been for the best.
Ideally, the designers would have been able to logically explain why they did what
they did and get the majority of the team to agree. On Aplowcalpyse, this did not happen.
Instead, we showed up in class and were informed of the new direction for the game. This
was key in causing some team members to lose interest and become less involved with the
game.
34
On Team Spite, we did not argue anywhere close to as much, but we did criticize
each other a fair amount. It was a smaller team of friends and, as a result, though we did
have our disagreements, we were mostly able to resolve them reasonably. This resulted in
less toxicity. Instead of people getting angry and disappearing, we were mostly able to
discuss and work through issues. As the team size grows, this obviously gets harder and
harder.
Pain and Struggle is Often a Good Sign
There are moments on both teams where I got frustrated and wanted to give up. I
know I was not alone in this. The fact is that if you put enough effort and attention into a
project, the inevitable frustration is a sign that you care. Things never go perfectly as
planned. Especially not on a game.
Your brilliant idea might simply not work as intended. Maybe the game just does
not excite the player as you expected it would. Maybe the mechanics feel clunky and as a
result your brilliant story and grand design falls to pieces. One thing both projects had in
common is that nobody knew what was actually going to work. We had to make educated
guesses and test them out to see if they resulted in effective gameplay.
Fortunately, there are a lot of great games out there. It is important to know similar
games and be able to pick and choose aspects that you found made those games really fun.
You cannot be completely original. What you can do is take a bunch of fun things from the
past and combine them in a meaningful and novel way.
35
CONCLUSION
Creating a game is quite challenging. By working on these two projects and examining
how Team Backfire and Team Spite functioned, I learned the following:

Only pivot if you have hit a dead end. Rapid prototyping at the beginning of a
project can clarify which ideas are feasible and which are not.

Seek to iterate. Hone in on what makes the game great and try to expand on
those features.

Test often (externally and internally) and use the resulting feedback as fuel for
iteration.

Seek to involve the whole team. An effective team is a team where everyone
feels like they hold a piece of the game in their own hands.

Provide extra motivation to the team as necessary. This can be done by signing
up for gaming events, or by creating self-imposed forcing deadlines. For
example, arrange for people to come test the game on a certain day.

Draw on the vast knowledge base of past games for inspiration and advice.

Come up with a game vision and push all elements of the game towards
realizing this vision.
Making a game is not easy. There will be struggles. But at the end of the day, maybe
you can make something you can be proud of, and maybe you can even positively affect
others with your product.
Name of Candidate:
Nicolas Goller
Birth date:
November 30, 1993
Birth place:
Indianapolis, Indiana
Address:
463 E Ninth Avenue
Salt Lake City, Utah, 84103