of next generation development can be seen everywhere; it’s at the
water cooler, it’s in magazines, it’s talked about at the Game
Developers Conference and in Game Developer Magazine. With
increased hardware capacity allowing for ever more expansive and
immersive games, everything is growing: Team sizes, asset requirements,
person hour investment, and of-course required capital from investors
to support it all. Audiences are also expecting more. They want more
mechanics with greater functional and technical depth, denser polygon
art, higher resolution textures, more complex AI, more testing and
quality assurance, and the list goes on.
fear of the next generation is not confined to the industry. The press
has caught, and with them the consumer. Game site FiringSquad.com said,
“Game publishers and developers industry-wide are complaining of
ballooning development costs, mostly due to art teams that have to grow
exponentially to create all the content that’s possible.” [Press01] A
vast majority of the problems facing the industry are deep seated in
the very production methodology that is employed. Teams of
approximately 100 people are still using methodologies developed for a
time when ten people were considered a bloated team. There are
game development uses a production methodology that spends a lot of
front-end time, defining intended functionality, often with
implementation of important elements such as mechanics and levels
waiting around until the mad scramble at the end. The traditional
methodology, often called Waterfall, isn’t dissimilar to an assembly
line, with the beginning of the line starting the process of piecing
together the product while the end of the line waits to add polish.
The wait is what creates the problem. Designers and publishers are
never able to get a real feel for the game, for example whether their
initial assessment of mechanics was right, or the implementation of
features doesn’t end up to original specifications. Factors like these
are what degrade product quality..
alternative addresses exactly these problems with traditional game
development methodology. It is, a product R&D process and team
management style aptly referred to as Agile Methodology. Agile puts
the emphasis on producing demonstrable iterations of a game almost
immediately into production, creating prioritized vertical slices that
iterate on the most critical elements and features. The method also
puts great emphasis on the organization of teams and the relationships
therein, as well as the cycles in which teams must plan and carry out
their project objectives. The challenges faced by game development
teams can be numerous and as varied as the divide between the
discipline, such as art, engineering and design, that need to work
together. The road to the end of game projects is also long; short
games are in development for one to two years, bigger titles are
running the gamut from a three years, and in exceptional cases up to
five or more.
paper will cover how the Agile method and a specific methodology,
Scrum, can directly address these challenges, and perhaps are
especially suitable for the complexity game developers, and explicitly
designers, face with next-gen console development.
Most game design or game development books contain very little about
methodology. They assume the vast majority of developers use the exact
same approach, a method often referred to as Waterfall. In the
Waterfall approach work moves sequentially in one direction, such as
from a project requirements or design phase to production and
implementation. There is very little iteration in the early phases,
leaving little opportunity for evaluation. What’s more, much like
running water, once the sequence is in progress the process is not
Waterfall game development, a game designer or group of game designers
will first create the game design document, where they lay out many of
the features and mechanics. The design document is then broken up into
smaller chunks which producers use to extract required functionality
and assets. The requirements for these assets and functionality
elements span the spectrum of teams involved in the project.
begins the sequence of the Waterfall method, as the requirements “flow
down” to animation, programming, level art, character art, QA, FX, etc.
This continues as once an individual or team is done with a piece of a
feature, they then hand it to another. A character, for example, would
begin with the design document and get handed to a producer or a
project director. From there, it would be broken out into its
components: The mesh and texture of the character, the animation, the
effects the character plays when hit, attacking or idling and finally
the AI technology which powers the character. Each department focuses
on its component, then work to implement it until its bears some
semblance of completion.
then moved back to the designer for tuning, handed off to QA for
testing, to the level designers to populate in levels, then bounced
back to various departments for bug fixes. While this character is
being worked on, other individuals and teams are working on their
pieces of specific mechanics. In the same day, a single developer may
work on pieces of several different mechanics. The nature of the
methodology is a percolation, where the game’s many mechanics are
brought from the ground up over time.
In the late 1990s, a number of new software development methodologies
began surfacing, derived from teams ranging from web applet development
to systems powering NASA flights. Each methodology possessed its own
do’s and don’ts, its own mantras and blasphemies, yet despite their
variances, a majority of them had several fundamental things in common.
2001, several of the those who had helped spawned the half dozen or so
methodologies in use organized a summit in Utah. The result was a
central ideology, and a manifesto to go along with it:
- A working piece of software had more value than a document that indicated what the software should do.
collaboration with customers was valued more than extensive contracts
that outlined the intended usage of a product up front.
- Value individuals solving problems rather than processes or tools.
- And most importantly, they valued responding to change over following a plan. [Agile01]
Implementation over documentation, ongoing customer collaboration and the ability to problem solve and change course with agility. The
central tenets to Agile Methodology were short, but they had large
implications, and they were applicable to any complex product
As use of Agile development grew, a number of different methodologies
surfaced. Some were derived from Agile, others were systems that had
been in use but never fully defined or applied to software development.
One such method was Scrum, an approach to product R&D which had its
roots in Japanese car and consumer electronics manufacture. By
definition, scrum refers to a maneuver in rugby where everyone on the
team is involved in an action to move the ball.
a methodology, the same approach is applied to product development in
spirit, where project teams are reorganized into small teams that work
closely together on specific components of a project. Iterative
development is stressed, with the project divided into components that
are “shippable” pieces that can be demonstrated, tested and evaluated
of the principal tenets in Scrum is that everyone on the team is
involved in the process. Scrum breaks down production into short work
cycles called Sprints. At the beginning of each Sprint, the entire
project team meets to create objectives and self-organize into small
Scrum teams. The Scrum teams are interdisciplinary, with artists
working alongside designers working alongside programmers. Though the
goal of each team is determined by project managers, producers and
publishers at the planning meetings, the teams ultimately decide the
path they will use to achieve their goals for the Sprint. Once into the
Sprint, the teams are completely self-managed in their daily planning
and execution of tasks.
recited often by those familiar with Scrum, projects become delayed one
day at a time. For this reason, a critical component of Scrum is daily
meetings among individual Scrum teams throughout the Sprint. The
meetings can be as brief as 5-10 minutes, and are designed to ensure
that objectives are on track, any impediments to progress are
recognized, and daily accomplishments are seen by everyone involved. [Agile02]
The process creates a sense of ownership among every member of the
team, and its transparency is designed to create accountability among
team members that ultimately boosts productivity.
the team self organizing, regular reviews keep the team on target and
give everyone a full diagnostic of the product in the purest form
possible; how it looks and performs. At the completion of every Sprint,
the teams conduct reviews that demonstrate their accomplishments, and
allow their product owners or “customers,” such as studio managers and
publishers, to evaluate progress. The customers can then determine what
the priorities are for the next Sprint.
A simple visualization of Scrum. Game features are broken down into
individual tasks by programmers, artists and designers, they then work
on these for an iteration of two weeks to a month, accounting for their
tasks and to each other in a daily meeting. At the end of the iteration
a product review occurs of all work done for that iteration where
project directors and publishers can determine how to prioritize the
next iteration based on the work done in the latest.
goal for these teams when reviewing with their customers is to
demonstrate a “vertical slice” of the game, as in a piece of a game
such as a single level hub or a completely playable mechanic or a tuned
feature. While not all mechanics can be delivered in a single
iteration, the individual pieces of them become the vertical slices
that teams focus on. For example, an AI character is very difficult to
deliver in a single Sprint. Yet a single behavior of that AI character
can be fully programmed, animated, have sound attached to it, be
deployed in a level, etc., resulting ultimately in something that can
these two elements in mind, a customer can look at a product and see
exactly what’s been achieved, where it’s going, how fast production is
progressing, etc.. A customer does not need to guess or have faith,
they can see a direct diagnostic, and often by picking up a controller
rather than looking at spreadsheets or wireframes. Scrum also gives
customers flexibility from iteration to iteration, just as it does
have room to redirect project goals between Sprints if what’s been
created and evaluated is not living up to expectations. And because of
the iterative process of Scrum and the short work cycles of Sprints,
redirecting a project rarely results in large volumes of wasted work.