Planet Tech Art
Last update: March 30, 2015 04:01 AM
March 28, 2015

Maya Bug Watch: API2 and GetPoints()

In general I’m more or less a fan of Maya Python API 2.0. It’s more pythonic and feels faster than the old version. However, it’s not without its quirks and I just found one that really bit me in the behind.
If you want to get the vertices of an object in the api, the usual formula is:
  1. Get the dagPath of the object
  2. make an MFnMesh
  3. call the ‘GetPoints’ method of your mesh
  4. party on.
Something like this, which returns a list of MPoint objects for the verts in the mesh
import maya.api.OpenMaya as api

def get_verts(mesh):
mobj = api.MGlobal.getSelectionListByName(mesh).getDagPath(0)
# that's lazy, it assumes that the first child is the mesh shape.
# in practice you need to be more careful...
mfn_mesh = api.MFnMesh(mobj)
vert_array = mfn_mesh.getPoints()
return [i for i in vert_array]
This works fine and dandy… except:
If the mesh has 256 or more verts, the first vertex comes back as garbage
Here’s an example, using the same function:
mesh, _ = cmds.polyCube(sw = 1, sh= 1, sd = 1)
print get_verts(mesh)[:4]
#> [maya.api.OpenMaya.MPoint(-0.50000000000009082, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(0.5, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.5, 0.5, 0.5, 1), maya.api.OpenMaya.MPoint(0.5, 0.5, 0.5, 1)]

# this looks good... Here's the same thing for a 226 vert cube:
mesh, _ = cmds.polyCube(sw = 8, sh= 8, sd = 3)
print get_verts(mesh)[:4]
#> [maya.api.OpenMaya.MPoint(-0.50000000000005185, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.375, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.25, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.125, -0.5, 0.5, 1)]

# but up the vert count to 258:
mesh, _ = cmds.polyCube(sw = 8, sh= 8, sd = 4)
print get_verts(mesh)[:4]
#> [maya.api.OpenMaya.MPoint(5.0277956463997711e-315, 5.0313386899592279e-315, 0.5, 1), maya.api.OpenMaya.MPoint(-0.375, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.25, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.125, -0.5, 0.5, 1)]

# that first point is gibberish: python can't go to the -315th power!
I’ll leave it to wiser heads to figure out why it works out like this. My guess is that something is borked in pointer math going on inside the wrapper around MfnMesh, but I don’t know. Luckily, there’s a workaround: if you create new MPoints out of the items coming back from the GetPoints() call, you get good data. I’m not sure why but this should be so but it appears to be reliable on my machine (Windows 7, 64 bit maya 2015). Here’s the workaround:
def safe_get_verts(mesh):
mobj = api.MGlobal.getSelectionListByName(mesh).getDagPath(0)
mfn_mesh = api.MFnMesh(mobj)
vert_array = mfn_mesh.getPoints()
return [api.MPoint(i) for i in vert_array] # creating new MPoints fixes the issue

mesh, _ = cmds.polyCube(sw = 10, sh= 10, sd = 10)
print safe_get_verts(mesh)[:4]
#> [maya.api.OpenMaya.MPoint(-0.5, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.40000000596046448, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.30000001192092896, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.20000001788139343, -0.5, 0.5, 1)]

by Steve Theodore (noreply@blogger.com) at March 28, 2015 04:20 AM


March 24, 2015

Yet another 'dorito' tutorial

Hi folks,

Last night I captured this short video on how to recreate the famous 'dorito' setup in Autodesk Maya.

