|
By
Josh White
Gamasutra
June 19, 1997
|
|
|
 Features
Game
Artist Survival Guide
"Game
artist" and "survival" are all too often used 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 I’m here to share some of those tuition-free lessons. In this first
installment, I’ll 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. There’s
lots of specific tasks that are called "planning" - from low-level stuff
like level design to high-falutin’ conceptual work like game theory.
Here, I’ll rail about "game production planning" - the decision-making
that happens when a game project is about to start. I’ve 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 Don’t
Artists Plan?
There are lots of reasons why artists don’t usually get involved in
planning. Artists aren’t usually invited because most organizers don’t
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 aren’t interested in dealing with paperwork, budgets
and schedules, which is the lifeblood of the planning phase. It’s 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, it’s 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, let’s
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 I’ve
hacked it all to bits and reassembled it with an artist slant here, so don’t
blame him for it!
The Spec
The game specification ("spec") is the key document in any planning process.
It’s a basic blueprint of the game, defining who this game is targeted
towards, what its innovative gameplay ideas are, what platform it’ll
run on, the basic plot/concept, some general things about the type and scope
of art, and some technology issues. It’s 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 it’s 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, we’ll 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? What’s
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 - we’re
just testing performance of the target system because we know we can’t
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 it’s vaguely similar in design and face
count to what you’re planning, and see if it’s 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,
here’s 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, we’ll 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 everyone’s sold on the budgets, write them down
as part of the project specification, and start in on production phase.
- It’s
worth noting that planning doesn’t end when production starts -
it’s 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 project’s 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, isn’t
this whole process a gloriously sterile dance of foresight, cunning, and
leadership? You savvy artists! I can hear you-all muttering: "That’s
nice, but what the heck am I, a production artist, supposed to do in this
process?!" Well, in the spirit of planning, here’s 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 it’s well written and available from the start, it’s
a glimpse of your professional future as development takes place. From
it, you can learn what new technologies you’ll have to master,
what import/translation tools you’ll 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 aren’t confident that they’ll 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 you’re
a lowly pixel pusher, so you think you shouldn’t attend. Wrong!
Remember that YOU, the production artist, often know more about what’s
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 what’s 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- don’t criticize unless you plan to
defend it, admit when you don’t know, and stay focused on why you’re
there.
Sometimes getting in to the meeting isn’t an option: you’re
simply not welcome. In these cases, get to know the people involved
in planning and at least keep in touch with how it’s going. If
art-related things sound sketchy and worrisome, or you really want to
give some input, I’d 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 it’s 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: it’s also a guide to the hardest parts of the artwork.
Innovation, from the planning point of view, means untested and problematic.
For example, let’s say you’re the new artist eating a burrito
lunch with the programmer. He’s all psyched about this new project
and goes off: "Dude, this new game PsychoKillerDoggies is the bomb!
Yah, it’s so hot, our hero dog’s got awesomely greasy, smelly
dog hair! We’ve got this 3D Barbie we’ve been using as sample
art, and the hair looks all flat and sticky, just like unwashed dog
hair!" Aside from losing your appetite, you’ll 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 aren’t naturally interested in greasy dog hair,
ask more questions about how it’ll 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 aren’t about to
destroy their mood with a crisp, clean project spec - heck, even a scrawled
napkin feels kinda formal and constraining. Hey, that’s cool -
excellent game designs don’t require formality...but no matter
how small or informal the game design is, no artist should start work
without knowing what they’re supposed to be drawing.
At a minimum, you’ll 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 isn’t finished if this document doesn’t
exist, so don’t start work without it!
I hope
you agree with me that planning is where game artists get the size of
their canvas decided -- so artists should be involved!
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.
|
|
|
|
|
