This is a repost of my post to the Tiny Hydra blog. To read the original go here.
I’m often asked by my former students, “What skills should I really be learning to get into the industry?” The answer to this question is really complicated, and depends largely on what the person wants to do. However, there are a few jobs that are very difficult to fill for many companies and if you have an aptitude for these disciplines it can be a great career path for you. This is the second in a series of blogs, each discussing niche positions, what they do, how that varies from studio to studio, and some good ways to get started. Checkout the previous post on Technical Art.
Both Technical Design and Technical Art are services Tiny Hydra offers. If you’re interested in being one of our ‘Hydra Heads’ so you can help studios make better games, take a look at our recruitment page. We’re happy to have new entrants into the industry with demonstrable skills. We make a special effort to train applicants in the soft skills side of working in games, not only the technical aspects of specific disciplines. We also specialize in rapid onboarding and cross-functional collaboration.
For this second article in the series, we will be discussing the Technical Designer role. A little attribution before we continue. Because I have been doing Technical Design for most of my career, I felt like I might have some very strongly held opinions that were not always accurate, so I enlisted the help of my friend Brian Jennings Lead Technical Designer at NZXR, while coming up with ideas for this article, and I want to thank him for his contribution here, especially in coming up with “beginner” Technical Design projects.
What is a Technical Designer?
A Technical Designer is a facilitator, helping to move concepts from ideation to implementation. They serve as a practical bridge between disciplines (design and engineering), and as a professional “unblocker” for the design team.
Where do Technical Designers come from?
I think most Technical Designers come out of design. They tend to be people who got fed up with how tools were working. Most disciplines are driven by questions. The artist asks, “How can I make this look cooler?” The UX Designer asks, “How can I remove a click?” The Game Designer asks, “How can I make this more fun?” (or some variation on those). The Technical Designer asks “How can I make designing this go faster?” If you often find yourself asking that same question and motivated to do something about it, then you just might be a good Technical Designer.
Like Technical Art, Technical Design is a discipline in its infancy. There are no programs that I know of (please let me know if you know different), where you can major in Technical Design. And even today, if you’re a designer looking to make tools (or worse, an engineer looking to make the design team’s life easier), it might be an uphill battle to convince your team your time would be better spent on that than something else. You might even be told to, “Stay in your lane.”
There are actually a fair number of barriers to entry to Technical Design. While Technical Art is getting to be pretty well understood by most people in the industry these days, as of the time of writing this article Technical Design is still not as common at studios, or the value is not as well understood. Part of the problem is, when some people see you moving outside of what they consider to be “your role” they tend to get a bit uncomfortable. Other people might feel threatened, like you are encroaching on their territory. And so, artificial barriers to entry have been set up around roles like Technical Design. Usually, you can get past these just by showing the value of what you’re trying to do. But, that may require you to do work on your own time to sell your ideas, and it doesn’t always work out.
So, where do Technical Designers come from? Most of the time they come out of Design. People with an aptitude and a desire to solve problems. They can also come out of Technical Art. Often Technical Artists find themselves asked to build tools to facilitate solving design problems, and eventually have so much knowledge of an engine and the design processes they are working with that they become the go-to person for technical design tasks. Sometimes, it’s an engineer with a propensity for design and a desire to make tools or rapid prototype ideas.
What do Technical Designers do?
Here’s a one-sentence definition: A Technical Designer is a Designer who can create functions for their game’s high-level scripting language, or creates interfaces/tools for design.
The answer here is a bit more straightforward than with Technical Art. Okay maybe it’s a byte more straightforward, but still not much more (look Mom, I haz programmer jokes). In fact, Technical Designers do many of the same things as Technical Artists but just from a different perspective.
One of the most common functions of a Technical Designer is building tools for designers. If you are totally new to the concept of Technical Design, you might wonder what that means. Well, it can mean a lot of things: It could mean creating two-way communication between a game engine and the spreadsheets that System Designers work out of. It could mean building a way to procedurally generate game objects based on a set of criteria. Or, it might mean creating widgets/gizmos/brushes/ or other interfaces to make level design quicker and easier. The breadth and depth of tools a Technical Designer can create are really only limited by the imagination, what’s possible with the latest hardware, and the development skills of the Technical Designer .
Technical Designers might also be the person tasked with rapid prototyping ideas, and might not make tools at all. They explore game mechanics and systems by making a lot of quick and dirty minimum playable experience (more on this in a future blog post, I promise). These prototypes can be tested and used to discover what’s fun and engaging so the team can focus their efforts on what will make the game compelling to users. This side of Technical Design means throwing away a lot of your work when it doesn’t test well. So if this is the sort of thing you’re interested in, you really need to marry your brain to Jesse Schell’s concept of how to handle ideas:
“Ideas are not like fine china, ideas are like paper cups — they are cheap to manufacture, and when one has holes in it, go get another one.”
It’s the “be willing to kill your darlings” philosophy of game design, and it will probably serve you well no matter what discipline you’re in. But, as a Rapid Prototyping specialist, you will probably be doing this more often than not. So if you are a person who loves exploration and scientific experimentation, and is not super in love with iterating on the same thing for years, until it’s “perfect”, a rapid prototyping specialization might be the right fit for you.
The typical differences between what a Technical Artist does and what a Technical Designer does are the focus (art vs design), and the technologies they tend to work with. This is not always the case mind you. I see more Technical Artists working to facilitate the use of Digital Content Creation (DCC) tools using languages like MEL, MaxScript, Python, and VEX. While I see Technical Designers focused more on extending the in engine functionality and typically using languages like C#, C++ and LUA (yeah creating Blueprints too).
If you can do both (tools and prototyping) then you’re batting a thousand (did I use that right? I know next to nothing about Baseball, but I think that’s the right idiom), and should probably start focusing your resume and applications on Technical Design. A general distinction to be made here is that some Technical Designers are programming to support their own creations (high-level gameplay programming and rapid prototyping) and some to facilitate the work of others (tools and pipeline development).
What Should I Be Doing to Become a Technical Designer?
Again, the first answer is: “get good” at math. After that, it really depends on what you want to do. But, there are a few things that will make Technical Design tasks more accessible to you from a high level:
- Learn an object-oriented programming language.
- Don’t Panic!
- If you want to use Unity then (no contest) the choice is C#. But, generally, you should probably learn C++ first (or you know you could learn Objective-C; after all they are both just preprocessors in front of C). Straight up, if you learn C++, you will be far more efficient in Unreal than if you just learn Blueprints.
- If you find C++ (or even C#) overwhelming, you could always start with something like Scratch, which makes the common lessons of programming super approachable.
- If you do want to start with a web development first approach consider JavaScript, it’s a pretty solid intro language. There are even some fun JavaScript based engines out there, like PlayCanvas.
- Whatever you do, don’t waste your time with JAVA (he said, showing his bias). And, don’t be like me, I started object-oriented programming with PHP (back then though I thought I’d be pursuing a career in web development).
- Learn about data structures, serialization, and reading/writing files from your programming language of choice.
- These are subsets of learning to program. But you want to become pretty solid on these as teams will use a ton of different solutions for managing designs, and engineers will have a lot of different opinions on how to best handle data. And you are going to want to marry those two using tools in many cases. Because, you aren’t going to get designers to stop using spreadsheets, and engineers aren’t going to handle a bunch of CSVs when they can demand JSON… You see what I mean?
- Learn about Design with a capital D.
- You should learn Design concepts really well so that you can easily communicate design intent to engineers. Once you can do that, you should have no problem understanding the needs of your design team and solving them yourself (provided you have the programming chops).
- Learn an engine.
- Some people will tell you that once you have a good grasp of a language then you can learn an engine. But it is really about the approach. For me, it was always about getting things done. As a consequence, when I was getting started I tended to learn the basics of the engine first. After that, I learned the basics of the language. Finally, I learned how to use the language in the engine thus increasing my understanding of both by an order of magnitude.
What Makes a Good Technical Designer?
As with so many things, being an effective communicator is really important. Technical Designers are a bridge role that needs to be able to bring Design and Engineering closer. We’ve already talked about how it might be necessary to advocate for the value of Technical Design. Beyond that, as a Technical Designer, you will need to “sell” your prototypes, or tools. Getting good at presenting, showing an ability to empathize with people from other disciplines, and speaking the language of your peers regardless of their focus: all these soft skills will serve you well as a Technical Designer.
You’ve got to be problem focused. You need to demonstrate an ability to identify, and define a problem quickly and work towards implementing a solution.
As a Technical Designer, it is important to be scientific. You need to be test driven, and understand the value of research. Whether you are serving the needs of others on your team by facilitating their work through well designed tools, or creating lots of testable prototypes; being willing and able to gather and act on useful feedback is key to doing strong work.
It also helps to be a bit of a jack/jill of all trades. The technical design position is something of a generalist position. One day you might be putting on a pure design hat, the next doing UX research for something you’re creating, another creating some rough art assets to help convey the idea of a prototype you built. Having at least a working knowledge of things like 3D modeling, digital illustration, VFX, sound design, UI design, etcetera; will help you make stronger work while also allowing you to better understand the needs of your teammates.
Another thing that makes a good Technical Designer is their ability to design. There is no one size fits all way to be a good designer. Some people love to design by taking inspiration from other games and building on that. That’s fine. In fact, there are designers out there who I look up to and that seems like the only thing they do. They play a lot of games, they experiment, and they make. But, imho, the best designs come from personal experiences. In the words of Jess Hider (Technical Game Designer at Rare):
“Hobbies and life experiences are the most important things for a game’s designer, because it means we can pull on first hand experiences, not regurgitate somebody else’s.”
See what I did there? ‘I’m such a hypocrite.’ No, but seriously, this is a perception I have long held and is the reason I have spent my professional life moving around, why I’ve traveled everywhere I can as much as I can, and why I’ve picked up all sorts of hobbies from brewing beer, to snowboarding, to rock climbing, to maker work. So, get out there, so you bring your own life experience to the table in the future.
Where Should I Start?
Like with anything, start small. Try reproducing solutions to problems other people have already solved (without straight up copying). Maybe expand on a game project by making all the settings that drive the experience easy to modify outside the code (accessible at the engine level to non-technical designers). Then move on to bigger game (yeah, you know you like my punz: game like hunting game in the context of a game development blog, hold your nose against my maximum pun-age). You could also try a training site like Code Wars.
Below, I’ve compiled a few projects you can try to get yourself started and explore whether Technical Design might be for you. I want to say that these projects are nontrivial undertakings. In the case of the more advanced projects, many of the things here would take a skilled Technical Designer several days of serious work to accomplish, and are likely to take a novice a much longer period of time (like probably a lot longer). As with anything, practice makes perfect you better.
Getting Started
- Map generation tool.
- Create a project that procedurally generates a map for games that makes use of tiles or hexes (like a 4X or RTS). Can you log your seed and any custom properties for later use? Can you build a tool to take the map you like, load it up, and then change aspects of it? What about being able to change individual tiles (or hexes) via a brush or maybe execute batch changes via a menu?
- Enemy generator.
- Let’s say you have libraries of armor and weapons your enemies can use, and base stat ranges for your enemies with standard modifiers based on their level. Can you build a tool that will generate variations (5, 10, 20, 100) of an enemy with a single click? Can you reference a file to pick any number of these generated enemies and present it in game?
- Quick add tool.
- What if any time you dropped an asset is into a folder it became part of a library of characters that spawn in an environment? Can you use tags in the name of the asset to define properties or assigned behaviors?
More Advanced & Bigger Projects
- Procedural localization tool.
- Make a tool that will search all prefabs in a scene, grab all the text mesh components, throw the text into a spreadsheet, localize it using something like Polyglot, then be able to reference the results and change what’s presented in the game based on a language setting.
- Asset usage lookup tool.
- Click on a project asset with this tool open and see all instances where it is used in the project. The same tool could also search all your assets and find anything that isn’t being used (find assets without references). That would be super useful for cleaning up bigger projects.
Resources
Here are some things you should look at.
- http://blog.cleancoder.com/
- Uncle Bob is a friendly inspiration to all of us. He’s one of the authors of the Agile manifesto and a development historian. Engaging to read and watch, he’ll make better recommendations for things you should check out than I ever could.
- Game Maker’s Toolkit
- A great youtube channel on design and development. Maybe start with versatile verbs.
- http://stonetronix.com/
- Stone Librande is a very smart man who says smart things, mostly about design. Check out his website, I’m especially a big fan of his one page design doc philosophy.
- https://www.redblobgames.com/
- Math and math visualizations that make it more approachable (or at least cool to look at).
- https://unrealslackers.org/
- Unlike Technical Artists who have tech-art.org, Technical Designers do not have a go-to community maintaining an extensive forum and active slack (to my knowledge, please let me know if I am wrong as I would like to join). In lieu of that maybe join this discord, or the next one, or both.
- Side note here, if you happen upon this post and are interested in running a Technical Design group I would be happy to support you, I would start one myself but (as with everyone) I’ve got too much going on already.
- https://discord.me/udc
- Same as above, but for Unity devs.
- http://www.squidi.net/three/
- Three Hundred Mechanics is a project by Sean “Squidi” Howard, and is an interesting exploration of game design and (some) implementation. Worth checking out.
- http://gameprogrammingpatterns.com/
- Not going to skip the about page that offers to sell you this free book, as the author deserves the chance to sell it to you. But it is free, and super useful if you want to go from understanding that programing is just “assignments, if statements, and loops” to understanding how things can be more efficient.
- https://www.habrador.com/
- This collection can be a bit difficult to parse but there is some good stuff there, especially in the Unity tutorials. That said, those aren’t so much tutorials as an explanation followed by a code dump, so don’t skip straight to this stuff.
- https://catlikecoding.com/unity/tutorials/
- There are a lot of good tutorials there, and honestly, there’s something for everyone here from a development perspective.
- Game Design Resources
- A giant workbook with everything from General Design resources, to Tools, to Career advice. It’s a lot to parse but totally worth it.