In case you are not familiar with the term (it's mainly a Softimage lingo), it simply refers to a way of spliting the skinning deformation into different layers, where each layer rides on top of the previous one avoiding double transformations.

The technique itself is nothing new and there are several videos explaining how to do it in different softwares, but looks like the Maya approach is a bit convoluted and I wanted to share a straight forward way to do it without any rants on how good or bad Maya workflow is.

Hope you like it,

Cheers!

by Cesar Saez at March 24, 2015 03:00 AM


March 23, 2015

Book Review: Learning C++ by Creating Games with UE4


    The past week I’ve pretty much jumped into UE4 programming feet first with my boots on, and I gotta say it’s been pretty fun. As I mentioned on twitter, good on Epic for providing a great UX for developers, so often people tend to think UX only applies to non-code content creators and end users, but as a someone who spends most of his time writing code, having a smooth flow from IDE to Build is awesome, especially given the fact that with something like UE4, it’s not just as simple as hitting the build button and clicking “Start Debugging” (although, with UE4 it actually is, which is a monumental feat). Props to Celia Hodent and the rest of the Epic UX crew, next time you guys are in the bay area, drinks on me.

    I have to say it hasn’t been lack of wanting that’s kept me out of UE4 up ‘till now, I was excited as anyone to get started last year, it’s been more due to a lack of available resources coupled with lack of available learning time. Seems the universe is doing that thing where it gently nudges me in a direction again though, and as I’ve had some projects come up at work recently that are less research and more production (and also require a high degree of shiny), combined with the aforementioned availability of resources, it seems like the perfect time to dive in. Sadly, I can’t give any specifics on what I’m working on just yet, but let’s just say...Good Hunting.


...and UE4 is definitely good at shiny. (Atlantis by Allegorithmic)

    To set some context for my review - In my search for learning resources, there were some specific “filter settings” I applied:
  1. Having prior C++ knowledge, I didn’t want something that focused too much on the basics of C++. Ideally, I’d like a “UE4 Programming for C++ Programmers” type of thing.
  2. I didn’t want something that focused too much on Blueprints other than how to implement custom Blueprints. I’ve seen quite a few tutorials that promise to teach UE4 programming but only touch on C++ just enough to get you into Blueprints, then all the actual heavy lifting is done in Blueprints, even thought it could be done in C++. I need to be “close to the metal,” as the kids say.
  3. I also didn’t want something that only focused on implementing gameplay features. I know that’s a tall order since it’s a game engine (and hey, I was a tech artist for 10 years, I know tools development and the like isn’t sexy), but ideally I’d also like to learn how to implement lower order functionality, say Blueprints for utility functions or how to wrap external libraries for use in UE4.
    Of course, since I’ve only been able to find this one book on UE4 C++ Programming, this criteria may be moot, although I just got wind of another text coming out end of next month, and though I’m not totally sanguine on paying college textbook prices anymore, I'll definitely be giving it the once over as well. Getting back on topic though, how does Learning C++ by Creating Games with UE4 stack up to my scrutiny?

    Given my first criterion, I can’t comment on the first seven chapters, but even if I could, I probably wouldn’t. One of my personal beliefs (validated through experience, mind you), is that using a tool like UE4 to teach a programming language isn’t the best approach, there are just too many other topics to contend with. Definitely not a knock on UE4, I mean, if I were going to teach someone C#, I wouldn’t use something like Unity either (for reasons I may detail in another blog post).


...pretty, but all that shiny can be distractive and not quite conducive to learning to code

    So how about actually teaching UE4 programming? Well, I have to say it does a pretty good job of that, but until the next revision comes out, I definitely recommend having google and the Official Unreal Engine docs on hand. Already much of the code in the book relies on deprecated functions and paradigms, which can cause a bit of confusion on initial read and also results in build errors. No knock on the book or UE4, it should certainly be expected that the APIs are going to change, and I would advise any other author and publisher to consider any UE4 text a living document and make sure to stay on top of errata and keep the code updated. That aside, the programming projects start from a good place and progress very well. Additionally, the author provides short learning projects for the reader to implement on their own which build on the currently presented topic. Personally, I spent about 4 hours going through some of those learning projects and exploring other features, so you can definitely use these as jumping off points for other exploration. And yes, there is some Blueprint work, but only so much as necessary to get the code accessible from the editor and to teach basic workflow, so you’ll definitely be self-sufficient after working through this text.

    Sadly, the book does focus purely on implementing gameplay features, but as I stated earlier, I can’t knock the author or publisher too much for that. I have to imagine that the majority of readers who come to this text will be more interested in creating gameplay features as opposed to plug-ins or other tools, but as the APIs tend to follow common patterns and conventions, branching out into other sorts of UE4 programming tasks shouldn’t be too hard from this foundation (hopefully once the plug-in framework crystallizes a bit!).


...and there's plenty of plugin source available, so you're in good...err, hands.

    Hopefully you can gather that my overall impression of this text is positive, but there are a few things I found a bit off, though none of them are showstoppers, at least not for an experienced C++ developer. The in-line code snippets tend to gloss over a few points, things like declaring things public vs private, including headers where necessary, and other little things that, again, for an experienced C++ developer won’t provide any roadblocks, but if you're just learning C++ and have some of the first time jitters (which is to be expected!), these oversights may cause some frustrations. I think there was also a bit of a missed opportunity with Chapter 9: Templates and Commonly Used Containers. This chapter touches on array types and gives a comparison to STL types, which is valuable, but reads a bit out of place. In my opinion, this discussion would’ve been better in the first section on basic C++, which would have allowed for this chapter to provide some more UE4 specific projects and code samples showing how to work with the T* container types. Just a small thought, again, not a total showstopper.

    I guess what I’ll say is that if you’re an experienced C++ developer and you want something light that you can just work through in a weekend or so and feel comfortable in UE4, this is a great choice. Between this and the official documentation, you’ll find yourself in a good position to strike out into your own projects, whatever they be. Based on the review criteria and my own perspective as outlined earlier, I don’t know if I would recommend this to someone who was wanting to learn C++ and UE4, but like I said, I wouldn’t recommend someone learn C++ through a large content creation framework anyway. My impression based on skimming through the first seven chapters is that it teaches you enough to be comfortable working in UE4, but I don’t know that it’s going to make you a competent C++ programmer, granted that's something that only really comes from practice, but having a good solid foundation is also key. To its credit, this book will definitely give you a good foundation in modern programming basics, but C++ is a vast topic that requires some specific discussions. I would recommend instead something along the lines of the tutorials found at Cprogramming.com, LearnCPP.com, and/or CPlusPlus.com. I don’t say these things out of elitism or snobbery, it's just that since UE4 now gives you access to the FULL engine source, I think it’s really worth learning C++ properly so you can take advantage of that fact. Who knows, you too may find yourself with an opportunity to push the engine outside of its original sandbox, why not be ready to rise to the occasion?

Overall, 7 out of 10

by Seth Gibson (noreply@blogger.com) at March 23, 2015 05:48 PM


March 18, 2015

Markdown Wrapup

A while back I blogged about how much I longed for a good Markdown based blogging platform. Since a couple of people inquired about how that’s gone, I thought I’d mention my (meager) findings since then.



There are several different ways you could get Markdown-based onto a blog:
Static site generators
I looked at a number of static generators, like Gollum from github and Nikola. Both of these were conceptually appealing, but suffered from similar issues, most notably the usual run of configuration and install issues the come with any web-world endeavor these days. I had a hell of time getting either one working install on the macbook I use for most of my writing and eventually decided that I wasn’t that interested in wrestling with those kind of things into the future. More importantly, I’m too busy to really admin my own server - I want a hosted service. If you’re more into running your own server – and you don’t mind sleuthing out things like getting the right Ruby package manager setup running – they could both work fine.
Markdown-based blogs
There are a few markdown based blogging hosts out there. The one I looked at most carefully was Silvrback, and I enjoyed it a good deal. The writing was clean and simple and it came with a built-in syntax highlighting: the biggest damn hassle about all these posts has been getting the code samples into a reasonable format without hopping around between multiple sites and pasting a lot of esoteric formatting codes in HTML by hand. So, I had a good experience with Silvrback and I seriously considered switching. If you’re just getting started it’s definitely worth a look, particulary for technical blogs like this one.
silverback
Custom markdown
The last option would be trying to take control of the markdown to HTML conversion process and spit out a minimal set of HTML that would play nice with Blogger but need no hand-work to make it pretty (you’ll recall that I bitched about my earlier efforts getting bogged down in <p/> vs <br/> and other HTML nonsense I don’t want to think about. There are lots of Markdown generators out there at varying levels of sophistication, but I also don’t want to think too much about micromanaging those.
After a few bouts of intense googling, I ended deciding to stick with Blogger for two reasons. First, I didn’t see an obvious way to port my old stuff – more than a hundred posts with all sorts of special formatting and so on – and I felt it would be bad for the site to be split across two hosts. Also, I worried about losing readers if I switched URLs (if I do this again, I’m going to set up a custom domain early so people know the site by a redirect I can switch at will!). I will admit that I also wondered if using Google for hosting has anything to do with search results - I’ve noticed that a significant portion of traffic comes through Google searches and I wonder if other hosts are quite as well covered by whatever magic algorithm Google uses.
Sticking with Blogger for hosting means figuring out to reconcile my markdown text and Blogger’s style sheets. Luckily, it turns out that Sublime Text has a nicely configurable Markdown preview plugin. I love Sublime anyway – it’s my go-to text editor for everything except heavy-duty C# and Python (VS and PyCharm, respectively, btw).
In ordinary use, MarkdownPreview “bakes” your Markdown info nicely formatted HTML with all sorts of swanky CSS formatting – which is precisely what makes things hard for Blogger. With a little extra work, however, you can get it to produce a stripped-down HTML with the right tags and links but without all the extra CSS that conflicts with the Blogger template.
It took a bunch of fiddling to figure out how it works, but once I got over the n00bishness it turns out to be very simple. Here’s a step-by-step to setting it up for yourself.

1. Install the MarkdownEditing and MarkdownPreview packages for Sublime Text.

This is pretty simple using Sublime’s excellent Package Manager, so I’ll skip the details (here’s some help if you need it.)

2. Create a simplified HTML template

You want to make a simple HTML template that Sublime can render Markdown into. You can add some customisations if you like but the main business of the template is to prevent MarkdownPreview from filling in all of it’s own CSS styles.
Luckily, it’s easy to do this: if you don’t add a placeholder for the HTML <head> tag, MardownPreview can’t stick all the styles in there. This means you can force Sublime to give you a stripped-down output that won’t override your Blogger template.
If all you want to do is get uncluttered HTML, you can just use
{{ Body }}
as your template. That will let you past your Markdown HTML into blogger while keeping your Blogger theme intact.
Since I do a lot of code samnples in this blog, I opted to include a little bit of custom CSS to pretty it up. MarkdownPreview uses Pygments to generate highlighted code. Pygments marks up the html with a bunch of custom HTML classes for different language parts, and you just need to provide some CSS that will decorate those guys. There are plenty of examples that work with Pygments which you can cut-and-paste like this set from Rich Leland.
For myself, I grabbed a free one that looked a lot like the highlighting style on Github – to keep my template simple I put it in a public folder on DropBox and used an HTML link to include it in the blog. Feel free to use it if you’d like, but don’t link to it: I may keep fiddling with it and you don’t want my changes!. You can also get it here
<head>
<link rel="stylesheet" title="github" href="https://dl.dropboxusercontent.com/u/2977490/github.css">
</head>
{{ BODY }}
The dropbox files contains the CSS styles for highlighting code, but none of the zillions of other styles that usually come out of the Markdown > HTML translation. This way, my Blogger template will control the appearance of everything and keep the general style of the blog – but the code coming out of Markdown will be highlighted. Plus, I can tweak old entries by just changing the shared file. One caution: Blogger is finicky about which links it will allow in the head tag: I would rather have linked to the Gists or a CSS file on github, but wasn’t able to get that to work.

3. Customize the MarkdownPreview package.

Open up the user settings for MarkdownPreview (Package Settings > Markdown Preview > Settings – User). This will be a blank file the first time you open it, but like all Sublime settings files it’s a JSON file. We just need to tell the MarkdownPreview plugin to use our template:
{
"enable_highlight" : true,
"enable_pygments" : true,
"html_template" : "C:/path/to/blog_template.html",
"skip_default_stylesheet": true
}
The key thing values here are the html_template, which is the path to the template file from step 2, and skip_default_stylesheet, which tells MarkdownPreview not to insert all those other styles.

4. Build your blog!

With the template and settings in place, create some Markdown. In Sublime, generating the HTML uses the same ‘build’ model as compiling code. So you first set the build system to Markdown (Tools > Build System > Markdown). Then you build it (CMD + B or Tools > Build), which by default will create an HTML file alongside your markdown file. You can view the results in a browser directly or just open the HTML file in Sublime.
What you should have at this point is nicely formed HTML without tons of extra CSS (and, if you added code-highlight styles, some colorful highlited text as well). You can just cut the HTML and paste it straight into the HTML view in Blogger and you should have a perfect, Blogger friendly but Markdown-clean and easy blog entry. Once you’ve done the setup steps once, your only job is a single cut-and-paste (you can even configure MarkdownPreview to copy the HTML to the clipboard instead of writing to a file!).

Wrapup

This is not the perfect blogging system, by a long shot – but it’s a whole lot better than Blogger’s slow GUI, and it offers flexible code highlighting for all of the languages that Pygments supports. Once all the spadework is done, posting is as simple as writing in Markdown, hitting the build button, then pasting into Blogger. So far I’m finding it a huge improvement.
But of course, TA’s are never satisfied so I bet this will come up again some other time…

by Steve Theodore (noreply@blogger.com) at March 18, 2015 06:47 AM


March 17, 2015

You kids get offa my lawn!

I didn't get a chance to go to the GDC panel on ageism this year, but it's definitely a topic that I've thought about a lot as I've gradually metamorphosed into an  old codger.  Seeing the panel and related articles reminded me of one of the very first columns I wrote for Game Developer, all the way back in 2004 when my back didn't make those bizarre noises every time I bend over.

Some of the observations here are a bit dated -- most notably, the article is pretty optimistic about the options for climbing the corporate ladder, since it was written at a time when team sizes and big mega-game-conglomerates were growing instead of looking increasingly rare.  However the problems seem to be very much alive today.  As somebody with very talented and accomplished friends who've fallen off the industry tightrope in their 40's and early 50's I can attest that the problems are real.

Never Hire Anyone Over 30


Lately the games business has come to remind me of the glitzy shopping mall / utopia in Logan's Run. (Even your references have got cobwebs on them, old man! -- Ed.)  It's a fabulous playground for young people  - though to be fair games biz is short on free love and polyester unitards – and we've all got blinking crystals in our palms, ticking away inexorably towards extinction. While we may not be facing the fiery Carousel at 30, it seems like very few us stay in the business past 35.  Take a look around at your next GDC or IGDA meeting: there will be a lot of pink and blue hair, but not much gray.  As one recruiter I spoke to told me:

“Companies definitely want us [recruiters] to ask a lot of the questions that the law won't let them ask. Age discrimination would be the industry's dirty little secret if somebody would bother to keep it secret.”

The reasons for the demographic skew in games are very complicated. After all, it's not as if the games industry's attitude towards age and experience is dictated by some sinister Young Boys Network.

So, let's start by saying what should be obvious: simpleminded discrimination based on age is stupid and shortsighted. Our industry has always had a lot of adolescent traits – particularly when it comes to deadlines and professionalism – and we'll never grow up if we don't find ways to retain experienced, mature people. That said, it's important to look at some common reasons employers and recruiters give for putting a discount on experienced artists. I'm not defending these attitudes, but you'll need to understand them if you want to manage your career effectively through your thirties  and hopefully beyond.

The price of experience

One obvious handicap that veterans face is cost.  Artists with a lot of titles and long resumes expect to command salaries that reflect their experience. Obviously studios always have one eye on their budgets when making hiring decisions, so this makes changing jobs and chasing raises harder for a vet than for younger, cheaper talents.  In addition, many employers feel old pros will be tougher negotiators than new hires. They are less likely to believe in stock options or bonus packages and more interested in cold cash. Worst of all, from the employer's perspective,  a pro is relatively immune to the glamor of simply being in games. Where a lot of young talent is willing to work for peanuts, just for the chance to be close to the games they love, the romance wears a bit thin when its time to pay for the kids' braces or a new dishwasher.

Does this mean an experienced artist is necessarily a bad bargain for a company? Not at all. But it does mean that an eight or ten year vet needs to be able to tell a potential employer exactly why he or she is worth more money, or deserves more responsibility, than a younger artist with only one or two titles shipped. Like a manufacturer in a high wage area, a veteran artist needs to identify the things that he or she can do well, because competing on cost is not an option when you have a family and a mortgage.

Fire in the  Belly

We are in the era of the rising star...  Rising stars are hungrier. They don't have a family to feed, they don't have outside commitments and  are able to work longer hours and spend their free time benefiting their career. They observe what others are doing, how they can do it better, and quickly catapult themselves ahead of the pack.
-P,  a games industry recruiter.

The line between investment and gambling is often hard to find. Everyone faced with a hiring decision fantasizes about catching a talented newcomer with great potential but a short  resume – the “Rookie of the Year”  who will come at a big discount and mature into a star performer.  Of course only a fraction of new hires will turn out to be stars, but like all forms of gambling hiring thrives on hope.   Companies yearn for great discoveries they way FPS players bash crates in search of hidden goodies. In a perverse way, this optimism undercuts the what should be a veteran's biggest asset: the same track record that proves you're reliable, hardworking, even very talented also gives a pretty good indication of your future performance -- which might be very good but isn't going to change the industry overnight.  It's easier for a search committee to project the fantasy of brilliant learning, professional growth and whole-hearted devotion on the blank space at the end of short resume.

Moreover the notion of the “rising star” also brings up the question of lifestyle, which may be the most damning liability which veterans face. The movie-montage version of game development (cue cross-fades over empty pizza boxes, empty coffee cups, and bleary animators wincing at the rising sun)  is a young persons game. Room-mates or parents might dislike you coming home from work at 2am, but spouses and kids have a legitimate right to be mad about it. If a company sees potential employees primarily as mythical man-months on legs they're certain to incline towards the young.

In this context, veteran artists need to be able to articulate clearly how they can get as more work done  in a livable 40 or 50 hour week than their gonzo colleagues do in 80. They need to prove to potential bosses that they are more, not less likely to make the milestones than the pizza and coffee crowd.  The key to effectively dealing with employer preconceptions is understanding what employers want  -- productivity --  and being showing how  you can deliver without last minute heroics. Producers may like man-hours, but they really love reliable scheduling and completed assets.

Keeping up with the times


When I was 25 I'd stay up till 3 or 4 in the morning just  playing with the new features in the latest version of Max, doing little side projects. Nowadays, between meeting my deadlines at work and having a family life, I don't have the time or, frankly, the interest to check out anything new. I know I'm in danger of falling behind, but I've got other priorities. 
- T, an artist, 33.

With the astounding rate of technical progress in our business, obsolescence is a permanent threat. An artist approaching mid career will always have a few painfully acquired skills that have become completely useless. Even worse, the the combination of production pressure in the office and family life at home makes it harder to keep up with new tools and techniques. The stereotype of the older artist with rusting tech skills is not really fair, since an experienced artist can often see through the details of a new tool or idea to the core concept more quickly than a younger person who has read the manual but hasn't learned to really think in 3d. But fair or not, the stereotype is a fact of life that experienced artists have to combat.



The cumulative weight of all these preconceptions makes the professional environment for artists in the decade bracket – the “Children of Doom” who got into games in the early 90's – a tough one. In the early stages of a career, practically the only thing that really counts is a strong body of work– every article on “how to get a job in games” will tell you that a strong demo reel is the magic ticket to games industry success. But when you're a veteran, looking for an appropriately senior job, everybody you're competing with has a strong reel: the 3dSMax fanboys and overly optimistic web designers already been weeded out. Add in a potential employer who is worried about your salary, your commitment to the job, and your technical skills and the picture seems pretty bleak.


Don't Fear the Reaper


Against this backdrop the best thing you can do for your career is to understand how you look to potential employers. In effect, your career is a product, and every time you go looking for a job – within your current company or at a new one – you're doing marketing. We tend to snicker (or worse) when the word marketing comes up, but it's a fact of life for anybody who wants to sell anything. You wont sell much if you don't know what people want to buy,or what you have to sell.

Emotionally this is often a difficult leap for artists to make – we put so much of ourselves into our work that we're offended when people take our creative skills as a given and want to talk about how we “contribute to the team” or “drive the product.”  Unfortunately only a small fraction of us will be hired for our artistic genius or personal creative vision. Far more of us really are there to contribute to the team and drive the product. To manage our careers effectively, we need to understand how we fit into the complex machine of game production. In short, we need to market ourselves effectively.

On thing most headhunters will tell you is that their clients – our potential employers --   want solutions to specific problem. It's not enough to go to a studio and say, “I've got this artist who is a really great person and very talented.” What most companies want to hear instead is -- “You need somebody who can manage the pipeline on your upcoming PS3 title, and I've got just the person.” Very few companies have the luxury of hiring solely because an applicant is talented, or has great potential  – what 40 or 50 person studio can support a Xerox PARC or Advanced Technology Group for distracted geniuses?

The problem for us, of course, is that it's very difficult to predict the specific needs of individual companies in advance.  The range of knowledge you need to be a good marketer for yourself is pretty intimidating – you need to be up to date on current and future trends in technology, fads in pop culture that get recycled into game art,  and of course the rise and fall of different studios, in order to manage your career.  This is a good place to plug another old column: Read The Damn Ad

Once you've mastered all of that, you need to build – I hate to have to be this crude about it – a brand for yourself. When you're 25 you can sell yourself on drive and potential. By 35 you have, intentionally or not, shut off some possibilities and embraced others.  Most studios are already subdivided to the point that modelers, animators, texture artists and level designers are seen as mutually exclusive jobs. Within those specialties new sub-specialties are emerging – scripters, character riggers, and shader writers, for example. As each new discipline matures, people who picked it up out of necessity or curiosity will become “experts” -- which is powerful selling point as long as those specialties are in demand. At mid career you have a complex mix of skills which represents most of your value in the eyes of a potential employer. You need to know which ones are in demand and which aren't.  At 25 you're a commodity product, one of the many warm bodies the industry needs to function. At 35 you need to be a specialty item with a narrower market but much higher potential value.



Whether it's a technical or an artistic niche you're looking for, you have to remember that you don't have control over the environment in which you'll be trying to peddle yourself and your skills. If you were a history buff with a fantastic reel of Shermans and Tigers, you'd have had a hard time pitching yourself in 1999, when everyone wanted to build the next Half-Life or Unreal. But after Saving Private Ryan, Medal of Honor and Battlefield 1942 you'd suddenly find yourself a hot commodity. Alas, even if you sat down today to today to master the details of the PanzerKampfWagen IV ausf H., it's probably too late. Something else will have already become the specialite du jour. 

The same problem bedevils technical skills too. If you have a lot of production experience in, say, PS2 environments you've got a leg up relative to somebody who's only done DreamCast games. Yet becoming tagged as a PS2-monkey can one day become a drag on your career, if it ghettoizes you into B-list, end-of-lifecycle titles and keeps you away from cutting edge PS3 or Xbox2 games.  Specialization is a two edged sword, and you need to have an eye on the future as you indulge your passions. You also need to look for assignments that will keep you current with upcoming tech and topics.

The real key to being rewarded for your experience is honesty: the ability to take good hard look in the mirror. Without a realistic sense of your own strengths and weaknesses,  you won't be able to sell yourself. I don't mean weakness in the interview question, “my biggest weakness is I don't know when to stop devoting myself to the company” sense -- this is a sober look at your real skills and personality. If you know what you can do well, you can either find companies that need you, or become good at something they need that flows out of your existing skills. If you don't know what you're not good at, you'll always be competing at a disadvantage without knowing why.

One artist I know, with a track record dating back to VGA era, found his career slowing down because the combination of family life and production pressure made it almost impossible for him to keep up with cutting edge technology. After a lot of soul searching, he accepted the fact that he wasn't going to stay on the bleeding edge any more. He found a job doing interface design, rather than production art; as an “interaction designer” he can still use lessons he learned on a 286 about clear design, user expectations, and the relationship between interface constraints and gameplay. His deep knowledge of how gamers think makes him very good at his new job. Moreover in ten years he'll still be learning and growing, instead of swimming upstream against a continuing flood of technological change.

Going Corporate


Of course, the  classic way to capitalize on experience is to move from line production to management. This is harder for artists than for many other folks -- we tend to be artists precisely because we enjoy making things, and a life spent monkeying with schedules and having meetings is a terrifying thought for a lot of us. It might be easier to seduce us into management if there were management niches to fill --  but  in most studios the career ladder is extremely short. You can become an art lead, and then an art director...  and then you're done and can retire.  Without a lot of intermediate positions it's tough to even know if you have the aptitude or the desire to leading a team.

Unfortunately, the role of Art Director is often a dubious reward for success as a production artist. The the key skills of an AD – communications, personnel management, transmitting a shared vision and getting people to collaborate on realizing it – are only tangentially related to the technical skills that make a great production artist. The notion that Art Direction is a “level up” in the great games industry RPG is a source of unhappiness and frustration for many.  If you do have people skills, though, you may find that not only art direction, but even becoming a producer or studio head is the best place to spend your second decade in games. Your artistic judgment will still be necessary, but you'll be free all nighters and carpal tunnel syndrome and all the year's you've spent watching games and games people will be a big asset to your work.

Keep on keepin' on


Many of us, though, just want to keep on doing the work we love. It's always possible to keep beavering away, perfecting our craft and (hopefully) being rewarded for our skills and vision. Hopefully the tactics and observations we've sketched out here will at least help dedicated artists to remain well paid and well respected in their work even if there is no corporate ladder for them to climb.

In the Golden Age of Hollywood, craft specialists like cinematographers, set designers and effects people hardly ever made the jump to management either as directors or producers. However they did have their own parallel status hierarchy, in the form of professional societies and particularly the Oscars, which gave meaning and shape to careers that topped out, in terms of money and job titles, when you were 35 or 40.  Our industry would certainly benefit if we could have a similar level of professional respect and community, in which we could recognize and applaud each other's work. How many game artists work do you actually know? Can you put an artists name on a particular character or environment? If you read Jason Rubin's manifesto in the May GDMag, you know how much studios and developers need to work to promote their professional profiles. We need to do the same thing – to form a network that recognizes and rewards talent and expertise in our medium. That would be a benefit for all of us, old fogeys, young rebels and everybody in between.






by Steve Theodore (noreply@blogger.com) at March 17, 2015 02:05 AM


March 14, 2015

Site updates

I've finally gotten around to re-hosting the slides from the Character Rigger's Cookbook talk.  You can also get the original audio on the GDC Vault.



For the tiny handfull of you how were using my Unity course notes, I'm in the process of moving them to a new host.  So the old link at theodox.com is no longer correct (if you follow it you'll get a work-in-progress page; I'm experimenting with a cool new markdown based wiki that is much nicer than the old one at tryscribble.com, but I have yet to make 'real' pages).  I'll announce it here when they go live again.

While moving things around I also added redirect so you can find this blog at blog.theodox.com as well as the usual blogspot link. 

by Steve Theodore (noreply@blogger.com) at March 14, 2015 11:22 PM