Artists
vs. Programmers 1998
Wednesday, May 6th
This day seemed to have the largest diversity
of opinions on the subject and showed some very interesting trends by
the time we wrapped up the session. We began by having individuals state
who they were and what they did, as well as give a brief description
of why they had an interest in the roundtable. Two groups immediately
became apparent, one which was having problems and hoping to find solutions
and another with positive experience and a desire to share.
The two most notable problems were a lack of respect for their artists
given by the programmers and a lack of actual communication between
the two groups. We prompted the question of knowledge-crossover which
got good results. On one hand group having few problems had a great
deal of crossover between their artists and programmers; to the extent
that some of the artists were writing their own tools to make their
job easier. In fact, one person at the roundtable did a great deal of
that himself, acting as sort of a go between for the artists and programmers.
He went out of his way to aquire and share knowledge with each group
as well as encourage them to do that themselves. In addition, this group
tended to hire on actual merit of knowledge and abilty to learn and
grow, with a degree of raw talent thrown in the mix.
The other group tended to keep artists and programmers as far away from
each other as possible, and interaction between the two was not really
encouraged. Hiring was also handled differently for their artists and
programmers. Programmers were required to be college graduates with
a degree and never having worked in the industry before. In theory the
idea was that they would have a good knowlege base to start, be cheaper,
and moldable to suit the company's needs. It was also felt they would
be extra hard workers because after years in college they would be burning
to start "real" work. To a degree this actually worked for them, but
where the idea falls short is that because the artists were hired for
their artistic skills alone, not for their degrees, the programmers
tended to look down on them, as though they were a lower class.
Another intersting note was the flexibility that the different groups
had. One with flexible hours and diverse tasks, the other with strict
hours and plainly laid out tasks. For certain types of jobs, everyone
keeping the same hours and having clearly defined jobs works; but it
also creates an assembly line mentality where creativity, innovation,
and problem solving aren't fostered. The results were actually very
apparent in the way the two types of groups were structured, with the
more flexible structure having fewer programmer-artist problems.
Of note was that one company had experimented with letting their artists
take a stab at design; unfortuanately with very little technical knowlege
of how the design would be implemented, or their game engine's capabilities,
they had fairly miserable results. In fact the person stated that he
would no longer allow his artists to do design. The biggest flaw in
this case was a lack of focus and knowledge on those particular artists'
parts, in fact it was expressed that the artists were kept away from
the technical discussions that their company had. It's very important
that at least some of the technical knowlege needs to be passed on to
the artists so they at least know what parameters they are going to
be working in.
A lot of good ideas were put forth on how to solve some of these problems
and the discussion was quite productive, and the discussion extended
overtime by about 20-25 minutes.
Thursday, May 7th
This session was not quite as polarized in how things were handled at
the different companies that were represented here. Again we started
with everyone introducing themselves and stating their interest in attending
the roundtable. After brief introductions around the room we prompted
the subject of communication between artists and programmers at the
various places.
Today the focus seemed less about actual problems between the two groups
as opposed to how to handle production hurdles and get the two groups
thinking toward the same end. We had one person there who did seem to
have problems with his artist, in that he did not want to stifle the
artist's creativity but found that often the wealth of ideas springing
from the artist got in the way of actual production. Too many ideas
kept the designs of their games in constant flux. After some prodding
we learned that the production cycles on their games were very short,
a month or so per title! Having a constantly changing design would very
obviously make it difficult to bring a game in on time with a tight
schedule like that. The consensus was that the group needed to learn
to "just say no", and put the ideas into the next game.
Also of note in today's conversation was the filtering devices that
certain groups had developed in order to better get art integrated within
a game. The larger groups had people in place that would actually be
sure that all the art was converted to correct palettes, given proper
naming conventions and so on. What seemed to be a shortcoming here was
that only a few people in their group would make an effort to discuss
problems with each other, this was instead left to the filter people.
So while there was a little bit of knowlege-crossover occurring here,
the lack of personal dealings could lead to the feeling of alienation
between the two groups.
We covered briefly the subject of proper tools, how they were developed
,and what different conditions brought about their need. This day also
went overtime.
Friday, May 8th
This was an extremely small roundtable, attended mainly by people that
seemed to have little or no experience in either the art or programming
aspects of a game. The biggest diversity here was people that had actual
production experience and those who had very little or none.
The talk focused primarily with the group's past struggles and what
the less experienced people may actually face once they get more into
the production of an actual project. We were joined about halfway through
by a seasoned artist at a large publisher who also did internal development.
He shared his difficulties both there and at a previous company in which
he worked. It was interesting to note that both places were started
and mostly run by programmers. We felt that perhaps there was a bit
of the class issue occurring there as well, being that the company was
geared around the engineering department. The art tended to take a back
seat and it was more difficult to get proper tools developed. However
this individual did take the effort to try to learn enough about the
technical side of things that he might offer solutions to certain problems
they were faced with. As an art director he felt it was his role to
be a go between and make sure his artists had a good knowledge base
technically in order to do their work. The biggest hurdle here centered
more around the respect or clout issue within the company.
We were joined toward the end by a writer covering the different talks
at the conference who prompted us with questions about the industry
in general.
Summary
Based on the discussions during the three days and our own experience,
we compiled a three secion list of areas to focus on in order to minimize
friction between artists and programmers while at the same time helping
everyone produce that killer game.
Technical
Often overlooked, the technical aspects of a project can have a significant
impact on the ability of the artists and programers to communicate.
1 Selecting the proper tools.
Proper tools are vital to the success of any project, and you can see
further gains if the selected tools allow the artists and programers
to easily coordinate on the work, share data (in both directions), and
minimize the number of specialty tools required.
2. In-house tool development.
It is almost always the case that existing tools fall short in several
areas that must be covered by in-house tools. Spending the extra time
during the development of these tools to insure that they are easily
used by the artists on the project can have a significant impact on
the quality and timeliness of the art delivered.
3. Knowledge cross-over.
The more each side knows about the capabilities, tools, and requirements
of the other the better. At a minimum programmers should be able to
use the art tools, and the artists should know how to use the data translation
tools for the project.
4. Defining the Process .
As early as is practical in the project, the process of taking art and
implementing it in the game should be defined. Even if it changes later,
this definition should allow the artists to place their art into the
game.
5. Decision Making.
Major decisions by either side should include input from the other,
to insure that each side knows about such changes and has a chance to
insure that these changes can be implemented within the project structure;
or if not, that the project structure gets changed to allow those changes.
6. Understanding the Design.
Each side usually understand the design from their aspect, but taking
the time to understand the design from the other's aspect will help
ensure everyone is working toward the same goal. This also will help
to reduce the time required to make changes.
Personal
Each member of the team, whether artist or programmer, has an individual
communication style, as well as an indvidual personality. Learning to
identify,and work with other's styles is a must.
1. Dealing with Change
Everyone should first accept that the project will change,to some degree
before it's finished. How these changes are brought up and handled can
have a tremendous impact on a project.
a. Approaching others
When and how to bring up change can help reduce it's negative impact.
Is the change final? Can it be revised? Do you tell the other side or
wait to hash it out first? And, when you do bring up the change with
the other side, how do you approach them?
b. Controlling reactions
The common reaction to change is to deny it. I"t can't be done!" is
a common response when someone is told about change. Learning to control
this initial reaction can help everyone get thru the process more easily
and quickly.
c. Acceptance of denial
If you are the party informing of a change, you should be able to accept
the other's denial of the change. Take a break, let everyone think it
over, and solicit options to ease the decision.
2. Keeping Communication lines open
Communication is propobly the most vital aspect in maintaining good
working relations, and at the same time it's usually the first area
to break down in a project.
a. Project issues
Both sides should make every effort to keep the other informed of all
major issues, developments, concerns, and ideas. There should be a formal
method for this communication, whether it's a weekly status report,
a weekly staff meeting, etc.
b. Personal issues
Individually, it's also important to communicate. Did your mother just
die? Probably a bad idea for someone to approach you about extra work
right now. Got a dentist appointment? Anyone expecting something from
you that day should be informed to expect it the next day. Communicating
your moods and schedule can help everyone to work with you more easily.
3. Interpersonal Relations
One of the hardest aspects of communicating is that not everyone communicates
in the same manner. Just because you understand what you are saying,
does not mean that everyone else does. Taking the time to communicate
in terms your audience understands is worth the effort.
a. Keeping personalities in mind
Everyone has a unique personality, but there are a few generalities
that can be used to help everyone communicate better. Some people like
to be told what to do, while others like to be asked, and yet others
need to have input on the decision.
b. Modifying your communication style
Knowing how someone else communicates best is only half the equation.
The other half is being able to modify the way you communicate. This
can involve how you phrase things, your mannerisms; it could even involve
your appearance.
4. Making the effort to know your co-workers
Of course, the best way to learn how to communicate with your co-workers
is by getting to know them. In small companies this is (usually) pretty
easy, if not unavoidable. In a larger company, especially if you are
not the out-going type, this can be much harder. Make the effort!
a. Communication
Interacting with someone in a non-work environment, or at least about
non-work issues, can strengthen your knowledge of that person's communication
styles and lead to better communication on work related issues.
b. Knowledge
In addition to communication, interacting with co-workers helps spread
knowledge, which benefits individuals and the company (heck, the industry)
as well. Remember, don't limit your knowledge to just your field, interact
with the other side! It will increase your abilities, enhance your advantages
and expand your opportunities.
Leadership
For those in a leadership role (Lead Programmer/Artist, Art/Technical
Director, etc.) communication should be a major concern, for their success
depends upon it.
1. Coordination
Communicating what is happening within the project to those involved
is a given. But what about those on the periphery? Even if they are
not directly informed, it is a good idea to make as much information
available as possible.
2. Translation
Because most individuals are unaware of how to communicate effectively,
or unable to adjust their communication style to be effective, it is
often up to those in leadership to translate what one group or individual
communicates to the other. Learning when and how to do this can greatly
ease, or even prevent, dissatisfaction between groups.
3. Buffering
Another effective way to ease communications between groups is to buffer
information. It's not always required to let individuals know everything,
sometimes information can be damaging. At other times, waiting for a
few days can allow a potentially damaging situation to resolve, saving
everone a lot of unneccessary headache.
4. Focusing
As an individual team member, it is easy to become sidetracked; it is
up to leadership to insure that individuals, and the project team as
a whole, stay focused. In regards to artists and programmers, it is
also up to leadership to ensure that one group is at least aware of
where the other is focusing its attention. This allows each group to
concentrate their efforts to the best advantage of the entire project.
