Artists and Game Design Documents: From Interpretation to Implementation

By Joshua Gordon

Without question the biggest problem I find during the design and implementation of games is the lack of interactivity amongst the various team members of a project. We've all heard the comments (laments, shouts, etc.) "You wanted it to look like what?!?!?!", "This is the dumbest character I've ever seen!", "I said round! Not spherical!"--and so it goes. As someone once said "Without communication, chaos rules."

This article will focus on the relationship and communication between artists and designers during the development process. Topics will include: "Blue sky" meetings, the design document, methods for streamlining the production process and a few other random thoughts. Now a couple of those random, but important, thoughts.

Designers: Many (myself included) are Autistic, Not Artistic

While some individuals (show yourselves demons) are gifted with a plethora of skills- creative thinking, the ability to speak well, write well and create great art-others are not so lucky. Many designers find themselves in the position of being thoughtful, creative and having reasonable (hopefully) communication skills but a total inability to draw, model or otherwise communicate their ideas visually. Worse, many are not well versed in the diction of art (you know, "those dark highlights!" -or umm, shadows). Therefore, it's important to remember the "artistically challenged designer" needs your help. Designers can envision what we believe will be cool looking and we know the types of game play we are after, but without significant participation from the art team it is almost impossible to realize (much less enhance) the look and feel of the game.

Designs: Looking At The Big Picture.

One final point before we dive into specifics. Design documents speak to a large audience: Programmers, artist, level designers, producers, marketing and business folks, etc- the whole enchilada. This can often make the document large, fragmented and a "hard read". While nobody loves reading several hundred pages of semi-literate writing, understand that the document contains information that is crucial to an artist's ability to do his job. While you may want to skip over the treatise on AI (artificial intelligence), or the hyped up market speak this is almost always a mistake. Read the document, the whole document, you'll be surprised (hopefully pleasantly) to find information pertinent to the artistic content hiding in some of the strangest places--read the document, get the big picture.

Blue Sky Meetings

For the purpose of this discussion, let' s define "blue sky" meetings as the pre-design meetings, discussions and other "social events" that take place during the formative stages of fame. Opinions of "blue skying" range from critical to crap; I believe the value lies (or dies) in the ability of each member of the team to speak his mind. Unfortunately, I also believe that all too often those who are less outspoken do not get heard, but rather are herded. Artist as a group generally fall into the latter category (the herded). I've participated in endless blue-sky meetings where you can identify each and every member of the art team as they're diligently doodling throughout the discussions. While I'm sure they're really, really good doodles they don't really help the process.

Speak Now or Forever Feel Victimized

So, what does this have to do with the design document? Personally, I rely heavily on these meetings to help formulate the game design and, as importantly, to understand what the team is interested in making. -a great game design is worthless if the team doesn't want to make the specified game. Artists are as responsible for the creative game play content as any other member of the team. If you don't communicate during meetings your thoughts, ideas, characters and environments will not appear in the design. Conversely, if you do speak out you'll likely find many of your thoughts will be present in the document (even though the designer will take credit for 'em). I cannot stress the importance of this point. I like to think of designers as prospectors looking for ideas, some we'll dream up on our own, but a vast number of ideas, characters, situations and settings come from others. It is our job to absorb the input of the entire team and to coordinate and refine the creative vision. So, involve yourself in discussions.

Communicate Via Imagery

Here's a tip for the folks who don't feel all that comfortable trying to be heard through the debates, screams and other vocal exercises "blue sky" meetings often become-communicate your ideas through sketches and reference material. Some of the best ideas I've seen come from artists who appear at a meeting and drop a chunk of drawings on the table with a "how about these ideas" look. Remember the old (and overused) adage- "a picture is worth a thousand words"-give it a try. If you're bored, sketch a character, a scene, an object (anything related to the game as opposed to your personal doodle-glyphics). One final note, the drawings don't need to be high quality, quite the opposite, as long as they communicate your intentions you're "good to go". I'll be speaking more about concept imagery later.

Get Ahead, Think Ahead

A great way to avoid being run over during discussions is to come prepared. Think about the topics for the meeting before you arrive. That way when you're in the middle of your idea and the pizza shows up, you'll have a note or picture to remind you of the point you wanted to make. It also give you the chance to gather your thoughts without some idiot saying "yea, so what! Get on with it!" If you're unsure about exactly which topics will be discussed, ask your team leader before the meeting. Following is a brief list of design items screaming for artistic input:

