For every
game that sets the high-water mark in design and/or game play, there are
dozens of titles that don't. Why is that? I've discovered a number of
possible reasons. Many games are made by people who shoot from the hip
instead of taking a good and proper aim at success, many designers are
relatively new to their jobs and aren't certain what's expected of them,
and few development companies have established a formal design processes
for creating and implementing a game.
Books and magazines are only now dedicating themselves to the craft of
game design. Because it is an inherently creative task, everybody thinks
they can do it. If that were true, there'd be more games out there with
better control, better AI, more user-friendly front-ends, game mechanics
that the average 12 year old can immediately pick up and play, and less
games clogging the clearance bin at Software, Etc. A harsh reality story
a friend of mine likes to tell regards a VP of development-type for a
larger developer/publisher asking why he should invest 1.4 Million dollars
in his project versus simply investing it in the stock market. The answer?
The possibility of an astounding return on investment provided the game
is well designed, on time, and fun to play.
This primer for the design process is broken into three separate sections:
Do, Think, and Need. The first article explains what you need to do to
get ready to make a game, the second looks at what you need to think about
while you're making the game, and the final piece examines what you'll
need to do the task.
What to Do:
The primary task of the Designer is to design the game. That sounds simple;
it was meant to. More goes into designing a game than writing frilly paragraphs
about just how cool you think your idea is, just more is required than
writing a massive, hernia-inducing tome of endless and unnecessary detail
that no one but the author can bring themselves to read.
Good design is about the implementation of ideas and details. To know
what you need for your game, you need to know what's going on around you.
You need to know what the market might support and what the market is
sick and tired of seeing. You need to know what your company (or those
funding your company) may or may not want to see. In short, you need to
start by asking some questions.
1.
Asking questions
This is as simple as it sounds, you need to ask questions before you
begin to write your design doc. There are a lot of things to consider
while you're cooking up ideas for your next platinum-selling title.
By no means is this list all-inclusive. Some questions might be irrelevant
to your respective situation -not all games need the same considerations-
while some projects might require additional questioning. Determining
which questions to ask is one of the most important parts of your job.
What
are the current trends?
What are current trends in design? Scan the trade-mags and look at what
and who are causing a buzz. As technology gives us the ability to push
more polys, build and view larger worlds, light them in real-time, and
maintain an acceptable frame-rate, we see that gamers are expecting
more from their entertainment. One way that certain creative companies
have kept the ongoing interest of gamers is to blur the lines between
established genres. It helps us to challenge what's become "accepted"
and push the veil of innovative design.
|
|
Screen
shot from WWF Warzone
|
Trends
can also exist in things like options and utilities-how the competition
is empowering the player by giving them more control over their game
play environment. One standard now being called for in the wrestling
genera is the need/want to create custom wrestlers from the ground up.
This became the most talked about feature on the US side with WWF
Warzone, and now THQ and EA both incorporate more "player-empowering"
concepts into their titles.
What
is marketing looking for?
This could be restated as, "What are gamers looking for?"
Look to the marketing experts, they should have a good idea about what
people want. They do the focus-group testing, they should be compiling
data from this feedback. Also, consider what the market can stand. "Me-too"
products usually sell much less than the product they're emulating.
What
current tools do we have access to?
For example, look at what motion capture did for animation. Don't get
me wrong, I'm not advocating an "all motion capture, all the time"
game world, but that kind of data is an excellent way to build a foundation
that your well-paid and well-respected motion editors can start from,
tweaking the motion to fit the design after the fact.
3D authoring and world-building tools are still probably the most prevalent
example of things that can help or hinder the design process. Preexisting
tools can also give you jump if you need to either prototype a concept
in a hurry or if you need to race to make the Christmas buying season
before you loose the license for your game.
Tools give you a way to either prototype a design to get an idea across.
They also allow you to get a job done with less hassle. Recycling technology
is not a bad thing, unless the only thing your company can hype is tech
with no game play.
Some genre's lend themselves to certain kinds of music, often from professional named bands or individuals. Take a listen to what's good, what seems to be happening, then incorporate its style into your title. Some marketing folks will fork over a chunk of your development budget to sign bands or individuals to do the music for your title, but it's been my understanding that very seldom, if ever, will a person's decision to purchase a title be based on the fact that someone they may have heard on the radio once did the music for the game. In certain cases having a named talent do the music might add to the "cool" factor and help generate a little buzz on websites or the odd magazine, but it's not going to sway the consumer and it can also be a huge licensing hassle with no real guarantee that what gets written for the game will be delivered on time or be any good. If there's any question, a good solution is to try to get a synchronization license (Where you get the right to cover the song, but not to use the original recording by the original artist) for a piece of music you'd really like in your game.
|
|
Screen
shot from Toon Struck
|
Some companies
have been known to waste a ton of cash trying to get a particular vocal
talent or talents to act in their game as, unfortunately, a major marketing
aspect of the title. Did it matter that Rob Schnider was the main vocal
talent in A Fork in the Tail, or Christopher Lloyd was in Toon
Struck? As above, more often than not most gamers won't buy a title
simply because there's some celebrity voice actor that they button past
in the first 2 seconds of hearing it in order to get back to the game
play.
Get something (or someone) good that fits the attitude of the game,
and it will increase the gaming experience for the player. That's all
you need to be worried about.
What's
been done and how was it done?
I talk about this later on in the "Think" section about Critical
Evaluation, but this is a very important issue when you first start
your design. There's absolutely no need for you to tell a story that's
already been told, or develop a game that's already been done, or rehash
a genre that's on the way out. Do your research and learn from that
research. You should be playing games, plain and simple. You need to
know what's out there, what's already been done, and how high the bar
has been set so that you can clear it.
2.
The Working Design Document
Once you've focused your ideas, its time to think about the design doc.
The design doc acts as a script; it should be giving every other professional
involved with the product a more than firm idea of what they need to
know to implement their portion of the product.
Like other parts of the entertainment business, there are some basic
rules and formats for how ideas are presented, as well as a few things
that people no longer want to see. Publishing has its "double spaced
12-point Courier font" from the old Smith/Corona days, and film
and TV have standard script formats for either television or the silver
screen. These formats are not only expected, but also demanded.
Our business is a little different. It's not quite old enough for standards
and guidelines to exist, but we're moving into the "broad spectrum
formalization" for industry standards and practices. Simply stated,
tradition has bred expectation. Certain questions should be answered
before the thing is sent to production. This is your job, O Maintainer
of the Creative Vision. You need to answer these questions and more,
as everyone on the project will be coming to you or your people for
information and the lo-down on what needs to happen and, more importantly,
how it's supposed to happen.
Design documents tend to fall into one of two formats: they either loosely
describe a game concept so upper-management can sign off on the idea,
then get dropped into someone's filing cabinet never to be read again
OR they are the size of your local Yellow Pages, filled with every imaginable
detail that no-one but the person who wrote it cares about or is willing
to read.
In an effort to maintain the working lines of communication between
the design staff and the production team, we came up with the idea of
a "feature-oriented" document that could keep everyone on
the team up to date and informed whenever a design change was made or
redesigned.
If you look a production movie script, you'll see that there are different
colored pages at any given point throughout the entire script. These
pages represent changes that have been made to the script since the
start of filming. The colors allow the cast and crew to follow the changes
and thus maintain continuity and keep everybody -pardon the unintentional
pun-on the same page when updates occur.
Like a script, things in a design document will change due to circumstance,
talent, or innovative problem solving on the part of management or the
production team. These changes should not only be noted, but also sent
out to the people whom they affect.
The
Feature-Oriented Design Document
Our feature-oriented design document began as a basic form that could
help keep the 6 people involved with the design document up to date.
It was designed not only as a fluid guide for everyone on the team,
but also as a living document that could carry us through the ongoing
design of 3 different games.
We put the design document on our LAN, with the design team continually
adding to or updating the document at the same time. Version control
is a simple matter of the software (in this case MS Word) not allowing
more than one person to work on an individual sub-document at any given
time.
The document itself incorporates a couple of features that help with
keeping things organized, including major headings calling out important
items like what the engine needs to do to, AI requirements, game modes,
motion requirements, and on and on. Under these heading are the particular
sub-documents explaining the features or functions that individuals
on the team have been tasked with designing. Whenever a new design feature
is nailed down we can send out updates to the relevant team member through
E-mail with a hyperlink attached to the virtual document for easy access
by team members. We can do this because the document is being written
with the whole team in mind.
The sub-documents themselves take the form of a numerated template with
the heading numbers tied to the table of contents. This allows us to
sort these documents by feature or project when we work on layers of
design for separate products. The template helps push for a more detailed
design for each feature and also helps the designer answer questions
up front, allowing for a more thorough design when the project hits
production.
This template also allows us to design for more than one version of
the game. Some design features have been layered to appear over a series
of releases and as such, you're always on the same page with whatever
feature you're thinking to forward.
The master plan for the design document is to have it linked with both
a Technical Design Document that's arranged in the same manner and some
sort of scheduling software like MS Project. This has the added function
of allowing us to asses any impact to milestones or budget new design
features may have.
The
Template:
The major reason most artists and programmers don't read the design document is that, if there are any practical design features contained within, they are usually buried in page after page of ongoing paragraphs. Simply stated, no one wants to weed through it to get to what they need to know. The template, in this form, serves the major function of being digestible in small relevant chunks.
Remember, this is a FEATURE-ORIENTED design document, which means that
it is put together with certain goals in mind, and these goals are broken
down into doable bits.
- 0 TABLE OF CONTENTS - This needs to contain EVERY major heading that you'll be dealing with. It should include sections like AI, collision, level design, front-end logic flow, controller input, and the like.
- 1
FEATURE HEADING - Describes and numerates the issue/feature in
question. The numerical index, established in the TOC allows for easy
finding and sorting once the project is underway.
- 1.1 Contact and "See Also" Information - Straightforward: Point of contact for who designed the feature and what other documents it relates to outside of this one.
- 1.2 Goals - A bullet list of associated goals including problems you may encounter implementing this feature and possible solutions to said problems.
- 1.3 Implementation - How you're going to affect the feature. This is where you'd include formula, diagrams, or flowcharts that layout the design feature in question that all relative parties may need to know/follow to get the feature up and rolling.
- 1.4 Impact - How this feature will impact the current status quo. You can't always crystal ball this, but in our case we're making changes to an existing engine/game, so some changes do affect the way we're currently implementing some features. An example of this would be having a new action for a wrestler to do, and needing a button-press to pull it off when we're already overloaded here. Another use for this heading is to help you identify extra resources you may need, and schedule relevant needs to bring the feature into line.
- 1.5
to 1.8 Tasks & Questions for:
- Designers
- Programmers
- Artists
- 2D
- Modelers
- Motion
- Sounds
There
must be "Tasks & Questions" sections for each arm of the
development team. This allows the Designer, Artist, Programmer or Sound
Designer in question to skip straight to the task relevant to them without
having to filter through all the other text. This also lets the design
team ask any questions they may have at a time when they might not have
access to the person that could immediately answer it.
You'll also want some way to tag features that have been dropped or
held back for whatever reason. You don't necessarily want to delete
those features, as they may make their way back into the current design
or appear in the sequel if you're doing one.
In our particular case, we're working on the design for several titles
at one time. Each heading is further expanded into 3 sub headings-one
for each version-and color coded to make reading and separating them
on-screen a little easier.
E-mail
and the Hyperlink:
With the design doc online, we're able to send intranet e-mail to all
concerned parties when a feature is designed, changed, or dropped. In
addition to the email saying, "This feature has been designed,
changed, or dropped," we can also add a hyperlink which, when clicked
upon, will take the concerned party directly to the page(s) they should
be reading.
The e-mail has a secondary consideration in that the Project Manager
will know when and if the Email is being read. This helps in maintaining
team accountability for what each person's job should be, and how they
need to implement it when the time comes. This kind of organization
lends itself to a HTML-type document as well. We're currently setting
up just this kind of accessible, online document using MS Frontpage.
You could also use Dreamweaver if you were so inclined. This allows
anyone with a web browser to access the design doc and very easily navigate
their way to whatever piece of info they need. Even better, you can
do things like create art bible's, complete with linked thumbnails and
actual photo reference on the network, making sure all or your resource
is available and protected.
The next section (THINK) will go deeper into asking questions about what you're supposed to be doing as a designer. This also includes my list of "Nevers," garnered over the years both from friends in the industry and from simply doing things the hard way.
Tim Huntsman has been with Acclaim Studios, SLC for over 4 years and is the Lead Designer for Acclaim's next-gen wrestling title. He has worked on the ECW wrestling franchise as well as the genre-defining WWF Attitude for PSX and N64, projects that taught him more about professional wrestling than he ever thought he'd know. When not working on games and their design, he's playing guitar in experimental projects, writing various forms of fiction, painting in the Sumi-E style, and fencing (with swords, not wooden planks.)