| |
| | ||||
![]() | ||||||
| | | |||||
|
GDC 2003: Art Management For Artists Pitfalls for New LeadsNew leads take a while to settle into their position, and, based on their temperaments, there are certain patterns that they can fall into in dealing with their new responsibilities. Lead artists are less artists who manage than managers who are in charge of artists. The manager is simply that - an administrator. His time is spent with graphs and charts, on the phone, in meetings and in frequent conferences with individual artists. The art load, if there is one, is very light, and likely to be off the critical path. The art lead needs to have good data on whether the project is on track, and where the problems are if it isn't. The manager thinks of himself as the one who keeps the wheels greased, management informed, and his team happy and well-supplied. If you stay in your job long, this is the type of lead you will be. I have exaggerated a little from my own experience and that of some of my co-workers, but only slightly. Keeping up with data and keeping in touch with your managers, your team, and your outside dependencies makes up the majority of your responsibilities as a lead artist. Developing those skills will be the story of your career. If you don't enjoy at least some of that, you're in the wrong job. And it's not impossible to maintain a creative life, as long as you are realistic about what is expected of you, and you plan ahead. But there are pitfalls that you need to be aware of in developing that position. Here are a few that I have seen, and that friends of mine and I have fallen into.
The Other Leads One of the purposes of the lead artist is to shield his or her artists from the other leads so that they are not interrupted in their work. That means that you will need to have a good relationship with all the other leads on the team, particularly the lead Engineer and the designer. You are the gatekeeper for the artists, and they should expect not to be pulled in different directions by your manager, the producer, or engineers. Engineering We've already talked a little about how important it is to be in synch with the Engineering lead. Art and Engineering are likely to have the most friction on a team. When dealing with engineers, remember that they need a different kind of information from you than other artists do. Find out first in any negotiation what the engineer needs to know, then work from that point. My favorite
story about this kind of thinking was from a talk by Dave Perry of Shiny.
He asked an engineer if characters could ride motorcycles in the game
they were developing. A good Engineering Lead will act as a translator between you and his programmers. In turn, respect his boundaries and get permission to work directly. Design Designers are some of the most overworked people on a team at Red Storm. This fact and the fact that most design work is paperwork means that designers can become isolated from the team. Even the best designers can't predict all of the kinks in his vision. That means they will need to adapt as conflicts arise. Since adapting means re-design, the Art Lead needs to try to predict, to some degree, where changes are likely to be made. At the beginning of the project, there are some things you can do to minimize future problems. Sit down with the designer and feel out how open he is to informed criticism. There will be areas where your particular expertise can help avoid problems or unnecessary waste down the line. After all, you as Art lead will probably know what is possible to build and what is the most efficient way for your artists to work. If you are not pushy or overbearing, you may find that the Designer is very open to good ideas. You won't know what parts of the design are most flexible until you ask. Be ready, too, to adjust your plans when the design cannot be modified in your favor. Quality Assuarance One part of the team we haven't mentioned to this point is Quality Assurance. Testing tends to be an afterthought at many companies, and Red Storm has certainly had the same problem. We quickly discovered that not including QA in planning and schedule discussions always led to headaches down the road. Why? Because testers have to verify everything that any other part of the team does. QA develops a test plan that lays out how and when major features of the game are declared to be finished and functional. They must therefore know when to expect them and what they will have to work with. To release a bug-free product on time, they have an established system for rubber-stamping what the artists and engineers have done, so missing verification can mean major interruptions in the pipeline. Worse, it can mean that elements of the game are never tested until there is no hope of fixing them. If anyone
has faced the nightmare of finishing a game, only to find that it isn't
fun, then you know why QA is important. Make QA's job easy, or they can
make yours very difficult. You have been warned. Wrap Up Every company and every team is different, so it's unlikely that the answers you get to the questions I've asked will apply to every lead. Similarly, no amount of thinking on your own can replace experience, and no one has more experience with the problems you will face than other art leads. Use them. Another excellent resource for pinpointing problems and finding possible workarounds is post-mortems from other teams. If your company doesn't do them, organize them yourself. If done right, they are a gold mine of information on process. Everyone on the team, not just the artists or your supervisor will review your performance. Odds are, people will say things they wouldn't have during the project, because they were afraid of getting fired or rocking the boat. If you have ever read more than two post mortems, you will probably have a feeling of deja vu. Most projects have a set of problems that are almost identical - incomplete or constantly changing design, poor communication between art and engineering, missed deadlines, loss of staff, and short schedules are on almost every list. These can mostly be dealt with by proper planning, and are within your control. What makes postmortems from other teams so useful is that they have specific problems, and solutions for them, that you might not have foreseen. A good source for postmortems from other companies is Game Developer magazine. I'm sure you've seen free subscription forms all around the conference. Get it. It costs you nothing, and you won't be sorry. I also recommend two articles by Dianne Davies about the particulars of being an art lead. They are still on Gamasutra. My last suggestion is talk to the people who do it right. If you see a project like yours that looks like it was done well, call the lead artist and chat. If you see anything done well, if you see any product that shows real excellence, find out how it was done. Call the lead artist. Call the art director. Call anyone who will talk to you. As long as you are polite, people are very receptive. If you call someone who's not, what have you lost? Other people
have done this job before. Find out what they have to say. ______________________________________________________
|
||||||||||||||||
|
|