Common Methodologies for Lead Artists

Author: by Dianna Davies

Back in the early 90s the industry could get away with not having clearly defined roles because game development was a giddy new discovery and we loved the "seat-of-our-pants" style of production. Nowadays it is serious business with a competitive edge. Larger teams need more structure. If hiring managers are going to effectively be able to do their jobs, we may need to adopt common definitions and methodologies.

Defining Art Roles

If you ask a variety of artists and producers in our industry what they think the term "lead artist" means, you will receive a variety of answers. For some, it means "head honcho"; for others it means "technical artist". I have heard of instances where the lead artist was more of an art director. How do we begin to define the role of lead artist? This article describes the various responsibilities of the lead based on the combination of definitions I have seen that work best.

My experience has taught me that the most successful formula for establishing roles is a combination of one part tradition and one part progression. Tradition can describe the common ideas people share when it comes to what constitutes leadership. Progression involves transforming our notions of leadership and make them fit to the demands of game development on a continual basis.

The art director is the creative visionary, responsible for defining the visual direction of the project. What colors will define the mood of the environment? What level of detail should the textures convey? What are the buildings in a city supposed to look like? How does the terrain look on this level? What kind of ambient characters populate this world? How red should the blood be? The art director works closely with the game designer to shape the game world. The art director carries the burden of communicating his or her vision of the game design to a diverse team of artists.

The lead artist helps the team technically and artistically, to carry out the art director's vision. The lead understands how to conserve where necessary and how to give more freedom to the areas that are important in achieving the goals of the game designer and the art director. The lead artist handles the technical aspects of the art team: art processes; tools; geometric budgets; texture budgets; task definitions; scheduling of tasks. The lead also communicates with the lead programmer and the producer to identify risk in the production pipeline. The lead takes the burden of artist management and protects the art team from counter-productivity.

The best teams I've worked with had an art director and lead artist who worked closely together and respected each other's roles. They communicated openly. They agreed upon the visual direction of the product and discussed their respective responsibilities that were required to carry out the execution of the design. Not surprisingly, they were relatively stress-free teams. With the definitions out of the way, we can look at the methodologies and stages of production the lead may encounter.

The Art Specifications Document

Ideally, the lead and art director would ideally have time to examine the game design document well in advance of the assembling of the art team. Having reviewed the first draft, the art director and lead work together to define the art portion of the design doc, called the Art Specifications Document. In this document, the lead identifies the requirements for producing the art assets and the risks associated with any unknown areas. This could include the introduction of a new tool, lack of programmer support until late in the development cycle, testing processes and approval systems. The game design doc is a living entity, and should be used as a method of tracking original plans and staying focused. It is very important that the art director strive to outline the artistic direction of the product in as much detail as is possible. The art director needs to have an open line of communication with the decision makers and should obtain written approval of the project's art specifications.

An Example

Failure to come to agreement on art assets, such as character design, can cost hundreds of hours of production time.

In this example, the Art Specifications were outlined very thoroughly in many areas, even containing blueprints of world object creation. However, the character portion was left vague and undefined. Figure 1 is an example of the spec document illustrating that section:

More thought is given to the technical approach of building world objects, which can be far less complex to integrate, than is given to character design. As a result, the characters created were too stylized to fit the client's ideal and had to be revised after the second milestone. It may seem amazing that it could get that far without being caught, but it happens all the time. What could the above example show that would satisfy the description necessary for the enemy characters? How about this:

The Art Specifications should include estimates for texture footprint budgets, polygonal budgets, animation requirements including a first pass animation list and, later, a flowchart describing the motion flow of the animation. They should also cover character design, descriptions of construction methods for models, naming conventions, tool requests, roles and responsibilities of each member of the art team, visual examples and possibly storyboards supplied by the art director.

Task Breakdown and Assignment

