Hello everyone, I’m new around here but I tend to visit regularly. I’m sure this has been asked before but I can’t really find any good information on becoming a tech artist. So, how does one become a tech artist? I know many people tend to come from either an art or programming background to begin with, my problem is I’m not sure what to focus on for a portfolio.
I currently work on http://www.orion-project.net/ a Source engine mod as a technical artist. I help with rigging, learning and teaching technology to team members and developing a script here and there to help speed things up.
I’m currently in school for game design, so I’m pretty well rounded in many aspects of what it takes to pull a game or mod together but I’ve found myself really enjoying rigging, animation, and really getting to know the tools of any given engine. Upon graduation I’d like to be able to land a job as a tech artist. So, what should I really focus on and place in my demo reel to prepare myself for this?
This comes up constantly and it is a good question. I have personal guidelines which probably fall a bit off the beaten path somewhat.
Ultimately I will be looking at the following:
What problems did you solve creatively?
What I’m looking for here is ‘art’. I’m going to try to find out about what issues came up on projects you’ve worked on and ask the solution you did that you’re most proud of.
How well were these solutions implemented?
This is about ‘craft’. I’m going to delve into the details of how you implemented the solution and ask for samples. The technical implementation is less important than the conceptual implementation (how do you handle error or edge cases, do you understand how to write good code, etc.).
How are you on your technical feet?
Did you re-use available code instead of writing your own? Where did you write your own? How have you used and extended middleware? Have you adapted your technical proficiencies for what you need to do?
How are you on your verbal and interpersonal feet?
You need to have good communication skills, be a fast thinker, have a thick skin.
Ultimately, I’m not looking at demo reels for tech guys. The work you do in your first 2 months will be more technically advanced than the biggest thing you’ve done before, so I care less about what you have to show and more about what you’ve learned. So be active on the forums, get to know people, post questions, post answers or the results of those questions. HR can be a TA’s worst enemy, so try to go directly to the source and get to know the other TA’s themselves. HR will want experience and pretty things, neither of which are relevant.
I’d focus on whatever answers those questions the best that fits in line with your passions. If you want to rig, don’t show me a rigging reel, show me some unique condition your game demanded that you needed to solve that required you to implement this really crazy joint type. If you want to write tools, don’t show me a tool, tell me about some unique condition on your project that required you to write something interesting.
Thanks, that link is a really helpful read. And Rob, that’s probably some of the most useful advice I’ve heard yet, thank you!
I can see how HR would go nuts on experience, so I’m assuming it’s going to be hard to break into the industry as a TA. We don’t use a lot of middleware nor have many “technical” issues come up in Orion… yet. So through a mod, experience will be difficult to acquire.
I do have another question, some of my scripts/macros are not the cleanest, and I’m sure there are better way to do things I just may not know yet - is extremely proper code and the most efficient ways to do something looked at when hiring a TA? I may not always know the best way to do something but scripts I’ve slapped together have gotten the job done, and done correctly. I’m curious to know if a script I write will be nit picked upon because there might have been a better way to go about something.
And my final question, for now. Most TA deal with a pipeline creation/maintaining in some form or another, correct? How exactly do you learn to do something like this, or is all experience?
[QUOTE=0x40;6387]
And my final question, for now. Most TA deal with a pipeline creation/maintaining in some form or another, correct? How exactly do you learn to do something like this, or is all experience?
[/QUOTE]
Unfortunately, comparing my time as a student and as an intern as a TD, there doesn’t seem to be a way to encounter the types of problems and issues that would arise in a large production project at a studio.
[QUOTE=0x40;6387]I do have another question, some of my scripts/macros are not the cleanest, and I’m sure there are better way to do things I just may not know yet - is extremely proper code and the most efficient ways to do something looked at when hiring a TA? I may not always know the best way to do something but scripts I’ve slapped together have gotten the job done, and done correctly. I’m curious to know if a script I write will be nit picked upon because there might have been a better way to go about something.[/quote]
Well yes and no. No one is going to hire you based off your code quality, because it is undoubtedly going to be worse than the people already on the team. What I’m looking for is mostly conceptual- how are you checking if the user has done something correctly? Are you checking at all? Are you re-writing a bunch of custom functions for things that are built in (I’ve heard of people writing replacements for String.Replace)? How have you managed to integrate code you haven’t written?
Being good is more than ‘getting the job done.’ Be careful who you use that term around- I personally find it offensive. The ‘job’ is a multi-year, multi-million dollar game in many cases, and if you write something for every task that gets the job done, you’re going to end up with an horrific toolset and script suite. Paramount to be is high-order thinking- I want to see libraries and reuse more than anything, probably (ie, if you write a script that emails someone if something’s wrong, don’t put it in the ‘texture setup’ module/assembly, make sure it abstract it well enough for future use).
Oh and also, this is minor but I think a good tip when people are judging your code- use standard formatting. If an accepted style guide exists for your language (it does, even for MXS, which can be found on our Wiki ), USE IT. Especially things like tabbing, parenthesis, and blocks/braces. It can make or break borderline code evaluation- it says to me, this guy doesn’t really care about writing code together, and I’ll nitpick that much more.
And my final question, for now. Most TA deal with a pipeline creation/maintaining in some form or another, correct? How exactly do you learn to do something like this, or is all experience?
You really can’t and no one expects you do. Solving the lower-order problems that will arise on a mod will be good enough and allow you to develop the tools you need.
), USE IT. Especially things like tabbing, parenthesis, and blocks/braces. It can make or break borderline code evaluation- it says to me, this guy doesn’t really care about writing code together, and I’ll nitpick that much more.