The Design Document

OK. The meetings are over, time has passed and the designer appears with his magnum opus to the gaming world. What is this thing? What did the designer intend? How much latitude do you have artistically? These are hard questions to answer, game designs and designers come in all flavors, shapes and sizes. I've never seen two alike. However, most design documents should and will speak to a set of game elements critical to the art team. Following is a discussion of these elements and hopefully answers to the questions above:

Read the Whole Thing

I said it above and I'll say it again-read the whole document. This discussion will focus on sections of the design that related specifically to artists but remember you will find pertinent and interesting items throughout the document. For, example, much of the business/marketing writing may seem like a waste of time, it's not. Held within are the desires, requirements and most importantly the expectations of people who you may not see but will definitely impact your work. Understanding how the folks outside your team are thinking is crucial. Another good example are the game play dynamics/mechanics-the basic rule system for the game. Understanding the core game play will help you avoid designing characters, objects or scenes, which won't work when placed in the game. While a ceiling dangling, fire-ball shooting slug boss may be a cool idea it won't be all that cool if the player character can't jump high enough to reach it and doesn't have a projectile weapon--meaning the player can't fight your cool boss (generally not a fun thing). Al is another area often overlooked. In my documents I include a small paragraph that outlines character/object- If the character kicks it better have legs. If it shoots rockets, it needs a rocket launcher. I think you get the point. Other Al items can be subtle. If the characters stop and look around when they hear the player, you need to make sure they have heads that swivel, bodies that rotate, etc.

Game Look and Feel

A section on the game's look and feel is intended to communicate and reinforce the overall graphical style of everything from the characters to the environments. Unlike many other areas of the game design, the game's look and feel is almost always decided up front-otherwise you end up the "Gamorama Eclectia"-a hodge-podge of imagery without a cohesive theme, look or style (generally not a good thing). Input should be given during the 'blue sky' meetings and/or art specific meetings during pre-production. It is during this formative period that you can affect the look of the game-and it's a look you will live with for the duration of the project. So keep you eyes and ears open during this process and when reviewing drafts of the design document. It is also helpful to clarify the look and feel during the design creation process. If the wording is ambiguous or unclear, don't hesitate to ask for clarification. Varying from the game's overall look and feel is ill advised. Following is a sample description of the look and feel of a mock game titled Mega-Game:


  1. Look
    Mega-Game will use an edgy, hyper-realistic style to portray a dark, alien, devastated look with some lighter environments used for balance and contrast. Each game environment will vary significantly from the others containing different music, sound F/X, color schemes, backgrounds, and NPCs. The look will generally become darker, stranger and less "normal" as game play progresses. At the game start the look will resemble that of Star Wars, toward the end it will have a more post-apocalyptic Terminator 2 look.

  2. Feel
    The feel will be that of a lone person or group on an almost hopeless campaign to stop a universe threatening evil. The player should feel an overall sense of an ongoing and increasing destructive force, veiled in mystery and intrigue throughout the game. As the player progresses, the story and the player's ultimate objective will become more clear while the feel becomes more and more twisted and evil. An increased sense of a maniacal and ruthless presence, which must be overcome, gets stronger and stronger.

    There will be a strong emphasis on ambience in Mega-Game. The backgrounds will be "alive" with activity; utilizing background animation, palette shifts, etc. The music and sound F/X will be used primarily to enhance this "live" and realistic feel.

  3. NPCs
    All NPCs (non-player characters) will be rendered in 3D. They will look and behave as "realistically" as possible. In general, this means that a large strong looking NPC would cause greater damage and have greater resilience than a smaller NPC. (Note: Obviously, some smaller NPCs will be capable of inflicting heavy damage, much as a rattlesnake can severely damage a human).

    NPCs will look and feel dangerous, aggressive and deadly (the bad guys). This is important, as the player will only be allowed to fight with "bad" dangerous entities. Mega-Game will NOT allow the player the opportunity to attack any entity which is non-aggressive.

  4. Backgrounds
    All backgrounds will be rendered in 3D. As discussed above, each level will look unique and, in general, the levels will become increasingly dark and twisted as the game progresses. Ideally, the player should be able to identify any level within the game purely by its background.

Level/Environment Description

