Ultimate Game Design : Building game worlds

C H A P T E R 1 0
but from continually playing our own and others’ games to see how the decisions made when those
games were created can be best referenced when moving forward.
TM: How do you handle multiple design preferences and multiple design personalities on a design
team?
BR: Being a producer or lead designer in this industry is like juggling cats. You will have numerous
talented and highly independent people all giving input into the direction of the game, and it is your
job to sort through them, pulling out the best ideas for the game. This is a key distinction from pulling
out the best ideas in a general sense; it is important that in all design decisions it is the game, and not
the individual personalities of team members or a desire to be hyper-innovative or the need to be on
the cutting edge of technology, that drives the process. Whether you are diplomatic or hard-nosed in
your interactions with your team members (and both will be called for), as long as they can see that
you have only the best interests of the game in mind and at heart, they will work with you. This also
means that you need to be able to lead by example. If you have a design idea that ends up not being
as good for the game as a concept proposed by another member of the team, you need to be able to
put your idea aside and go with theirs.
TM: Any suggestions for handling the communication loop between a design team’s requests for
features and functionality in tools, and the programming team tasked with building those tools?
BR: If you can get the programmers and designers to agree that the tools are an essential part
of making a great game, you have won half the battle. Again, the focus needs to be on the game
and not the programmers’ “personal” interests or the designers’ “petty” needs. The designers have a
responsibility to give thought to what they are trying to accomplish with the requested tool as opposed
to just saying, “We need feature X.” The programmers have a responsibility to work with the
designers to create a toolset that makes the creation of the game as quick and easy as possible. The
huge benefit is that if there is a strong toolset that a designer can use to get all of his ideas onto the
screen, the end of the project becomes much easier for the programmers because they won’t be
spending all of their time writing special-case code to do what the well-written tool will handle.
As an example, the design and implementation of the World Editor for Warcraft III was key to the
successful realization of the role-playing-game aspects found in the game’s single-player campaign.
The level designers worked hand in hand with the programmers to create a tool that was not only
powerful, but was also easy enough for them to use day in and day out. Although it is not uncommon
to see tools created without much thought given to the end user, the growth of the World Editor was
a cooperative venture between the people making it and the people using it. This was essential not
just because we intended to ship it as a part of the game, but also because we knew that we wanted
to free up our game programmers as much as possible from having to do special-case programming
for the campaign.
By putting a heavy focus on designing a robust tool that the level designers could use to modify
their work and then immediately review it in the game, we not only streamlined our development
process, but we also gave ourselves many more chances to iterate on those designs while reducing our
required quality-assurance testing time. It is said that a craftsman is only as good as his tools, so giving
your craftsmen the best tools possible will help them create the best product they can.
TM: What advice would you offer to new designers? How do you prepare?
261
Getting Started in Game Development