The lead should have an idea of how many artists will be assigned to the project. Once the lead and the art director have examined the GDD and formed the Art Specs document, the lead can begin to break down the tasks according to the number of artists and the number of assets required. Factor into this of course, the timeline of the project. Typically, the lead will assess the roles he or she has in mind for each artist and assign the tasks accordingly. Figure three is an example of a schedule drawn up by the lead to assign milestone tasks on a per artist basis.

Identifying the Art Process Pipeline

The tricky part of the art process pipeline is developing a pipeline where none exists. In an ideal situation, the art lead and art director get the opportunity to work with the lead programmer in testing the art pipeline before the team is assembled. Unfortunately, the luxury of time required to accomplish this is rarely afforded to the leads. Instead there is a degree of scrambling to work out the bugs of the asset generation methodology. Hopefully, schedules are defined with such requirements in mind.

The art process pipeline includes the definition of the building of assets in software; the way files are saved to directories; the method of exporting to the game asset folder; the testing of the assets in the game environment and the method of reviewing assets.

Figure 3. Example of task list breakdown by milestone.

The first important part of establishing the art pipeline is to ensure that the building environment is the same for all artists. The lead should take the initiative to examine each artist's computer to make sure that date and time are synchronized (this may seem over the top, but sometimes it is important for tracking purposes to work from the same protocol). Then, the lead should check the preferences of the software to ensure world scale units match, export paths are correct, and plug-ins needed are present and are the correct version.

It is easier to work within a methodology that adopts standardized protocols in every area. For example: if you are creating directory structures that have many layers to them, try to keep a common pattern for each level if possible. If your level folders contain the sub-directories: reference, textures, models, animation and exported, then each level folder should be structured the same way. Maintaining a complex structure is easier to do when all of the artists and programmers on the team agree on the structure and communicate if someone is not following the agreed protocol. Sometimes, the first generation of a directory structure for a project is too complex or not complex enough, and it is important to be flexible when something is not working. This requires communication and input from every team member.

Organizing and tracking assets is important, but it is equally important to examine the methodologies of building assets. Perhaps the method you begin with to create environment models does not work out to be the best way and is not optimizing the assets. It is better to admit something is not working and try to come up with something more efficient than be stubborn about hanging onto it because it was your idea. The thing to remember is that you are a member of a team. Leaders have a tough job as it is, and if a team member you are leading has a better way of doing something; why not save yourself some grief?

We have a great resource at our disposal as leaders: the web. I use the web all of the time to stay current on methodologies. Gamasutra constantly publishes post mortems, which identify pipelines and their flaws. One of the tools that can aid in building an art pipeline is examining the company's post mortems to identify patterns that may cause problems. If the company is new and has not adopted post mortems as a development tool, then the web contains plenty of examples, not necessarily catered to your production processes, but as a source of good ideas.

What exactly can be identified as a pipeline flaw? Anything that slows the production of assets or causes problems in the game engine can be viewed as a flaw. That may sound fairly simple, but a flaw can be an easily fixed problem as long as attention is paid to it. For example: Artist A creates models that contain subdivided polygons that have not had their normals flipped or unified. Artist B is assigned the task of applying textures to the models. Since Artist B is only concerned with mapping the textures, it may not be immediately obvious to him that the model is flawed and suddenly he sees the texture being drawn incorrectly on that portion of the model. He spends time examining his texture and his mapping when Artist A could spend a smaller amount of time ensuring his models are clean before handing them off. Now, instead of Artist A taking a few minutes to be more careful, Artist B is involved in a flaw in the process without really being responsible for it. You now have five minutes in total of 2 artist's time wasted for a total of ten minutes production time lost. Now if that asset is exported to the game engine and breaks the game code for whatever reason, you now have a programmer's time involved. Add in total fifteen minutes or more to the equation. That may seem unimportant, but if you are considering the generation of thousands of assets for a project it can really add up! Communicating a pipeline's success or failure can mean big time savings to the team as a whole.

Perhaps your pipeline requires five steps to get to the exported version of an asset. Is there an area that the programming team can examine to help you improve the time it takes to commit art assets to the game engine? As lead, you may need to identify the areas of your pipeline that are unacceptable risks and work something out with your producer.

