Like I said at GDC regarding ‘tech vs. art’, I disagree with the rationale (you must understand the art workflow, have been an artist, etc.) has any bearing towards the conclusion (how to be a good TA, which here entails writing good tools, systems, and pipelines).
A logic proof if you will:
[ul]
[li]You must be making production art regularly to be the very skilled in production art.
[/li][li]You must be programming regularly to be very skilled in programming.
[/li][li]Time spent making art is not time spend coding.
[/li][li]Very few people will be able to split time equally between programming and production art and be very skilled at both.
[/li][li]Production art proficiency often leads to alternative and better art workflow ideas and techniques.
[/li][li]Technical proficiency always leads to alternative and better ways to create tools and systems.
[/li][li]Technology, both technical and artistic, changes quickly enough that technical skills learned on one project may be outdated on the next.
[/li][/ul]
Now, obviously, there is a HUGE gray area- a decent coder who is a less-than-decent artist will probably come up with a better workflow or optimization than someone who is a pure production artist; and a decent artist who is a less-than-decent coder will probably write tools that are difficult to maintain, if effective for a single task. But that gray area is my entire point- I don’t give a fig about the gray area. There shouldn’t BE that gray area. The only reason we insist on imaging there should be such an area is because we’ve attributed an effect (tools for artists) to a cause (artists who can code), with absolutely, positively, zero proof that the ‘artist’ portion of the equation is in any way relevant.
Let me pose two scenarios and tell me which will yield a better result.
- An artist on each team is generally able to script. There are one or two dedicated technical artists who are generally more proficient technically.
- A technical team is assigned to support the art department. The team does not make art and does not necessarily have art training.
I’ll bet that #1 is what your studio probably looks like. And if you think it is working, it is because you probably need to work on your technical abilities. The most likely result of such a setup is a codebase that is poorly implemented and maintained, written in inconsistent conventions, poor sharing and communication between code and coders. The time required to learn how to be a good programmer in a team and tool context is prohibitive towards doing any art whatsoever, and these are artists primarily, so the code sucks.
The alternative outcome to #1 is that the specialized TA team focuses solely on programming, developing a sophisticated codebase and convention. However, such a condition practically voids any work other less-technical TA’s can do. The less technical are unable to leverage the more technical code, so they write code that is difficult to maintain, redundant, and slower to develop- it is quite clear that there is no point to even writing it in the first place. Let the technical people write it.
I dare someone to come up with an alternative outcome (that doesn’t hinge on a superman who is able to make AAA art and is a MS certified programmer). It is logically not possible. Which begs the question- what does our experience as artists have to do with our skill as a TA?
Nothing. As stated above, any attribution is merely coincidence. The much more important trait is that we identify as part of the art team. Identifying as part of the art team, being scheduled by them, beholden to them, is what makes a TA department effective at making art tools.
If you don’t believe me, let’s imagine a different department: Project Management. What do you think would be more useful? A PM who learns Python and is able to automate spreadsheets, emails, etc.- remember, at the cost of other PM duties- or a programmer who is going to be able to tap all of that automation in with the much more complex systems involving the game and art pipeline systems? How much more effective would a PM be at tracking work if he had a python script that creates and emails a spreadsheet, vs. a programmer who could implement a callback whenever a file is checked in that will update a database automatically, and a script will audit the database daily and send out the status? They key factor here is that the initiative is driven by Project Managers, and the person writing the tool is not doing it as a one-off or on the side. He is beholden, full time, to the PM team. So when an opportunity arises to integrate that auditing system into other components of the pipeline (what is exported, what is broken), the ‘TPM’ is available to act, depending on if the PM department (not engineering) wants him to.
What’s the point of all of this? It isn’t to put anyone down or insult a TA department. It is to ‘arrive’ as a position, and culture. We are appreciated, but still not acknowledged. We tend to be some of the most successful departments in a studio, but we have to fight the hardest to grow. The word ‘automagical’ should be offensive: people need to understand what it is we do. And that is not going to happen by creating boxes and boundaries between you and different departments. We can’t be lagging behind in our skills to not be able to interact with, fix, extend, the code of any programmer impacting tools and workflow. When we focus on the ‘art’ pedigree or skills, we’re cutting ourselves off from a very important reality of our position, a new branch of our evolution, in order to hold onto a vestigial, coincidental aspect of our geneology.
