Publishing and Programming

If you haven't seen the November issue of Game Developer Magazine, you might want to check it out! There's a really awesome article called "The Game Entity" that talks about... game entities, how they're constructed, and many pitfalls developers tend to fall into. Not being overly familiar with main loops and game engines and hardcore multi-thread memory problems, there were a few points that needed some google-fu. Still, I found it very informative (and co-workers who are familiar with these things enjoyed it immensely!) This one is appropriate for all audiences.

Oh, also: I wrote a Tool Box review of Autodesk Maya 2012!

It's my first published work as a game professional, which is incredibly exciting! The folks over at GD were very helpful through-out the whole process and I'm really happy with how it came out. I'm not allowed to re-post it here yet, but please do check it out in magazine form. (Edit: considering it's been 4 years and it's online in PDF form... link above) Not to spoil anything, but I get a couple good jabs in there about Autodesk's appetite for early releases and hot-fixes.

My team is talking about adopting Google's 20 percent time concept, which is also exciting. The concept is, since most sprint planning and retrospective days turn our schedules into meeting Swiss cheese anyway, we should take those days to work on personal projects. This allows us to expand our skills, kill a few bugs, increase team bonding, implement a few small nifty-but-not-essential features, and generally become 20% cooler.

My time will probably be spent continuing to learn C++ and C#. I am rediscovering C++ syntax (it's been a while) and am remembering all the crazy shenanigans it gets up to. Yesterday I wrote a list class as a refresher; I will not tell you how many times I tried to run and said, "oh, right, I need a blank .cpp for this header," or, "I guess it's not really going to error... it thinks that variable is out of scope, but visual studio is just lying." A couple engineers on our team have volunteered to help lead this effort (much thanks!), the whole tech art team is pilling in, and it's going to be a party.

I believe the ability to learn can be improved with practice. It's a key component of mental fitness to constantly try new things, especially subjects alien to your core studies. I want to see more developers learning new languages, singing opera, watching documentaries, taking sailing lessons, playing rugby, or learning instruments. It may even feed back into your core discipline! You may see something new about water physics while fishing or learn more about AI through paintball. That mental flexibility will give you tons of value and insight you would have never found at work.

Honestly, though, that's not even the big win. I don't care if my capoeira classes ever further my career or give new insights into animation. The big win is in living a richer life and feeling like every day has something unique in it. I love drawing connections between things when it's not even useful. Today Troy was showing me a new auto-attack particle for a champion; The only thing I could think of was, "that flash and smoke trail looks just like the mini-sonic-boom a pistol shrimp makes."

And that's not useful. That's just cool.

Level Up + Force Multiplying

Hello internet,

First, personal news: it's been a good week! I'm excited to say that, after finally receiving my yearly review, I've been officially stripped of my junior status. My title has evolved from "Associate Technical Animator" to simply "Technical Artist," indicating an increased range of responsibilities and influence within Riot Games. Huzzah! I'm very honored and excited to move forward with my team as we continue to improve our tools and pipeline. It's going to be rad.

During my review, one of the points Riot underlined for me was the importance of being a force multiplier. For those unfamiliar with the phrase, essentially it speaks to the value of teaching and enabling those around you to be more effective. Providing better tools, teaching new methods, improving communication, or simply increasing morale are all forms of force multiplication. To me, it is the core principle of tech art.

Last year, I was in a much different place at Riot. At the time, most of my work was related to hooking up new character rigs and skins. I was also responsible for creating dynamic poses for the characters, as we used these for reference when crating splash art. We had about seven character skins coming out per patch, so this represented a large chunk of my work velocity. It was difficult for me to do this work and simultaneously undertake tools initiatives or otherwise improve the pipeline. I was also a bottleneck: splash artists and QA depended on me finishing these characters before their work could begin.

Two important things happened: first, we sought to train others on the animation team to do these tasks. Sharing knowledge and responsibility made us more flexible. Second, we challenged the process. We experimented with outsourcing and creating other ways to generate poses that didn't rely on the animation team. Ultimately, we found that while some concepts might benefit from 3D poses for reference, many worked well (or even better) free-hand. By reducing the number of cross-team dependencies and increasing the number of routes to achieve our goal, the pain point almost entirely disappeared.

This is just one example, but it speaks to a philosophy. Whatever your work may be, continue to ask the question: "What is more difficult than it needs to be?" Where can we reduce dependencies? How can we share knowledge? What happens to your production if you get hit by a bus? As counter-intuitive as it may seem, you actually want to make yourself obsolete. Remember: if you want to be promoted, the best strategy is to train your replacement. Until you do, you are stuck.

Cheers.