Game Artist Survival Guide

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.

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!