So yeah. There are lots of fledgling indies out there – two or three man operations, and they don’t necessarily have a background in what a large team makeup is. Who can do what or not.
So I thought, what the heck, I’ll have a go at categorizing them. I intend to split this over several blog posts, one for each discipline.
So lets start with Engineering. You know. The code monkeys. The number pushers.
People like me:)
Engineering used to be just ‘programmers’ but now it’s got several area’s of specialization. It’s important to note that lots of teams combine these positions. There often isn’t a need for a specialized UI engineer, or a dedicated Networking Engineer – are one person may be tasked in lots of different area’s. The differentiation I’m using here would be evident on 30-40 programmer teams, like Bungie or Infinity Ward have. Not your average 30 people team that counts EVERYONE.
We’ll work from the top down, I think.
1) The CTO
This is where the buck stops. This is the guy who is ultimately responsible for all technical decisions made. If something cannot be done, or fails, he’s responsible. He ultimately ratifies all the decisions of those beneath him, and is the guy who says “Yes, we are going to spend $1.5m on an Unreal 4 license”. He does the strategic planning, looks around and says “everyone else is in the cloud, we should be do”. He holds the 5 year plan, and is aware of the industry and what is going in a general sense, and guides the technology plan for the studio at the top most levels.
2) The Technical Director (TD)
This guy has two different modes. The first is a back stop to the lead programmer. He’s not replacing the lead, he’s someone that is an independent verifier of the leads decisions. If the lead says “We need to spend X amount of time on Y system to do task X”, he’s the one who looks at the statements, verifies they are true and that the proposed solution will both fufil the requirements, and is actually do able. He will highlight area’s of risk – and in the worst case, rush in to help firefight if need be.
A TD will often have multiple teams he is working with, but traditionally, they do not report to him – he’s an independent entity.
The second mode is as traveling help for hire. He can and will be able to go anywhere in code and help build / fix / triage as is required. His technical knowledge in general is wide (and deep in some areas) but he’s not specifically tied to one project, working on many at once.
3) The Lead Programmer
The Lead programmer is the guy responsible for getting the game done. He’s the one who makes the plan about how the game will get done, who is going to do it, what the risks are, what outside software / libraries he may want to use to get the job done. He works out the tasks and either delegates himself, or he hands it off to a manager to do it (that’s how EA works). He is the touchstone that all other coders use, and he’s the one who has to know the entire codebase and what goes into it.
He decides coding standards, what the tool chain is going to be, and also manages any outside systems that are used (remote DBs etc).
A lead programmer should be on one project at a time.
4) Technology lead
It’s entirely possible that the engine your game uses is actually owned by another part of the company – a group who’s job it is to build and support shared technology. They don’t make the games, they make the technology that the games sit on. They take requests and tasks from the game teams, who require feature X so they can ship game Y, and implement them in a way that other teams may use that feature too.
There are some specific area’s of technology worth pointing out.
Animation coding is one of those things that is almost solved – once you’ve got the system importing models and animations, and providing an API to blend them, you are done. Except you are not. Next comes the systems that decide _what_ animations you play, why, how long, and how to interrupt them if need be. Add to that the creation of tables to decide how which animations are available for selection, and you’ve got quite a task.
The best way this can be implemented is at a data driven layer – so it’s done by external tools and the code in the engine is entirely generic.
This is a biggie, and there’s a lot of specialization in this area. There’s driver optimization, new features and then shader writing, which is an area of expertise all it’s own.
The bottom line is that adding new features, new ways of rendering and getting visual artifacts is one of the easiest to see upgrades a game can get.
It’s where all the glory code is:)
Networking is interesting, because networking needs to be thought of as part of the initial design of a codebase. You can’t just graft networking on after the fact; you have to be thinking client server architecture from day #1. Networking impacts so many different aspects of how your game engine works, it’s definitely a specialized area.
Audio tends to get relegate to also-ran status when making games, and that’s a shame since there is a ton yet to be done with this area. Correct audio bounce, correct obstruction, biaural processing, waveform distortion, environmental changing, musical beat matching for switching music tracks etc – there’s a lot yet to be solved with audio, but it gets short shifted because for lots of game devs, ‘good enough’ is good enough. The issue comes with gaming rigs with radically different audio properties, and the ability of the listener to even hear the small differences.
If you can get into it though, this will be an area of expansion over the next few years. I hope.
UI (sometimes know as UX, although there is a difference. UI is what the text / menuing / information passing looks like on screen. UX is the flow from page to page – the decision of what info is present to you, and when that happens). This is increasingly becoming a large part of game design, given how complex games can be, and how small a screen you may be providing information on (e.g. Mobile).
Good UI / UX flow can often mean the difference between a good game and a great game.
Tools is often an entirely separate area of the team, complete with it’s own lead. Tools programmers are responsible for creating plugins to existing tools, creating a pipeline to get stuff from content creation tools, like Maya or Photoshop, and into the game in a game (and sometimes platform) specific format.
Tools are one of the biggest area’s of expansion in the last few years. Games often live and die on the quality of their content creation tools. Better tools = better looking and more content for games.
Tools engineers relate directly to content creation parts of the team, often working with them for requirements and what the content creators need tools to actually do for them.
10) Scripters / AI
Interestingly, this group can often be the hardest to hire. You need logical thinkers, who are also content creators. These people are crafting your game at the highest level – using a scripting language that (hopefully) doesn’t have to be compiled. They don’t need Visual Studio on their machine, just a text editor and understanding of how a high level language like C#, python or lua work. You need a programmer who is also a game designer.
For some reason a lot of the people hired for this position tend to be graduates; I’ve no idea why.
11) Pure Game Engineers
These are the guys who *just* make the game. They don’t build technology, they use it. They are like scripters, but in pure C/C++. They create game specific objects, cameras, input systems and create the actual game experience.
These guys have the most iterative job, in that usually their code will get re-written several times over the course of development, as they try things, they don’t work and a new approach is taken.
This is actually one of the most stressful jobs, because code is thrown away so much, and so much of the final product is dependent on their work. They are the equivalent of the Formula 1 driver – everyone else is building the car – these are the guys who actually drive it.
12) Development Support / IT
This is part of team that handles things like build machines – that fire a build of code every hour, or every time something is checked into Perforce. It also builds a test harness, so the game can be run through testing of features every night. Again, this is a heavy investment in time, but in terms of finding issues with features in the game, it’s a gold mine. Coming in in the morning and looking at a webpage of lists of features in the game that are broken, or the fact that the frame rate halved that day due to some check in, is massive.
13) On Team QA
One of the nice things that large teams have is a couple of on team technically competent QA guys. They sit in the corner, look at reported bugs and try running the game through the debugger, so when it crashes, they can come find you, and you can see the crash as it happened in the debugger, with stack trace and all.
To be clear, this is a massive luxury, but if your team can afford it, it can reduce your beta development time (the time at the end of the project, where you ONLY work on bugs, and not on features any more) by almost 50%, since you are fixing crash bugs as you go along.
14) Automatic Testing Engineer
This is something new – an engineer dedicated to writing a test harness, so the game can be automatically built and tested every night, using specific human written tests. This means it can look for reduction in frame rates, crashes, game functions that aren’t according what the design calls for, etc.
This can seriously impact a build’s stability and track when things go wrong, allowing the team to address it immediately.
So there you go. There are more specialties – path finding, facial animation, visual effects coding, and so on, but those tend to be very specific for a specific game. A football game may have a dedicated person to create large crowds, for example, where as a fighting game would not.
So, next post – Art!