This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
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.
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.||
Psych: This answer is quite brief, possibly because the designer hasn't thought out the scene in much detail. Also, this designer doesn't want to commit to a list, in case something else comes up later. However, the artist should continue to find out as many specifics as possible: What kind of animations are needed? What's in the room? These details will definitely affect the scheduling. Also, this is a good time for the artist to vaguely describe the planned style (quick examples) to make certain that the designer likes it. This kind of early communication can prevent disagreements about style.
|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.||Psych: This is another question that can make the artist feel trapped, because it's where the rubber meets the road. Often, programmers don't know the polygon budget or make up untested numbers. This uncertainty could be the sign of a basic design problem (which means it could be a sensitive issue). Experienced artists will gently explore the "why" of this budget and see if it matches their intuition.|
|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?
|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?
|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?
|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.||Psych: This is probably the hardest question to which to get a straight answer. Of course, RT3D means the viewpoint usually isn't defined, and the designer can't know the viewing positions. The good news is that artists only need to know very general information: what parts will be scrutinized, and which are rarely seen. Ideally, they will know more: how and where the object will be in the scene, what the minimum, maximum, and typical viewing distance will be, and what the field of view is.|
|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.||Psych: In our example, we're getting a pretty sophisticated real-time animation system. That probably explains the low face budget - fancy animation methods usually hurt performance. It might be a good idea to verify this theory with the programmer.|
|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?
|Tech: For objects that have moving parts, such as spinning wheels on a car or propellers on an airplane, we need to know if the spinning object will ever be seen still, which would require a second model (blurred and still).|