Before reading, be sure to check out Part One, where we talk about ideas, funding, phases of development, and what designers do.

Who Does What (Continued)

Art

Artists make all the things. Everything in the game was made by artists. A designer might have decided to put the tree over there, but the tree was made by an artist.

While we like to pretend that we use an agile development methodology, art tends to play more by waterfall rules. Design says “we need a hundred different items of clothing,” then art has to plan out how long each item takes, and figure out how to deliver them all in the available time (and if it’s freaking impossible, they need to whine at design until design relents and pares the asset list). So basically, art builds a huge list of tasks and starts grinding away at them.

At the top of the pile is the art director, and finding a good one is damned hard, because they need to do two things. First, they need to be great artists themselves, with the ability to define the look of the project, do ‘draw overs’ on other people’s art to show them how to make it better; and second, they need to be fantastic managers, with the ability to inspire their team and keep them going. Finding either ability is non-trivial, and finding both talents in the same person is golden.

Concept artists can actually draw (something not guaranteed for everyone on the art team). Their work can sometimes be gruelling; as an example, for one character, one of our concept artists drew something like four dozen sketches of the character’s head, exploring different styles and looks. And that’s just the head. First passes get refined until you have a final, approved concept, which then gets passed off to the modelers.

Modelers model and texture 3D assets, and often they’ll specialize in different things: there are character artists, environment artists, and people who like building equipment and props (props being a generic term for just about any item that can appear in-world).

Animators animate characters. And by “character,” we don’t just mean PCs; an animal is a character. A vehicle is a character. Anything that requires animation is a character. This is a much more complex task than most players realize; for instance, in our game, characters can move in eight directions at three different speeds, and animation is required for all possible combinations and for transitions between all possible combinations. And that’s just locomotion; MMOs are famous for social animations. You know the drill. /bow /airkiss /roflmao. Somebody built all those animations. (Well, to be fair, we buy a lot of mocap animations, but they’re always rough and need work; someone at least polished all those animations.)

Technical artists do things I don’t even understand (which is totally fine because they do). They throw around words like shaders and mipmaps and master materials. With help from engineering, they build the pipeline that gets assets out of Maya and all the other tools artists use into the actual game. They do the technical wizardry involved to make sure the things the other artists are building actually look good in the game. One shader to rule them all, and in the correct lighting bind them. Or maybe in the darkness, depending on where you are in the day/night cycle.

Bonus Joke: Q. How many art directors does it take to change a light bulb? A. …Does it have to be a light bulb?

Another Bonus Joke: Q. How many artists does it take to change a light bulb? A. Three. One to model the light bulb, one to texture the light bulb, and one to animate the light bulb changing.

Product

Game designers. Artists. Engineers. All calm, reasonable people who never disagree and take direction well. Consequently, producers have the easiest job at a development studio. Right?

You can stop laughing now.

Here’s how it actually works. Your design team has over-scoped and over-specked, and if there was infinite time (and infinite money), maybe you’ll ship this game sometime in the next decade. (We over-scoped it, by the way, because we know damn well 30% or maybe 50% of the things we want will get killed before we get to beta, so we ask for all the things, hoping we get enough of the things to make a game that’s worth the powder to blow it to hell.)

Your engineering team rabbit-holes (the character controller is fine for now, stop fiddling with it damn it and move onto the next task). They also hate process, and process is your damn job.

Meanwhile, the art team is producing assets that are beautiful, but the textures they’re using are so freaking ginormous the game is running at maybe 3 frames per second on a min-spec machine.

What the producers do is estimate (with help from other disciplines) how long tasks are going to take, prioritize the order in which things get developed, realize that the launch date management wants is crazy talk, and then figure out what gets cut, what gets scaled back, and what we want to deliver at each major milestone (our milestones are 3 months long). At the beginning of each sprint (typically 2 weeks long), they negotiate with the other disciplines about what tasks will get done this sprint (in an agile process, each person has to agree to their tasks and reasonably estimate what they can get done in a sprint). As tasks get accomplished and marked as complete in the task management software, they make sure QA has checked them, and when verified, close them out.

They assign people to strike teams (each focussed on a particular feature), and hold daily stand-up meetings with each team, where each team member checks in and answers three questions: What did you do yesterday, what are you doing today, and is anything blocking you. If the answer to the third question is “yes,” it’s their job to figure out how to unblock that person.

In other words, it’s the job of the production team to make sure the trains run on time. Only there are no trains. There are a bunch of ornery, passionate people who occasionally are at odds with each other. Not to mention that next milestone, design, art, and engineering all have different, conflicting priorities about what they want to make happen, and it’s your job to bash heads together and find some sort of uncomfortable consensus.

Bonus Joke: Q. How many producers does it take to change a light bulb? A. The light bulb isn’t critical path, so don’t expect it before beta.

Engineering

Then we come to the engineers. Poor bloody engineers. Why?

