Psychochild's Blog

A developer's musings on game development and writing.

11 June, 2016

What is a Technical Designer?

Interviewing takes up a lot of time, especially if you fly across the country for an interview. So, forgive me if I miss a post or two in the next few months.

One thing that I’ve noticed is that the title of “Technical Designer” has been showing up a lot more. As a game designer with a solid technical foundation, this is exciting. So, let me tell you a bit more about Technical Designers and why they are interesting.

Different types of designers

“Game Design” covers a lot of different types of design. Design responsibilities include level layout, game systems, gameplay feel, user interface (UI), narrative design (writing), visual design, and others. Not every designer is adept at each of these areas, just as not every programmer is equally proficient at rendering, networking, server infrastructure. Different people have different focuses and specialties.

Obviously at smaller companies, you expect to have fewer people who do more work. And at larger companies you might have designers who have even finer specializations working on specific parts of the game.

Development assumptions

So what, then, does a Technical Designer do? The Technical Designer stands astride both design and engineering, acting as a bridge between the two groups. This might seem a bit silly at first blush, but it can be an incredibly important role.

Developers bring certain assumptions with them as they develop a game. These assumptions are shaped by the demands of their individual areas. And, as you might have guessed, Engineers and Designers bring different assumptions with them as they develop.

For example, engineering is mostly about trade-offs. The classic programming tradeoff is processor vs. memory. If you want to program a task and have it take less processor time, you can often do that by using more memory, and vice versa. A lot of engineering is about choosing the right trade-offs to make and to the proper extent. This is what the experienced programmer does best.

Designers, particularly those without a technical background, may not understand these tradeoffs. A designer may say he wants “more flexibility” or “more control” from a tool, not understanding that these demands come at some other cost. For example, a more flexible tool may end up being harder to use, following another programming continuum of power vs. ease-of-use.

The rift between disciplines

This misunderstanding leads to problems. Sometimes Designers feel that Engineers are unwilling to give them what they want. And, to be fair, there certainly are passive-aggressive programmers who try to influence by what they agree to work on. But, in many cases the Engineer is making the decisions he or she thinks are necessary. And, since these tradeoffs are second nature to the Engineer, he or she doesn’t think to explain them in depth to the Designer.

This is the same problem that started causing rifts between programming and art. As art assets got more complicated, artists needed more programmer time to accomplish their goals. Some areas of art became incredibly technically demanding, and an artist without a technical foundation was often at the mercy of programmers. Without a shared set of assumptions, this caused problems.

Unfortunately, these misunderstandings often lead to rifts between the design and engineering groups. Designers think programmers are sandbagging, and programmers think that designers are asking for the impossible. This leads to a poor work environment and more obstacles in the way of creating a great game.

The bridge over that rift

And this is where the Technical Designer comes in; he or she needs to understand the design, be able to drill down and understand the specific design goals and then understand the engineering tradeoffs necessary to accomplish these goals. So, when communicating with the Engineers the Technical Designer can understand the underlying assumptions and discuss the tradeoffs with the necessary foundation.

This is similar to how Technical Artists became important previous in the game industry. As I said, art requirements got a lot more technical, so it required Technical Artists to bridge the gap between art and engineering. Often they became specialists in certain tools, such as writing shaders or coding art tool plugins. By combining an understanding of art requirements with technical ability they were able to help both groups work together better; in other words, they could translate the assumptions made by each side so that the other group could understand them.

And, to be clear, designers are hardly technologically illiterate. In fact, most designers need to have some technical savvy in order to work in the game industry. Especially at the smaller companies, a designer who has no technical foundation is probably going to run into troubles as there won’t be enough programmer time to handle every problem that designer will run into. And, using specialized tools, such as level layout tools, takes specialized technical knowledge to get the most out of them.

Still finding a place

The game industry is still working toward understanding how Technical Designers can work best. Technical Designers are some years behind in evolution compared to Technical Artists. This is further complicated since some people harbor grudges against “the other side”. Engineers with bad prior experiences might still think of Designers as impossible to please divas, and Designers who had bad experiences may still see Engineers as passive/aggressive wannabe designers who make their job harder instead of easier.

There’s also a question about how much hands-on work the Technical Designer should do. Should they be contributing to the development of the game, or should they do more oversight? Also, where does a Technical Designer fit within an organization? Are they an Engineer or a Designer? How does this impact their day-to-day work? I suspect in some places Technical Designer might just be a fancy name for “scripter”, even though the role should encompass so much more.

Personally, I’m excited about this position. I hate having to shut down my design side or my engineering side to work on some project. So, the ability to use all my skills is welcome.

What do you think? I’d love to hear your thoughts on what you think about Technical Designers.







No Comments »

Leave a comment

I value your comment and think the discussions are the best part of this blog. However, there's this scourge called comment spam, so I choose to moderate comments rather than giving filthy spammers any advantage.

If this is your first comment, it will be held for moderation and therefore will not show up immediately. I will approve your comment when I can, usually within a day. Comments should eventually be approved if not spam. If your comment doesn't show up and it wasn't spam, send me an email as the spam catchers might have caught it by accident.

Line and paragraph breaks automatic, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Email Subscription

Get posts by email:


Recent Comments

Categories

Search the Blog

Calendar

May 2017
S M T W T F S
« Apr    
 123456
78910111213
14151617181920
21222324252627
28293031  

Meta

Archives

Standard Disclaimer

I speak only for myself, not for any company.

My Book





Information

Around the Internet

Game and Online Developers

Game News Sites

Game Ranters and Discussion

Help for Businesses

Other Fun Stuff

Quiet (aka Dead) Sites

Posts Copyright Brian Green, aka Psychochild. Comments belong to their authors.

Support me and my work on