Technical Support
Another major area of responsibility for technical artists is to provide technical support to the art team. This includes tasks such as diagnosing a problem an artist is dealing with in the content creation package (3ds Max, Maya) or other in-house proprietary tools.
Filling in the support needs of artists can be a time-consuming process. To speed up the process for technical artists, we require that all requests be sent through email in the form of a descriptive explanation of the error or problem, along with attached screenshots.
We do this for several reasons. At Volition, technical artists support a vast number of artists, including any who are outsourced. It's critical that the response be focused to reduce the amount of time spent on the request and get the artists back up and running so they can continue to work with as little interruption as possible.
Scheduling
A lot of what a technical art team does (depending on how far the team is in the development process) affects scheduling, both their own and the project's. As individuals, technical artists frequently switch between developing tools and fighting fires, often at a moment's notice. And as multi-disciplined team members, they are required to be in many other departmental meetings, some of which come up unexpectedly.
If management accepts that the discipline is difficult to schedule and maintains an open mind, scheduling technical artists can be manageable.
Here are a few approaches we've found that work well in creating technical artists' schedules.
Early identification of needs. At Volition, we allow anyone in the studio to submit ideas for a feature or new tool to the project via email aliases. These items are reviewed by all project leads and dependencies are identified at this stage.
When evaluating a request, we use a five-point rating scale, with 1 signifying "must have." We make it a priority to fill all level 1 and 2 requests, while items with priority levels 3 through 5 are reviewed later to fill out empty spots in schedules.
Due diligence. Every tool or feature request goes through a three-phase process: investigation, implementation and documentation.
Investigation is used to identify risks of the request. Too often, risks are not accounted for in the schedule; by identifying them, you impress the importance of building solid tools.
Documentation is often glossed over. Good documentation ensures that anyone using the tool, no matter their technical ability, will use it properly.
Schedule support time. This is to accommodate the roller coaster frequency of support calls. From our experience, we have found support time typically ramps up quickly the closer you get to the end of a milestone or deadline.
Schedule buffer time. Even with the scheduled support time, things inevitably crop up that can't be foreseen.
Change management. Implementing a solid change management plan for tools and feature requests is essential to keeping to the schedule. Too often, features are requested for existing tools that may seem minor to implement, but added all together they further complicate the already difficult problem of scheduling tech art. See Figure 2 for a flowchart that illustrates how we have implemented our feature request and change management plan.
Figure 2: Volition's flowchart for feature requests as well as a change management plan.
Implementation
How many technical artists should a company have? Over the past few years at Volition, we've found a need for three or four per project with a team size of roughly 80 to 90 people.
We structure the team such that there is the lead, who is the technical art director, then at least one senior technical artist, and a character technical director. The others are more focused technical artists who are assigned to specifically dial in on certain areas of the game.
While finding the right person to fill this role is difficult, it should not be overlooked in today's competitive and high cost environment. If your studio has no technical artists at all, or has some that aren't being used to their full potential, I encourage you to take another look. You'll be glad you did.
---
Title photo by Wolfgang Staudt, used under Creative Commons license.
|
Printer-Friendly Version
Posted by a geek,
Continue to be pissed off. 8-)
I don't agree that the technical artist should be the one writing the tools in the future though. That's what tools programmers are for, of course the technical artist should be the one that tells them what tools need to be made and how they should work. As soon as the technical artist starts writing tools it will be perceived like just another programmer that artists have to beg to for features and bug fixes instead of an ally that can translate their needs effectively to the programming team.
Also, unfortunately the example given in the art of diplomacy section doesn't really proves the point of the need for a technical artist, there are much better examples. For that specific example, any graphics programmer worth its salt would have proposed a mixed system, or other ways that allowed to preserve the per pixel dynamic lighting on the parts were it really is important, and fake them (or alternative ways to do them faster or lower quality where possible) to keep the frame rate up as soon as the performance problem was discovered, if not way before that. A good graphics programmer would have seen the possibility of that problem arising since the really early stages of development of the game engine and develop techniques or enforce practices to avoid it entirely.
To Anon: Technical artists are real artists, at least all the good ones, they just happen to know the technical side too.
As for the first poster i think you need to consider the film industry where you can afford to take weeks to render a scene and each character model is a billion trillion polygons each!
Whats missing from the article is alot of the art side of the role, working with programmers is only 1/2 the job the other 1/2 is looking at art pipeline efficency, how things are constructed, the way shaders are used etc to make the assets as efficent as possible and allow artists to get the biggest bang from their buck, yes support for the software package is there but its vital that guidelines are established and regularly checked for the creation of assets, a large game can no longer afford rigourous scrutiny of indvidual assets for inclusion in a build.
I totally agree, I've been a part of a company where a
Tech Artist has completly sabotaged the studio by passively aggressively controlling the pipeline.
These types really need to be watched carefully, because they are not creatives but instead are pipeline bug fixers. I'd rather change their names to "pipeline technician."
This specific Tech Artist, was a huge whiner and sabotaged the entire creative process. So we began to invite this person into the creative meetings; to no real creative person's suprise his ideas where way off to being anything unique or stacked.....
I can see why you'd object to the term 'artist' if you worked with mere 'pipeline technicians.' When another artist, who happens to have some coding experience sits with you at your desk to design a tool and really stresses over making the work flow easily and efficiently based on your creative process, you'll appreciate why Technical Artist is an appropriate title, especially when you compare that to the glorified spreadsheets, through no fault of their own, that programmers deliver as tools.
However, as a software engineer, I don't believe you'd need to introduce a Technical Artist - or a whole team of them for that matter - to solve 99% of the issues this article is mentioning.
Obviously, there needs to be a real software design process while crafting tools, but to me, this falls in the responsibilities of the Tool team.
Let me explain : in other industries involving software odevelopment, a programmer/engineer and even more s someone creating tools is not only expected to have technical knowledge but also to build an expertise about the domain he's crafting something for. For instance, someone involved in making software for trading is supposed to end up knowing most of the stuff related to this field, otherwise what he does will somewhat be off the expectations.
Thus the problem lies with Tool Programmers being unable or unwilling to understand whatever artistic field they are in contact with. So rather than introducing a new element, you need to pick tools programmer based on their ability to work tightly with artists and manage them so they can build an expertise about sound, art or level design. Then you won't need a middleman that might slow down the tool creation process.
You need somebody like a technical artist (or tool programmer if you want to use a different name) on these large teams in order to facilitate work between two increasingly specialized disciplines. Specialists - those that are pure programmers or pure artists - put a lot of focus on being good at what they do. However, the more you focus, the less ability you have for bridging the two disciplines. You need a generalist or two in order to get your studio's left brain to work effectively with it's right brain.
The fact that a good tech artist is so hard to find is probably part of the reason that the vast majority of development tools for games are absolute garbage compared to what they could be.
They are artist (generally coming from an animation background, but not always) with a distinct eye towards art that is functional in a game. And that is the key here... they understand what will be functional in a game. And not only are they able to communicate on both a technical level (with programmers) and artistic level (with artists), the ingredient that makes a technical artists successful is their ability to translate across disciplines.
From a programmer's perspective, I have seen artists make claims that they are not being given the tools or engine to do their art. I'm a programmer and not an artists so sometimes I don't have the ability to refute their claims. A good TA can come in and call BS on the artist and proceed to demonstrate the skills required to get the job done.
Likewise a good TA can have greater knowledge in the tool that is being used and can point out features of the tool that the tools programmer didn't know about. So if a programmer says they can't implement tool functionality because the base tool does not support it, then the TA can call BS on them as well. Not only that, often time the TA can script up a solution much quicker than a tools programmer can code it.
Where a TA excels is not in making suggestions about engine and tools features (though they are generally better at it than most non-technical artists), but in cross communication and watch-dogging between the individual disciplines.
Thomas is right in saying that the benefit from such a role only comes when the resources have exceeded a certain limit, but that is true for every business were multitasking is better for smaller companies.
I wouldnt consider myself an artist as I dress relatively modestly, and i dont have a plethora of little toys around my work station :) I do however, understand the wants and needs of artists and the technical capabilities of our platform. Our role is quite unique, but it is very VERY satisfying reading that it is recognized by the industry.
The "technical artists" (GSI) in our company are a critical and integral part of the SDLC. What was done in a day several years ago, can be done far more accurately and efficiently in 15 minutes with our new toolset and methodologies. Also, when you have a team of 50+ software engineers, you will have a large number of "colorblind" and "tasteless" software engineers. Hence why we keep the art to the artists, and the software to the software engineers - further justifying the need for such a role.
And then theres the issue of software cowboys who think they have a great eye and secretly add their own personal graphic touches, but that my friend, is another story.