Figure 2 shows a drawing made to identify the process pipeline. Given some thought, that process can be refined by asking the programmer team to come up with a way to unify the exporters used to get the art asset to game file format.

Tracking schedules and tasks

As game development becomes more complex and teams get bigger, it becomes necessary to examine software packages out there that can help you track tasks and meet your milestones. In the past, this sort of thing was left entirely up to the producer to worry about. But as lead artist, you may find yourself more accountable for slippages in the schedule, even if you feel your team is working as hard as they can to meet the milestones.

There are a number of applications out there that can help track tasks:

Microsoft's Visual SourceSafe
Alien Brain
Milestones Pro
FileMaker Pro

There are a number of bug tracking applications to help identify and track bugs:

TestTrackPro Web
Archimedes BugBase
Mozilla's Bugzilla
BugCollector Pro

You may ask why it is important to track tasks or track bugs if you are not the producer. Tracking tasks, especially with software like Alien Brain, allows you to monitor progress, back up versions of assets, and generally track how many reiterations of an asset were required to meet the final approval.

Tracking bugs is important to help prioritize the areas of production that need the most attention critical to game play or meeting the milestone requirements. Typically, most companies (game developers or otherwise) categorize bugs into three levels: A) critical B) needs C) wish list.

The review process

The review process is an important part of managing risk. Without reviews, the quality of the product cannot be assessed. Without reviews, technical problems cannot be addressed. The review may be a process that some artists cringe at, and it can be downright demoralizing - especially if the reviewer is insensitive to your effort. However, if you, as the lead artist, can develop an atmosphere of honesty and positive evaluation early in the formation of your team, reviews can help maintain focus, maintain enthusiasm in your project and raise the standards of your team's abilities.

There are varying approaches to establishing reviews. Some people prefer to do a one-on-one review while others like to gather the team as a group to gain more feedback. The best way to view the work is in the game environment. Problems with the look of a piece of art are fairly easy to troubleshoot once you have taken into consideration the game play and level of detail required for a piece of art. It is difficult to scrutinize a model up close in MAX or MAYA and dig away at minor flaws that you may never see in the game. If, after viewing a model in the game environment, there is still an obvious flaw in the model that is detracting from the quality, you can ask the artist to show you the file in the software. If the model looks correct in the software, then you may have a flaw in your exporting tool.

The style of reviewing the work is dependent largely on the atmosphere of your team. The frequency with which you conduct reviews is dependent upon the experience of the artists on your team; schedules and the current phase of the development cycle, may determine how often it is necessary to evaluate the work. I don't mean that as you approach crunch time it is acceptable to slack off the reviewing process, only that as you and your artists get more experience with the art pipeline and standards expected, the easier it is for the artists to produce at a level they know will be approved. As a production artist, having a clear idea of how the leads evaluate progress and quality, and having sign-off authority on the assets I am producing, reduces the amount of revision later. I also learn how to gauge the quality expectations and can eventually determine for myself whether or not the asset is going to meet approval. Be careful to balance the administrative needs of your role with maintaining the flow of production. Ask the artists how they feel about the sign-off process that you are currently using. If people feel that they have to stop their work too often to meet the requirements of the approval process, it may be time to re-evaluate that process.

The review process is not only the chance for the lead to maintain control of the schedule, but is also a chance to offer ownership to the artist. It is extremely important how you evaluate the art assets. Most artists in this industry are highly talented and capable people, producing under difficult circumstances. Most artists do not intentionally generate a lousy piece of art. An unsatisfactory asset is a result of one of two things: a) poor communication or b) poor direction. Chances are the artist is capable of doing the work, just may need more feedback or direction to achieve the desired result.

So how do you approach criticism? Do you allow the artist the opportunity to tell you what they think the art needs? Do you respect the artist and want him or her to do their best? Do you want a relaxed review process? Do you want to walk away from a review knowing that you feel as good about it as the artist you've reviewed? The answer should be yes. Example: Art lead and art director are called over to review Artist A's work.