In general each level of the game will be described within the game document. There should be somewhat more latitude here than in the overall look and feel. That is, as long as the overall game look and feel is followed, the specific look of any level can vary somewhat. It is critical to understand the plot line as it relates to the current level. In the overall description above, it specifies that the game will become progressively darker and stranger. If the current level is at the beginning you'll have less latitude to "go-crazy", while if at the end of the game it is almost a requirement. During production you'll want to work closely with the level designer who will be laying out the level. A few important items to note when designing the look and feel of a level:

Following is a sample level description:

  1. The Final Chamber

    A huge spacious cavern with organic walls similar to those in "aliens". The Final Chamber is suspended from the ceiling of the cavern. Several "bridges" lead to the chamber from the edges of the cavern. Thousands of characters are moving en-masse across the bridges and into the chamber where they are destroyed. The chamber pulses rhythmically creating a deep horrific sound, which emanates throughout the cavern. All visible light pulses to the beating sound.

    Due to the damage inflicted by the crashing ship (previous level) and the damage done by the player reaching the Chamber, the entire cavern is being rocked by sporadic quakes and explosions, falling debris rains downward and the bridges leading to the chamber shake, pieces snap off dropping to the cavern floor far below.

    The Chamber itself is a roundish structure with the sinewy biomechanical supports leading to the ceiling and floor of the cavern. Within the chamber are a handful of elite enemy characters who orchestrate the death march of the other characters as they enter the chamber and are absorbed by the machinery at the chamber's core. Additionally, there are large automatic defense systems used to guard this humongous machine and its ruler

    1. Look/Feel:
      • The inner sanctum-A holy worship of evil (think: Hellraiser).
      • A dark place, full of death and suffering.
      • Visually stunning, glowing, shaking, lots of movement.
      • Note: The last level of the game.
    2. Path: Diagonal down, Horizontal .
    3. Gameplay/Dynamics List:
      • Intense action/platform.
      • Heavy fighting.
      • Slide dynamics.
      • Timed escape.
    4. Story Elements:
      1. Make way to the Final Chamber.
      2. Fight to "inner sanctum".
      3. Defeat Boss.
      4. Escape the level before the cavern collapses killing the player

Note the inclusion of look/feel, the basic pathway, game play dynamics and story element bullet points. These are all intended to help the artist and level designer focus on items crucial to the game play and/or look and feel.


Some of the largest parts of design document (at least in my case) are the character design sections for the main player character(s) and the numerous NPCs (non-player characters-enemies, monsters, etc.) Hopefully the designer will have created a template used to define each character. This helps the readers by providing a consistent format, which allows the focus to rest on each character's specific traits. Character design is an area ripe for artist creativity and input. As long as the artist understands the purpose of the character and its actions he can generally embellish and refine to his heart's content (limited by those two pesky restrictions: time and money). I break down my character designs into the following sections: description, reference, health and damage information, Al notes and animation list. Each is listed below with a brief description of its intended purpose. Combined the information provides a set of guidelines while still leaving lots of room for interpretation.

