There's far more to being an animator, modeler, or 2D artist than just pushing pixels. Artists must interact with programmers, producers, and other team members, and overcoming those communication challenges is one of the biggest hurdles. See how it's done.
Things are pretty rosy for us game developers -- a fairly healthy industry, super casual work environments, and creative, exciting new technologies to explore. But it's not all fun and profit: We've got problems, and there's plenty of room for improvement. Aborted projects are a major source of burnout, generally cutting into the fun and glory that game development should be.
One of the hallmarks of failed projects is communication breakdown. Why?
Because good communication is damned hard, and it's one of those mushy personal skills to boot. It's much easier to study tools than to learn to ask questions such as "how many textures can I use?"
This article teaches both skills to artists. Once we identify the artist's coworkers, we'll examine the psychology of the artist/programmer relationship, pitfalls, handholds, and those inevitable nuggets of advice.
A word of warning: I've sketched some big stereotypes in this article. They're not intended to be rude or to offend -- I wrote them to help identify common interaction problems. So grit your teeth and hold your fire if you're insulted by the idea of stereotyping, but do speak up if you disagree with my basic generalizations. I write from a wide and varied experience, but it's only one person's experience -- more is always better.
Degrees of Separation
Remember the movie "Six Degrees of Separation"? It was a heartwarming story about some poor guy who scammed his way into high society, with the shocking conclusion that poor people are human after all. Anyway, the title expresses an intense idea: Everyone is a friend of a friend of a friend of a friend of a friend of a friend (hence the term "six degrees").
Let's apply this idea to the artist hard at work on a game. The artist's first-degree contacts are the developers that the artist interacts with daily, as shown in Figure 1; second-degree contacts perform functions such as testing and sound production, as well as nondevelopment things such as legal, marketing, and so on.
The Art Director. This person tells the artist what design/style of art to create and reviews the work for visual quality.
Artists. Peers who interact as they work. Other artists who may be working off site report directly to the art director.
Tool Programmer. This person tells the artist exactly how to import art into the game (and usually writes that code).
Game Designers. The designer decides what art pieces are needed for the specific game experience.
Producer. Generally, the person in charge. The producer makes decisions about what the game will and won't consist of, in terms of its features and the overall look and feel. They also coordinate other development efforts, such as sound and testing, and act as a firewall for publishers, lawyers, press, and other nondevelopers involved in the project.
Lead Game Programmer. This person decides what the game can do (and codes the functionality of the game). Depending on the team, the lead programmer may or may not directly interact with the artist.
Project Manager. The project manager keeps track of the schedule, equipment, and costs. Sometimes, the producer takes on this role.
Example Artist Interaction: Q&A for New RT3D Art Assignment
Before starting a new assignment, the artist needs to know specific information about the project. Without proper briefing, the art isn't going to match the needs of the game. This major communication event provides a rich stew of interaction to observe. Since art assignments are very project-dependent, no complete, general-purpose checklist for eliciting the proper information has yet been developed. Nonetheless, I've created a hypothetical conversation so we have realistic information.
In my scenario, the experienced contract artist has just been hired to crete artwork for a real-time #D game already in development. The artist is now getting acquainted with the project and its team members. As the artist asks questions of various team members (in the left-hand columns), I analyze the answers from both a psychological ("psych") and a technical ("tech") standpoint, which you can see in the right-hand columns. This will help you understand the context of and motivations behind the answers.
Artist: What's the basic idea of the game? Producer: We're building a simple, real-time 3D comic strip about a cat that is hunting a bird, as the bird sits in its cage. The style is simple with somewhat realistic rendering. It's a cartoon, but we don't want any drastic squash and stretch effects. |
|---|
Psychological Interpretation: Contractors are often brought into a project without being told any more than necessary. The artist needs to know some basic context to do his or her job. |
Artist: What artwork do you need, exactly? Producer: A bird, a cat, the birdcage, and the room, plus some animations. |
Technical Interpretation: The purpose of this question is to clearly define the assignment. If the artist had more design freedom, he or she would make a detailed list of objects to build. |
Artist: What's the face/polygon (or vert) budget? Producer: For the cat, the budget is 250 polygons. |
Tech: The basic geometry budget must be known up front before any work begins. Like most budgets, the polygon count is usually approximate, since its purpose is to guarantee a certain frame rate for the final game. A cat can be created using 250 polygons, but it won't be very detailed, so let's hope the engine has good texture-mapping capabilities. |
Artist: What kind of polygons are supported? Producer: Convex planar polys are supported. |
|---|
Tech: The usual answer to this simple question is either "Only tris [three-sided polygons] are supported," "Quads [four-sided polygons] and tris are supported," or "Convex planar polygons with any number of sides are supported." When tris are used, geometry doesn't have to be planar and convex. This type of geometry is easier for the artist to work with, but requires more tris to build a model. Quads and n-sided polygons must be planar and convex, but fewer polygons are necessary to construct planar objects. |
Artist: How are the polygons created from tris? Producer: If two tris share an invisible edge, they will be merged to a quad. |
Tech: This is a pretty standard solution to the problem that some modeling tools have, most notably 3D Studio MAX and 3D Studio 4.0. The problem is that the tools don't directly support any polygons besides tris. Our hypothetical programmer's solution isn't the only way to merge tris into polygons. For instance, sometimes a part of the art import procedure accepts a 3D data file, looks for coplanar tris that share edges, and replaces them with polygons. |
Artist: What tolerance, if any, is used when deciding that a quad isn't planar? Producer: One degree or less out of plane is O.K. |
Tech: This question applies if the import procedure has the ability to accept slightly noncoplanar quads as coplanar. This can save a lot of unnecessary editing, since it's common during normal construction for some faces to be slightly noncoplanar; it's difficult to make all faces perfectly coplanar. |
Artist: Are T-intersections allowed? Producer: Yes. |
Tech: The most difficult aspect of this question is agreeing on what a T-intersection is. As Figure 1 shows, T-intersections occur when one face touches another face, either in the center or at an edge, without sharing all vertices. If the answer is "no," the artist needs to understand the consequences because sometimes T intersections are almost impossible to prevent. |
Artist: Are intersecting faces allowed? Producer: Yes. |
Tech: This question may be asked instead of the sorting question that follows, but an understanding of the various sorting options is preferable to a simple yes or no answer on intersections. Be sure that the programmer agrees on the definition of "intersecting faces." What artists generally need to know is whether two faces can cross each other, forming a line (or a plane if they are coplanar) of intersection. |
Artist: What kind of sorting is used? Per-pixel Z-buffer? Per-face BSP-tree sorting? Producer: Z-buffer sorting, with object culling. |
|---|
Tech: The main purpose of this question is to determine whether intersecting faces are supported (Z-buffering allows intersecting faces, but most other sorting methods do not), but the answer can affect other areas as well. |
Artist: Are there any special shapes that should not be built? Producer: No line-face, point-face, or 1,000:1 skinny faces. |
Tech: This question reflects the fact that some graphics engines don't cope with strange faces, such as a "line-face," which only uses two vertices, or a "point-face," which only uses one vertex. Also, some engines don't handle long, thin faces well (such as a triangle that fits in a 1,000¥1 rectangle). Asking this question should reveal all those special cases, if there are any. |
Artist: What's the screen size for this application? Producer: 640x480 |
Tech: This very important question tells us what resolution the textures should be, and can also be used to determine the size of detail the on-screen objects will need. For example, if the answer was 320¥200, then a smaller fur texture might be O.K., and perhaps the gaps between the teeth wouldn't be worth modeling, since they would always be far less than one pixel wide. |
Artist: How will the models be seen? What viewpoints does the player use during the course of the game? Producer: The camera will orbit the cat, barely within the room. The cat will rarely take more than 25% of the screen width, and usually only 10% or so. We won't see the cat's underside very often - the view will be mainly from a six-foot-tall person's standpoint, much as you'd see a real cat in a living room. |
Tech: With enough information, the optimal size for an object is a known quantity. In this example, multiply the screen width (640) by the cat's length on screen (25%) to conclude that the cat's optimal size is about 160 pixels long. This number is useful when choosing texture sizes (128¥128 for the foot is way too detailed) and geometry detail. |
Artist: What kind of animation will this model be able to use? Producer: 3D morphing with support for bones.
Tech: The most common types of real-time animation include hierarchy, animated bitmaps, 3D morphing, or "none at all." This question will probably elicit a lot of detailed discussion on how to build the animation. Once the animation type has been settled, it's a good idea to build a simple test case and make sur.e it works. |
|---|
Artist: How do I get animation data into the engine? Producer: 3DS morph animation data is directly supported, so simply save the morphing animation sequence with the file name of the action - STALK.3DS, POUNCE.3DS, and so on. |
Tech: This critical question tells the artist exactly how to import animation data - it's usually much harder than importing the geometry and textures. For example, sometimes the artist must supply a string of 3D models as keyframes (STALK01.3DS, STALK02.3DS, and STALK03.3DS), or keyframes can be imported directly out of the 3D Studio animation data, as our answer indicates. The answer is usually followed a torrent of questions about how to handle animation data. For instance, what kinds of bone motions are possible - keyframes or every frame? Branching? Transitions? This issue requires a separate article to explain, but it's very important. |
Artist: Will any moving objects always be moving? Producer: Yes. |
Artist: How many colors is the target platform capable of showing? Producer: We're using 16-bit color. |
|---|
Tech: The usual answers are 8-bit (paletted), 16-bit (high-color) or 24-bit (true-color). This issue may be somewhat more confusing if the game is going to be used on multiple platforms. |
Artist: Are there any palette issues of which I should be aware? Producer: Nope.
Tech: This question always applies when the game uses 8-bit color. Again, this issue is too complex to explain fully here, but it's a very key point and there aren't many standard ways of handling palettes. The artist needs to know as much as possible about how the game's palettes work - specifically, how many (if any) of the colors can the artist dictate values for, how the fade tables work (if they exist), what happens when the lighting changes the colors, how to swap palettes, and so on. Also, the concept of palettes could be applied to higher color depths; even if we're in 16- or 24-bit, we may have to deal with palettes. |
|---|
Artist: Are there any "special" colors? Transparent colors, for instance? Producer: Nope. |
Tech: This question refers to colors that are handled by some special method. For example, some graphics engines consider any pixel that is pure black (RGB = 0,0,0) to be transparent, if the material has any file name under the "opacity map" setting. Palette-based systems often use certain palette entries for flashing colors, color-cycling, and numerous other effects. |
Artist: What kind of lighting will be used in the game? Producer: Static point-sources. Actually, "static point-source lights with ambient" is more accurate. Lights must be defined in the LIGHTS.DAT file using the format lightname, XYZ, Radius, RGB, falloff. Multipass lighting is also supported. |
Tech: As you can see, the, information relevant to this question includes the lighting type (point-source, directional, ambient), how to set these lights, and whether the lights can change during run time (dynamic) or not (static). |
Artist: How should dynamic lights be animated? Producer: Dynamic lights aren't supported. |
Tech: If dynamic lights are supported, the artist will need to know how to define their animation. Hopefully, the artist can simply animate in the modeling software and export that data - but it doesn't always work that way. |
Artist: How should I create multipass lights? Producer: Create separate geometry that is coincident with, but simpler than, existing geometry. Map it with the lightmaps and name it MP-OBJNAME. At run time, this model's rendering will be multiplied with the basic model.
Tech: There are many ways to handle multipass lighting input, and no real standards except QUAKE, which only really works for QUAKE or QUAKE clones. The programmer's answer is a simple example; real projects are usually different. |
|---|
Artist: What kind (if any) of texture mapping is supported? Producer: Perspective-corrected, no run-time filtering. |
Tech: It's a rare game that doesn't support texturing. There are several kinds of texture mapping possible, each with different tradeoffs between rendering speed and distortion. |
Artist: How much texture-map memory is budgeted? Producer: You have 2MB of texture memory. |
Tech: Obviously, the texture-memory limit affects how large and how many textures we can use. This is a pretty typical limit for 1997 graphics accelerator cards - usually, developers are limited to the texture memory on the card, which is often 2-4MB. |
Artist: What size and shape can the texture maps' dimensions be? Producer: They've got to be 16x16, 32x32, 64x64, 128x128, 256x256, or 512x512. |
Artist: What kind of shading is supported? Producer: Smooth shading. |
|---|
Tech: Almost every graphics engine is capable of flat shading from a fixed directional light source. Most can also handle Gouraud shading (a.k.a. smooth shading) and some can handle specular highlights (shiny spots). A few do Phong shading as well. |
Artist: What are the allowable combinations of shading, lighting, and texturing? Producer: All can be combined. |
Tech: This important question is often forgotten amid the confusion of technical answers, but it's important to ask. For example, some graphics engines won't smooth-shade a textured face, and ambient lighting may behave differently for flat-shaded (as compared to smooth-shaded) objects. |
Artist: How are Gouraud shading borders determined? Producer: Any faces that share edges are smooth-shaded together. |
Tech: Most smooth-shading graphics engines assume that any faces with shared vertices should be smooth-shaded together. |
The Psychology of Artists and Programmers
I've found that the programmer/ artist connection is difficult for many artists. I've often heard artists complaining about trying to work with programmers, saying such things as, "They have no idea that they just ruined the whole look of the game with that limit!"
I think there is often a disconnect at two levels: One is an important difference in goals for artists and programmers, and another is the garden-variety difficulty in communicating with which all team members must cope. Let's explore the first disconnect in detail. Artists generally encounter two common problems when working with programmers (here come the stereotypes!).
Feature Creep
"Feature creep" is when a product continually gains new features that weren't in the original design. This happens a lot with games, and it's often driven by programmers' improvements.
Why? Game programmers are very competitive with each other, and the score is often measured in features, not in depth of game experience. For example, I know high-profile coders that don't respect MYST because it isn't technically innovative. Lots of artists that I know think MYST is a successful game that has a powerful impact on its users. This extreme focus on the technical abilities of the game leads to ever-greater features, sometimes even at the expense of the overall game experience. By comparison, artists are more focused on the overall effect of the game: Commercial artists have been trained to impress their audience, not their peers.
"Field of View"
Programmers can lose the forest for the trees very easily. It's an occupational hazard - they have a death grip on microcosmic detail, and getting that detail to function is one of their primary tasks. This extremely heads-down approach means that it's hard to keep the overall importance of their current task in mind. For example, a programmer accidentally makes a renderer that generates cool lighting streaks when the player rolls. In the code, this looks like a mistake, and so the programmer fixes it… and kills a potentially valuable addition to the game.
Deciding what features to develop is really a technical design issue, not a coding implementation problem. Nonetheless, an industry tradition has arisen around this issue. In the early days, programmers designed and built the whole game and subcontracted out other parts (including the art) at the end - not an ideal arrangement for the artist. Today, programmers are part of a development team, but they often decide the game's features and capabilities, sometimes without the benefit of an artist's (or level designer's, or sound producer's, or a host of other developers') input.
Thinking Visually
Programmers don't think in the same visual terms as artists. As an artist, this point is driven home when I watch a programmer work. Standing over a programmer's shoulder, watching endless streams of text scroll past, I can see that the visually plain text formatting is not a significant barrier in their understanding. Of course, artists understand complexity - I've seen programmers shake their head as they watch an artist thoughtfully rotate a nightmare tangle of wireframe lines and points, then suddenly pounce on some apparently-problematic intersection. Both types are skilled at very complex, subtle problem-solving - the difference I'm emphasizing is the appearance. Artists understand visual problems, even if they're quite symbolic in nature, and programmers think in procedural flows that aren't necessarily visual at all.
How are Game Programmers Similar to Artists?
Programmers and artists are in a similar role: They're both major players on the frontline of development, caught between the realities of time, features, and managers' expectations. They produce the actual product, and that makes them peers in the end. They have similar issues with milestones and deliverables, and also have similar knowledge and attitudes about the rest of the game production cycle (marketing, distribution, customer satisfaction, and so on).
Both coders and artists are perfectionists, with their names in the credits. They usually believe in their own abilities, have a strong desire to produce a top-notch game, and are willing to work hard to do it and fight for what they think is important. For example, in real-time games, frame rate is a very important issue to both artists and programmers. They'll both howl when their game runs at a miserable ten frames per second, and they'll both have good insights and often volunteer to improve the situation. This commitment is a common bonding point for artists and coders - they develop respect for each other's dedication (without the danger of feeling competitive), sometimes expressed as a shared scorn for "slacker" nine-to-five workers.
Like many specialists, artists and programmers can fail to understand what specialized knowledge they have. For example, professional artists have unusual training and talent that lets them see and express visual beauty. "Unusual" means most people don't have this ability. Still, most artists that I know take this skill for granted, and find it frustrating when other people (say, programmers) ignore visual beauty. This lack of understanding is the root of many communication problems, and yet both programmers and artists share it.
Suggestions To Artists
I'm sure you think that's all very interesting, but what can artists do to improve the situation?
Get coders to understand your issues. For example, if you need more texture memory, don't just beg for more. Show them dramatic (but not faked) "before" and "after" textures so they can see the benefit of an improved texture and weigh it against the cost of the memory usage. If you can show a dramatic improvement, they'll be trying to figure tricky ways to get that cool art into the game. Be aware of the level of understanding that programmers have for varying parts of your work; don't explain concepts they already understand.
Be assertive about artistic judgment issues - remember, you're the expert at that. If a proposed feature doesn't add much to the environment, say so and recommend that it not be implemented (expressing this dissenting opinion without causing strife is tricky indeed!). In a similar vein, be respectful of your colleagues' fields of expertise, unless you have very solid reasons to doubt them.
Keep programmers in your loop. Consult with them, in their terms, especially about issues that affect performance. For example, if you're trying to create an army of 100 action figures, but your face count is too low, show a programmer a sketch of the scene you want and run through a frame-rate calculation with them ("O.K., so 100 figures means 8,000 faces. The performance of 1,000 faces per frame means…."). This provides a reality check (and a solid justification if anyone questions your decision), and it also gives the programmer a chance to suggest an innovative solution.
Stay in your programmers' loop. Excellent artists know the limits of their medium no matter what the art form. Also, tech-savvy artists can see improvements that others can't. Becoming technically savvy isn't difficult if you can find a friendly, communicative programmer.
Don't waste excessive hours addressing unimportant or unrelated issues. If you have a hard time distinguishing, don't suppress your queries, but do confine them to lunch-time or off-hour conversations.
Features Versus Beauty
Here's my theory: In general, programmers must balance features, performance, and time - they want the most capability, at the best frame rate, within their deadlines. On the other hand, RT3D artists are trying to balance artistic quality, performance, and time - they're trying to get the best looking art at the target frame rate, within their deadlines. This difference is the root of many programmer/artist woes.
In the worst case, coders push for features without caring if the game is any better, while the artists ignore these new features as they build detailed artwork in their own way. They don't talk much during development, then try to integrate their work at the end, which climaxes in a grand fight when the game sucks.
Of course, it's not normally so bleak. Programmers implement features that allow the game to show better looking art without compromising frame rate, and artists take advantage of these features to produoable.
Josh White ([email protected]) has been building real-time 3D models for games since 1990. He runs Vector Graphics (a company devoted to creating RT3D art), cofounded the CGA (a community of computer game artists - www.vectorg.com/cga), wrote Designing 3D Graphics, the first book on real-time 3D modeling, gives lectures, and writes about computer artists… but he admits that all this really kills time between soccer games.
Read more about:
FeaturesYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