Now not every team is going to be roses and wine, but if the spirit of the review process is positive, everybody benefits. The follow-up to the above scenario is that Artist A completes the request of the art director and the art director and lead, in the sign off process, re-affirm that they are pleased with the result to the artist.

Everybody has his or her own style and personality. As lead, it is your responsibility to make each artist feel as productive as possible.

The Lead as Manager

The toughest job the artist faces is to honestly evaluate their skills and the job they are doing. The lead artist in conjunction with the art director and producer must evaluate the performances of the art team. If the team is not meeting expectations as a whole, then the leads must make them aware of that and try to motivate the team to try harder.

It is important for the art team to meet together once a week formally to check in with each other, evaluate their progress and provide feedback from their perspective on what they are doing to meet their goals. Nothing says you have to meet in a room on a sunny day. Taking the weekly meeting outside if it is nice, is always a good way to relax the team and provide a fresh setting from the confines of the production room. After all, artists are typically esthetics, and respond to their environment like no other species of production worker!

Support takes many forms. Supporting your team as their manager should be your priority. If an artist is having technical problems with their computer, it's your responsibility to make sure they report to you any problems they have that are affecting their productivity. In turn, you should work with the producer to get the tools necessary to get the job done.

If an artist is having trouble working with a fellow team member, they should always feel comfortable enough to come and talk to you in confidence as their lead, and know that you will be able to help them deal with it. In turn, you may have the unpleasant job of weeding out the team members who are not consistently performing or are causing personality problems. Your priorities lie with enabling the art team as a whole to function, and to meet the milestones.

Your work environment can be an asset or a detriment, depending on the situation. An office is not necessarily the best-working environment for an art lead or art director if the office separates you from your team. Companies are fairly flexible when it comes to making requests that improve productivity. Open space environments can make communication easier, but can make getting work done more difficult if there are frequent social discussions intruding on an artist's workspace. Sometimes putting two or three artists together in a room works well as long as the rest of the art team is in close proximity to their room. You should never be afraid of asking to rearrange the art team's seating structure if you think it is not optimal for your needs.

Developing good communication skills

We work in the world of Geekdom. That is not necessarily a negative thing, but with it comes the plague of poor communication. Geeks are reclusive by nature and have spent much of their lives in front of a computer becoming better programmers or 3D artists. That means that some individuals' communication skills of may be lacking. I have worked with some outstanding people, every one of them nice, though a few of them have been a little tough to read due to poor social development.

How do you get your point across to a socially stunted individual? How do you solve problems with an individual who is defensive when their work is scrutinized in the troubleshooting process? Making another person feel as though they are saving you from a great struggle can go a long way. People like to be heroes.

Our industry proceeds with a lot of trial and error. Each and every one of us has done something stupid either because we forgot a step or were ignorant of the consequence of doing something a certain way. For example:

If the lead artist had developed a method of communicating with the lead programmer early in the project, they probably would have worked out a method of tracking dependencies and saved some trouble in the long run.

The main thing to keep in mind is that it requires good teamwork and communication to make a successful game. It is imperative that artists and programmers communicate well and that a spirit of cooperation prevails rather than one of blame and resentment. For the most part, I haven't experienced too many cases where I could not approach a programmer and work with him or her to resolve a technical issue. I've always made it clear that I respect the person I'm approaching for help and admit freely when I can't work something out on my own.

The common sense approach to communication is to remember that how you would like to be treated is how you should treat others; put yourself in the other person's place. Imagine how you sound as though you are talking to yourself in the mirror. Is your tone aggressive or friendly? Are you accusatory or expressing curiosity when approaching a problem? Try to consider a team member's level of stress when you gauge their response to you. Being under strain is certainly no excuse for rudeness, but reacting in a negative manner can only make the situation worse.

Developing good communication skills takes years of practice and constant evaluation. It is not an easy skill to master but an important one if you are seeking to become a leader.