Following is a (short) sample character description:


  1. Robossassin.
    1. Description: A strong, thin, almost wiry character whose metallic structure closely emulates that of the human body (metal plates for pectorals, thick cable for thigh muscles, etc.). Moves extremely smoothly-like ninja assassin. Carries a powerful energy gun (one handed it acts as a machine gun, and also be used two handed as a sniper rifle) and long serrated knife.
    2. Reference: "Joe Pineapples" of the ABC Warriors.
    3. Health: 75 health points (medium strength).
    4. Damage: (Note player has 150 health points.)
      • Machine gun attacks = 3 damage points per bullet (bursts of 10 bullets per firing).
      • Sniper Rifle attacks = 40 damage points each.
      • Knife attacks = 30 damage points each.
    5. Basic AI Behavior:
      • Standard patrol behaviors (path following, stationary guard).
      • On activation:
        1. If player FAR enters SNIPER_ATTACK
        2. If player MEDIUM enters MACHINE_GUN_ATTACK.
        3. If player CLOSE enters KNIFE_ATTACK.
        4. If player NOT_VISIBLE enters FIND_PLAYER.
        1. Aim- delay period.
        2. Fire.
        3. Advance toward player.
        1. Scream- delay period.
        2. Advance while firing. Alternate strafing per attack. Lt. to Rt., then Rt. to Lt.
        3. Check weapon.
        1. Alternate between straight thrust and backhand slash.
        2. Scream-delay period.
        3. If player CLOSE enter KNIFE_ATTACK.
    6. Animation List:
      • Stationary guarding pose w/ occasional head turns, weapon checks and other appropriate idle behavior.
      • Patrol walk w/ occasional head turns.
      • Stalk walk (when pursuing player).
      • Turn from patrol or stalk walk.
      • Gun to/from sniper rifle aiming/firing position.
      • Machine gun strafe while "stalk walking".
      • Take/replace knife from sheath.
      • Knife thrust.
      • Knife slash.
      • Recoil on damage.
      • Death-fall to ground
      • Death-explode.


      Now we've reached the point where the "rubber meets the road"-implementing the design. In theory you should be able to take the design document, spend a few moments pretending to understand the programmers and other team members and begin drawing, painting, modeling, texturing, and animating your heart out-right? If only life was this simple. Unfortunately, like life, things are going to get pretty complicated (and we're not even going to discuss all those lovely technical issues like polygon counts, texture mapping, texture sizes, memory constraints, color palette restrictions, file conversions, etc.)

      Following are several points to help you work with the designer(s) and insure (as best you can) that the work you perform will not only adhere to the overall vision of the game but allow you to the freedom to enhance that vision:

      The Three Most Important Points: Communicate, Communicate & communicate More.

      All too often artists and designers (along with everyone else) tend to become immersed in their work and those lovely ever-looming deadlines. While this focus is understandable it tends to create large gaps between review and design meetings. I'm not suggesting you have large meetings every day (or ever for that matter)-but rather that you find a few minutes to spend with the designer(s) as your work progresses, show him/her what you're working on and discuss how it will affect the game play. Whether you're building/drawing characters or objects, animating them, working on backdrops, textures or level art you'd be surprised at the amount of work that has to be reworked or redone due to simple misunderstandings and miscommunications (the designer told the team leader who told the art director who told you ----hmmm I wonder why it didn't turn out the way expected.)

      This Is the Last Revision...I Promise!

      Game designs are works in progress. They will change faster than you can sharpen your pencil. Eventually someone will get around to telling you that your level has been redesigned or that the character you've been working on has been changed. But, all too often, the lag between the design change and the communication of said change is far too large. Stay up to date, do not assume that you'll be told when things change. Remember, even if it's not your job to coordinate changes, you'll end up doing the work.

      Concept Drawings: Blazing Pencils

      One of the best artist/designer tools is the concept sketch or storyboard. Initially variety and options are the key. All too often I've left a meeting expecting to get some "concept sketches" for review, after several days an artist reappears carrying a fully inked and colored rendering ready for the cover of a comic book. Take note, designers would rather have 20 rough sketches showing a multitude of look and styles than one carefully crafted masterpiece. Once there is an agreement on the basic look of the character Then spend time fleshing it out.

      Reference Material Is Worth A Thousand Lines of Ink

      If a picture is worth a thousand words, then reference material is worth a million. As noted above, in the design document topics, designer should include references for their characters, levels and other graphic items. The same goes for artists, instead of drawing 20 concept sketches, show the designer an existing image, be it a comic book (my personal favorite), magazine image (and you thought those travel magazines were garbage), photograph (I have discovered a plethora of truly gruesome characters at out last family reunion), another game (good artist borrow, great ones steal) a video tape (Hooray for Hollywood), your dad's latest wood carving (hmmm), whatever. There is almost always some Existing material that can be used to communicate a look, character, scene or movement.

      Make One, Let's Review It, Then Make More

      Make sure you are on the same page as the designer(s). Don't go off and spend a hundred or more hours cranking out artwork. Finish one task and then review it with the designer. This is especially important at the beginning of a project when everyone's unsure of exactly what things should look and play like. As the game progresses both the artist and designers should begin to get comfortable with one another's styles.

      Final Thought

      Hopefully the above suggestions will help you sort through the sometimes strange, and often idiosyncratic work of various designers, as well as, streamline your production process as it relates to the design document. On a final note, remember each design document and designer/design team is unique- you'll need to learn how the designers work and how their documents are structured. Talk to them.

      Joshua D. Gordon can be reached at [email protected]


Return to the full version of this article
Copyright © UBM Tech, All rights reserved