Because they’re at the tag end of the development pipeline. Design is front-loaded; a lot of it gets done up front (and designers always try to be a sprint or more ahead of engineering, so when engineering has questions, designers have answers). When push comes to shove – like, we need this feature now – engineering is the team that takes the stress, and when crunch does happen, they’re the ones that suffer first. (And yes, at Playable Worlds, we try to avoid crunch, which frankly is an indication of poor management, but the reality is that I’ve never been involved in a project where there wasn’t crunch at some point. Good studios make sure it’s a week or two at most, and infrequent.)

Engineers, like designers and artists, tend to specialize. Server-side engineers do all the coding and maintenance of the game servers, which are critical to supporting any online game, and also critical to preventing hacks (never trust the client). They also maintain build automation, client authentication, and a million other things that may be invisible to the players but are key to keeping the game up and live. Which is also why they’re the ones who get automated phone calls at three o’clock in the morning and have to spend hours in the middle of the night fixing some critical issue.

A graphics engineer is responsible for putting pixels on the screen. They take what art gives them and figure out how to make it work in the game. They make the terrain look pretty. They make the water flow like water. They make sure the game doesn’t run at 3 frames per second on a min-spec machine.

A client engineer works on core code for the game client. They figure out how to get stuff from the server, and how to use it in the build. They figure out how players control characters, and critters control themselves.

A gameplay engineer codes actual game systems. Crafting, combat, whatever it is, it was a gameplay engineer who made it.

A tools engineer makes tools for designers, artists, and other engineers to use. Designers need to get data into the build? Here’s a tool. Need to proc gen worlds? Tool. Need some validation of data to ensure designers don’t screw it up too badly (and we will)? Tool. Being a tools engineer isn’t sexy (although ours seems to like it), but it is an essential role.

Bonus Joke: Q. How many engineers does it take to change a light bulb? A. That’s not on our task list for this sprint.

Another Bonus Joke: Q. How many gameplay engineers does it take to change a light bulb? A. We don’t really have time to do that, but here, we hacked in some LEDs.

QA

That stands for “quality assurance.” I worked for a while on a project that had no QA. Boy, was that a bad idea.
Before any code gets into the build, it needs to go through QA. An engineer (or a designer working on scripts or data) finishes their work, submits it to QA, and QA has the power to reject it. No, this isn’t to spec. Or no, this doesn’t actually do what the engineer claims it does. Or no, this is causing build errors when I merge it to master.

Or no, I’m seeing so many bugs, here’s Jira tickets for them all, kick it back, fix please.

Of course sometimes it’s more like “well… okay, I’ll merge it in, but here are all the bugs I found, we’ll decide what to prioritize for fixing at the next bug triage meeting.”

In a sense, then, QA and engineering are class enemies. They’re playing a game, which you can observe in the bug tracking graph in your task management system. QA tries to keep the line going upward (finding bugs), engineering tries to keep it moving down (fixing bugs).

Or as one of our QA engineers says, “You make it, I break it.”

Just by the way, no game ever ships bug-free. Some bugs appear once in a blue moon, or are incredibly hard to reproduce. Some don’t materially impact the player experience. Some seem just too minor to fix. Of course, there’s no excuse for shipping with serious crash bugs or memory leaks or any number of other things, and if you buy a game with that, you have a right to complain. But realize the reality. I mean, it’s not like we’re writing software to control jet-liners or automated cars; no one is going to die if our game goes wonky at times.

Bonus Joke: Q. How many QA people does it take to change a light bulb? A. This branch contains LEDs and not the expected light bulb, and is rejected.

Seriously, For a Moment

Well, semi-seriously anyway. I may have given you the idea that game development is kind of a mess. And it is! A big, glorious, crazy mess. But when it comes together, there’s nothing that’s better than launching a game that people like.

And a lot of the pitfalls I talk about? Thankfully, we have a pretty experienced team, so we won’t make the obvious rookie mistakes. Will our servers crash under the load of users at launch? I would be very surprised; we’ve been through the wars, we know not to make that mistake.

Or as Eric says, “We’ve all made a lot of mistakes in the past, and know how to avoid them. Let’s make all new, different mistakes.”

But in ending, I’d like to make a plea for compassion to game developers.

Two-thirds of game projects never launch. For a host of possible reasons; they ran out of money, the publisher lost confidence in the project, key people left, their ambitions were too large, metrics in beta were disappointing. More projects get canceled than ever see the light of day. I’ve been down that road more times than I care to count.

You bought a game and were disappointed with it? It happens. It’s not because the developers were incompetent, or didn’t care. I guarantee you that everyone involved in that project believed in it, at the start at least, and are heartbroken that it didn’t come out better. But game development is messy and hard. Not everything succeeds.

Are we in it for the money? Well, sure, welcome to late-stage capitalism, money is the condition of survival. But everyone – almost everyone anyway – on a development team could make more money doing something else.

Engineers could make more money at Google or Amazon. Artists could make more money in advertising. Even designers could make more money working on productivity software or something. We like to get paid, for sure, but we’re not in the game industry for that reason. We’re in the game industry because we love games. And we want to make the best game we can.

…And no, the light bulb never got changed. But we did persuade QA to leave in the LEDs.