I've started this blog over a year and a half ago, but I never really explained where it takes its name from.
So what's a technical game designer then? The short and simple answer would be "a designer who can code". However, that would be inaccurate and incomplete, so let's look at the long answer.
DISCLAIMER: This is a personal take on a position I happen to occupy. In no way it is meant to be a universal definition.
The history
Not so long ago (let's say the previous generation of consoles), artists and animators would usually be responsible for every part of the asset they were making, i.e. an artist would be in charge of the the modeling, the texturing, but also making the material. An animator would be creating the skeleton for a character, do the skinning as well as authoring the animations themselves.
Then, there would be some people better at that kind of (less creative) thing than others. So they would tend to become specialists, but that was still quite informal.
Circa 2005, the new generation of consoles was just around the corner. With the democratisation of shaders, motion capture for in-game animation and the like, content pipelines became increasingly complex. The demand for those shading, rigging specialists was then growing, as the goal was to have the artists and animators not worry about those nearly administrative processes, so they could focus on what they're really good at: making beautiful art assets, and stunning animations. At some point, the industry decided to give those specialists a name: Technical Artists.
As today's AAA games take a lot of time and people to be made, quick iteration becomes increasingly important. Iteration on gameplay involves giving more power to designers (more and more advanced scripting tools, game entities broken down into components that can be assembled like a Lego set, templates to define behaviours and properties, etc.). However, much like artists, there are some people more comfortable with that hands-on aspect than others.
Following the same pattern (albeit one step behind), there is an increasing demand for designers who are capable of harnessing that power, allowing level designers and gameplay designers to focus on what they're good at: making compelling game experiences. These guys are the Technical Designers.
One of the most important skills of a TD is the ability not only to talk to people from another department (code, art, animation, audio), but actually understand what they're on about, speak the same language. This implies having knowledge of how the others work.
For instance, a TD working with animators would know the animation pipeline as well as they do. This has two advantages: they know not to ask unreasonable requests (or how to turn an unreasonable request into a reasonable one), and they tend to know when they're fed BS about what can and can't be done (which does happen sometimes) A TD working with a gameplay programmer is able to give clear briefs about the inner workings of a system: what are the different situations, what should be exposed to designers for tweaking, and in which format.
Empathy is another important skill for a TD. They must remember that they are not working for themselves but for the other designers, which are the reason why TDs exist. When requesting functionality to gameplay/tool programmers, they must think about their accessibility to non-technical people. Also, when defining pipeline for authoring game mechanic related content, they must keep in mind that the data should be as straightforward to create as possible for artists and animators.
TDs are usually good system designers, and they have the foresight to implement generic systems in a future-proof way, anticipating changes in design.
The first and the last point tend to be the source of a never ending (but hopefully healthy) argument between designers and programmers where the former would fight for features that you can easily iterate upon, that don't require script duplication or that can be extended without additional code support, and the latter would try to minimise the amount of work that doesn't have a short-term positive impact on the project (the infamous "let's not fix something that isn't broken (yet)" or its variant "let's not try to solve a problem that may not exist").
Letting technical designers extend functionality is another potential point of friction with programmers, as the former can very easily push the existing systems to their limits, and then request that little bit more functionality to achieve that thing people thought wasn't possible without putting a programmer full-time on the job. Or what I call "implement a feature using an existing system that wasn't exactly meant to be used that way, and tell them to make it work".
However, that technical creativity is a double-edged sword. While it's obviously nice to make new stuff without requiring a coder's help, over-delivering features may let leads and executives think that the code base and/or the tool set are sufficient to get the job done, disregarding the fact that you just used a massive hack that wouldn't work as well in other situations (they don't know about that, they only see the result).
In the end, the whole point of having technical designers is to relieve gameplay programmers of some of their workload, and make level designers worry-free when it comes to repeatable mechanics. That's why TDs must be able to determine when something can be manageable in script, and when it should really be handled in code.
Then, there would be some people better at that kind of (less creative) thing than others. So they would tend to become specialists, but that was still quite informal.
Circa 2005, the new generation of consoles was just around the corner. With the democratisation of shaders, motion capture for in-game animation and the like, content pipelines became increasingly complex. The demand for those shading, rigging specialists was then growing, as the goal was to have the artists and animators not worry about those nearly administrative processes, so they could focus on what they're really good at: making beautiful art assets, and stunning animations. At some point, the industry decided to give those specialists a name: Technical Artists.
As today's AAA games take a lot of time and people to be made, quick iteration becomes increasingly important. Iteration on gameplay involves giving more power to designers (more and more advanced scripting tools, game entities broken down into components that can be assembled like a Lego set, templates to define behaviours and properties, etc.). However, much like artists, there are some people more comfortable with that hands-on aspect than others.
Following the same pattern (albeit one step behind), there is an increasing demand for designers who are capable of harnessing that power, allowing level designers and gameplay designers to focus on what they're good at: making compelling game experiences. These guys are the Technical Designers.
The background
First and foremost, technical designers (TDs) are proper, full-fledged game designers (or at the very least they should be, in my view). On top of that they happen to have technical skills, as the job title suggests. "Technical skills" is a bit vague, but most of the time, technical designers tend to have been either former programmers or very good level scripters. Technical artists can also make good technical designers. Case in point, at Epic Games, an artist made the iOS Jazz Jackrabbit tutorial, and it was a tech artist who made the Unreal Engine 4 editor presentation.The skills
Being designers, TDs are aware of and appreciate design concerns such as player experience, usability, rhythm, replayability, etc.One of the most important skills of a TD is the ability not only to talk to people from another department (code, art, animation, audio), but actually understand what they're on about, speak the same language. This implies having knowledge of how the others work.
For instance, a TD working with animators would know the animation pipeline as well as they do. This has two advantages: they know not to ask unreasonable requests (or how to turn an unreasonable request into a reasonable one), and they tend to know when they're fed BS about what can and can't be done (which does happen sometimes) A TD working with a gameplay programmer is able to give clear briefs about the inner workings of a system: what are the different situations, what should be exposed to designers for tweaking, and in which format.
Empathy is another important skill for a TD. They must remember that they are not working for themselves but for the other designers, which are the reason why TDs exist. When requesting functionality to gameplay/tool programmers, they must think about their accessibility to non-technical people. Also, when defining pipeline for authoring game mechanic related content, they must keep in mind that the data should be as straightforward to create as possible for artists and animators.
TDs are usually good system designers, and they have the foresight to implement generic systems in a future-proof way, anticipating changes in design.
The tasks
It obviously depends on the team and the project, but in general, the tasks of a technical designer may include:- Establishing with programmers how gameplay related features are implemented, more importantly defining what should be data driven and what shouldn't.
- Feeding back to lead designers on the actual complexity of a feature (from an implementation point of view).
- Creating "bricks of gameplay" that level designers can drop in their levels with little to no tweaking.
- Extending existing functionality using the "tools" (scripting functions) made available by programmers.
The first and the last point tend to be the source of a never ending (but hopefully healthy) argument between designers and programmers where the former would fight for features that you can easily iterate upon, that don't require script duplication or that can be extended without additional code support, and the latter would try to minimise the amount of work that doesn't have a short-term positive impact on the project (the infamous "let's not fix something that isn't broken (yet)" or its variant "let's not try to solve a problem that may not exist").
Letting technical designers extend functionality is another potential point of friction with programmers, as the former can very easily push the existing systems to their limits, and then request that little bit more functionality to achieve that thing people thought wasn't possible without putting a programmer full-time on the job. Or what I call "implement a feature using an existing system that wasn't exactly meant to be used that way, and tell them to make it work".
However, that technical creativity is a double-edged sword. While it's obviously nice to make new stuff without requiring a coder's help, over-delivering features may let leads and executives think that the code base and/or the tool set are sufficient to get the job done, disregarding the fact that you just used a massive hack that wouldn't work as well in other situations (they don't know about that, they only see the result).
In the end, the whole point of having technical designers is to relieve gameplay programmers of some of their workload, and make level designers worry-free when it comes to repeatable mechanics. That's why TDs must be able to determine when something can be manageable in script, and when it should really be handled in code.
No comments:
Post a Comment