Communication with Others. By "others", I mean non-artists. This section is addressing the importance of proper engagement with peers in other departments, such as programming or design.

Simply put, artists should use different approaches to collecting information from (and presenting it to) the various groups involved in game development.

In my experience, it's pretty easy for each group to become frustrated with the others. Almost all of these situations derive from problems in communication.

The fault, in most cases, lay not with any one group. In the majority of cases, both parties failed to provide or collect the information they really needed. More directly, they failed to "cater their message to the intended audience."

This should come as no surprise to anyone, but programmers often prefer that information be detailed and precise. By comparison, artistic analysis is much more fluid and subjective. As such, it usually requires more time and more thought to be put into communication between these two groups.

Numerous times, I've heard the comment from programmers that "artists don't know what they want." As an example, this scenario could derive from repeated or failed tool creation or feature modifications.

Understandably, both groups are frustrated by this situation. Programmers are frustrated because, from their standpoint, they've already spent time building something that isn't usable or desirable. Artists are frustrated because, from their standpoint, they've requested something that programmers haven't delivered.

So, what happened? When requesting tools or features, the conversation usually centers more on what the artist wants, rather than the goal that the tool/feature is expected to achieve. The end result may be what was requested in some sense, but not what was truly desired.

Occasionally, requests are too vague, or easily open to misinterpretation by non-artists. It is far more effective to clarify your goals. I regularly encourage artists to provide reference, or some form of visual indicator that explicitly communicates what you want to achieve. This is how you clarify the object of your request.

The next important component of tool or feature requests is how the request is presented. The common mistake is an artist asks, "Can we have feature x?" You've effectively asked someone a yes/no question as to whether or not they want to do more work.

What kind of answer do you expect in response to this situation? A much more effective question is to ask, "What would it cost to get feature x implemented?" For one, it addresses another frequently-heard comment from programmers that "artists just want everything."

This type of question opens a dialog on what a feature costs. Maybe what you're asking for will require sacrifices, but you won't find that out if you don't ask the right way. Your most recent request might just be worth the sacrifice.

If nothing else, the programmer will still have gained a greater understanding of your priorities, which may help with future decisions. Programmers are willing to work with artists to support their goals -- if they're willing to discuss options and alternatives.

In comparison, the inverse is more common when it comes to communicating with designers. When designers make requests of artists, it is most commonly in support of gameplay changes. In my experience, artists frequently complain that designers are too vague or don't know what they want. Sound familiar?

However, precise design is difficult to achieve early in development; good design often requires iteration and experimentation. As such, changes are to be expected, and artists need to be aware that they are part of this iteration process.

A good example of vague level design direction might be "please make the room bigger" or "can you add more furniture?" Some artists will just take the vague direction and make changes.

They may complain that the direction is vague, but take no steps to clarify the information. The end result is that the artist and designer will likely have to revisit this request multiple times. As with programming, the problem is that the features have been explained -- but not the goals.

My recommendation is to -- carefully, and respectfully -- ask why requests are made. Maybe the designer wants a bigger room so that they can add more enemies. Maybe they want more furniture to create additional places where the player can take cover. Once the goal is known, the discussion can focus on options and alternatives, some of which will save both time and effort and may avoid eliminating artwork that has already been completed.