|
The Artist Synapse Back to Intro |
|
Example Artist Interaction: Page 1 Page 2 Page 3 Page 4 Page 5 Page 6 Page 7 |
| Degrees of Separation [View] |
| Psychology [View] |
| Suggestions [View] |
|
Features vs. Beauty [View] |
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.
