By Josh
White
Gamasutra
June 19, 1997
Vol. 1: Issue 1
|
Part 1: Planning
Game artist and survival are all too often in the same sentence. You, the
savvy game artist, seek knowledge that will help you survive, and even thrive,
in this wacky industry. I am a graduate of the School of Hard Knocks, with
an advanced degree in Hopeless Game Projects, and Im here to share
some of those tuition-free lessons. In this first installment, Ill
introduce artists to an area of game production that is, alas, often untouched
by artist hands: planning.
Game planning is a pretty vague job, like most game development areas.
Theres lots of specific tasks that are called "planning" - from low-level
stuff like level design to high-falutin conceptual work like game theory.
Here, Ill rail about "game production planning" - the decision-making
that happens when a game project is about to start. Ive included concept
design in planning (though it could easily be the other way around) because
it helps connect the two ideas in a logical, convenient-to-explain way.
Why dont artists plan?
There are lots of reasons why artists dont usually get involved in
planning. Artists arent usually invited because most organizers dont
see the need for an artist involved in planning. Also artists are sometimes
hired after the planning stage is complete, so they miss out on it entirely
(or so they think).
Second, many artists arent interested in dealing with paperwork, budgets
and schedules, which is the lifeblood of the planning phase. Its a
guesswork, negotiating, managerial kind of thing, but the ideas and decisions
are key to artists - and sometimes artists have a surprising amount to
contribute.
And finally, in large organizations, its a class thing. Project planning
and design is done by movers and shakers, and they usually run in different
circles from production developers. This can form a barrier in unenlightened
organizations (see below for advice on this).
Quickie Intro to Game Development Planning
OK, so what does "planning a game" mean to an artist? To answer that, lets
start with some context and skim over planning a software project as vague
and performance-oriented as a game.
[footnote] This overview originated on a very good presentation given by
veteran planner Rick Bess, Product Manager at Newfire Inc., but Ive
hacked it all to bits and reassembled it with an artist slant here, so
dont blame him for it!
The Spec
The game specification ("spec") is the key document in any planning process.
Its a basic blueprint of the game, defining who this game is targeted
towards, what its innovative gameplay ideas are, what platform itll
run on, the basic plot/concept, some general things about the type and scope
of art, and some technology issues. Its usually 5-50 pages, with a
few level maps and concept sketches.
Ideally, the spec is an evolving, living document, constantly updated as
the plan changes, and accurately reflects the concept and planned implementation
of the game. That means that its being changed a lot, so you can expect
to see very different versions as the game progresses. In the beginning it
may be a "Cool concept, no clue how to do it" thing... and by the end of
development the spec may have incredible detail -- like time sheets and checkoff
lists -- integrated into it.
The Majestic Bullet-List of Basic Planning Steps
-
Concept Design is the first step. Start with
a good idea & vague budgets flesh it out into a basic idea for a game.
A few sketches are great, but vague is fine- character details can come later.
A good working name for the concept ("PsychoKillerDoggy") can set a super-basic
tone as well as make organization easy from the start. At the end of this
step, well get a really skeletal spec.
-
Setting Performance Goals should come next. This
is where we take the first step to matching the concept design to reality.
The idea is to define what this product needs, technology-wise, to make its
impact on the user. A lot of these questions directly affect the artist.
For example Can we get by with 256 colors or do we need 24-bit truecolor?
Whats a minimum framerate to provide the experience we need?
-
Target Platform: Picking a playback system comes
next. Is this a console-only game? Nintendo 64? both 486 and P200? Easy to
ask, tough to answer.
-
Mock-up and benchmark The idea is not to mock-up
the "look" of the art - were just testing performance of the target
system because we know we cant trust any performance numbers from the
vendors. Yes, this means an actual hardware system is needed. Throw any old
clip-art geometry into some kind of scene, as long as its vaguely similar
in design and face count to what youre planning, and see if its
conceivable that this game could work. This will give us a starting point
for art budgets - how many faces can it really draw? - as well as some valuable
hands-on experience with our platform.
-
Make engineering budgets: This critical step
is where everyone figures out how much time to build, many faces per scene,
texture memory, time, and other resources are allocated. For RT3D projects,
the frame rate depends on a lot of budgeting issues and decisions - (screen
size, face budget, texture budget, platform, other stuff) - so this is where
the frame rate gets battered around a lot on this step. (for reference,
heres some generic 1997 RT3D performance numbers: 15 fps at 640 x 480,
with 2k faces and 2MB textures, on a plain P120, 16MB RAM)
-
Loop if necessary: If the budget answers are
really bad, well start the cycle again by substantially revising the
Concept Design, adjusting our Performance Goals, and possibly the Target
Platform, retesting, and so on.
-
Start Development: Once everyones sold
on the budgets, write them down as part of the project specification, and
start in on production phase.
Its worth noting that planning doesnt
end when production starts - its normal that each new game feature
go through a scaled-down version of this process, for example. Also, it can
repeat on a large scale: if the projects in trouble, this entire planning
phase can be revived as the game changes to address the trouble.
What should an artist do in a planning phase?
Oh, isnt this whole process a gloriously sterile dance of foresight,
cunning, and leadership? You savvy artists! I can hear you-all muttering:
"Thats nice, but what the heck am I, a production artist, supposed
to do in this process?!" Well, in the spirit of planning, heres a nice
neat guide to your involvement.
Artist Involvement Checklist:
Get the spec.
The spec is the key to understanding what the heck this game is. If its
well written and available from the start, its a glimpse of your
professional future as development takes place. From it, you can learn what
new technologies youll have to master, what import/translation tools
youll be using, what issues are going to be problematic from an art
point of view, and game-style information - like what the game will look
and feel like.
Sneak into planning meetings
If your organization is big enough to hold closed-door planning meetings,
you need to make sure they address art issues. If you arent confident
that theyll consider art issues well, your goal is to infiltrate those
elusive meetings, learn what plans are going to affect art, make sure resulting
issues are addressed, and duck out again. If you can do this without making
any enemies, you win.
Yes, the VP of TechnoDogHairSimulation may be at the meeting, and youre
a lowly pixel pusher, so you think you shouldnt attend. Wrong! Remember
that YOU, the production artist, often know more about whats actually
going on than they do and realize that they need your knowledge. It
surprises me how often high-level executives are happy to have someone tell
them whats really going on down in the trenches, and will take you
under their wing. Of course, with power comes politics - for example,
contradicting and embarrassing your boss is a risk, so be careful in your
approach- dont criticize unless you plan to defend it, admit when you
dont know, and stay focused on why youre there.
Sometimes getting in to the meeting isnt an option: youre simply
not welcome. In these cases, get to know the people involved in planning
and at least keep in touch with how its going. If art-related things
sound sketchy and worrisome, or you really want to give some input, Id
recommend carefully writing a short, powerful, honest note expressing artist
concerns (in quick, easy Problem/Solution bullets), and then get this to
the Inaccessible Planners as food for thought.
In simpler situations (like small game production houses), these meetings
are usually open to anyone on the project, and its pretty easy to make
sure art issues are addressed.
Know unique / unusual parts of your project
Knowing what makes this project cool usually has a second purpose besides
the obvious fun of Hearing the Cool News: its also a guide to the hardest
parts of the artwork. Innovation, from the planning point of view, means
untested and problematic.
For example, lets say youre the new artist eating a burrito lunch
with the programmer. Hes all psyched about this new project and goes
off: "Dude, this new game PsychoKillerDoggies is the bomb! Yah, its
so hot, our hero dogs got awesomely greasy, smelly dog hair! Weve
got this 3D Barbie weve been using as sample art, and the hair looks
all flat and sticky, just like unwashed dog hair!" Aside from losing your
appetite, youll want to get some clues about how artists could specify
the hair in their art tools - is it a special object name?
Also, even if you arent naturally interested in greasy dog hair, ask
more questions about how itll work: "Rancid-n-Real DogHairSim Technology
- gotta love that concept, dude! So, uh, how real will it really look? Will
all the hairs move around OK if the dog scratches itself? Can it shed? How
about the length - can we get long, oily strands on the carpets?" Once you
find out the sordid details, be sure to get this information into the plan.
Usually that means adding enough artist time to R&D for this cool new
technology.
Bottom line: Art to-do list
This bullet point goes out to you artists in the back of the room - the ones
on funky evenings-garage-no-money types of project. Those projects
game designers arent about to destroy their mood with a crisp, clean
project spec - heck, even a scrawled napkin feels kinda formal and constraining.
Hey, thats cool - excellent game designs dont require formality...but
no matter how small or informal the game design is, no artist should start
work without knowing what theyre supposed to be drawing.
At a minimum, youll need a simple list of things to create. In more
organized projects, this is usually part of the spec (in the engineering
budget), and includes text descriptions, perhaps sketches, time milestones,
and dependencies for each major piece of artwork needed. In either case,
the game planning stage isnt finished if this document doesnt
exist, so dont start work without it!
The end.
Thats it for this article. I hope my beloved readers agree with me
that planning is where game artists get the size of their canvas decided-
so artists should be involved!
Biography:
Josh White
(josh@vectorg.com) has been building
real-time 3D models for games since 1990, wrote the first book on real-time
3D modeling: Designing 3D Graphics. His 3D modeling experience ranges from
mechanical engineering simulations to "normal" 3D animations (including the
1993 CGDC awards ceremony animation). Since 1997 he has relaunched Vector
Graphics (his art production company), lectured and exhibited at the 97 CGDC,
and presided over the CGA,
(http://www.vectorg.com/cga), but
he admits that all this really kills time between soccer games.
|