Do artists or programmers write the best art-tools?
You need what?
Artists have needs, especially game artists. While we can suffer through dense user interfaces all day, and do, inevitably we reach some insurmountable obstacle that will either take too long to get around or we finally insist on not pressing the same 40 button sequence for the tenth time in a day, the tenth day in a row. There’s a rhythm to the clicking that takes place when someone is processing art as opposed to creating it. It’s maddening, but it’s necessary. Like paperwork. Enter art tools. We need custom art tools.
A good tool — we’ll call it a tool — can solve problems, lessen the tedium of repetitive workflow and even provide unique and interesting output. Tools handle export and file operations and some do the seemingly impossible with mesh components. This is all well and good, but when does one decide that a custom art-tool is required and where does one come from?
Programmers can certainly write most any tool but they’re often hooked into an all-important low-level task (earning that salary) and might scoff at the notion of dulling their skills by slumming it with Python for a day. Technical artists, should you be lucky to have one at your disposal, are a sure-fire way to get some kind of tool into your chain but the prioritization of their tasks is often at the mercy of an entire team (and the bosses) and in the heat of production, getting a tool (your tool) on their list of tasks often won’t happen. As an individual, one with needs, you might be on your own.
We know what we want and we want it now.
Lets put a positive spin on this: it’s possible for artists to write better tools for artists because we know what we want our tool to do and we know how we want the tool to work. For example, take the seemingly simple action of selection order: more than a few common modeling or rigging operations requires multiple-object selection and a specific selection order. A simple operation can become maddening when your new tool counter-intuitively has you select objects in reverse order than expected. There are numerous examples of this in Maya — yes, the tools built into Maya — where some functions require selection in one order and others require the opposite. It’s a feature, not a bug! Or is it poor programming? Lack of communication?
I know of more than a few production cycles in which a ‘broken’ tool has been implemented into the primary tool-chain, becoming part of the backbone of the production pipeline yet containing more than a few annoying flaws. It is not an easy decision to prioritize valuable programmer time toward resolution of these issues and often the team is left to deal with these quirks on a daily basis. While it might seem like an artist-programmer combination will yield an intuitive product that works, the communication and collaboration required is exhausting, if not unnecessary. Perhaps you simply wish for a series of actions to occur in a specific order — like a macro. You might not need a programmer for that.
But artists can’t code!
I’ll insist that artists can write code. All artists can code, the suggestion that this is not true is a deeply rooted misconception that I suspect originates from artists themselves. Shifting gears to learn something new after years of building a successful artistic practice can be exhausting! That said, while I don’t think I fall in line with those who believe that learning a programming language is like learning a foreign language, there has never been a better time to pick up programming. Languages like Python are not only easy to read and fairly easy to comprehend but also require only a few basic concepts to get started and tutorials are everywhere. Having taught Python programming and writing basic tools to artists over the past few years, I have yet to have a single one (maybe one) who couldn’t grasp the concepts of programming and turn out a useful product or two. Remember when you would consciously take yourself out of your “comfort zone” to learn something new?
To be fair, we’re talking about fairly high-level “scripting” here and engine programmers might scoff at the notion that we’re discussing programming at all. My rule: if it looks like code, you’re probably programming. Semantics.