From both non-fiction and fictional works you can get a fairly realistic idea about how movies, plays, novels, and other creative forms get made. Perhaps because video games are more recent, few people understand how video games get made – and in some cases, very unrealistic ideas about video game development have been presented to the public. (I’m looking at you, Ready Player One and Reamde.) In a very essay-like way, I’ll bookend this post with some reading suggestions for books that do a better job of getting across what game development is actually like. So you can skip ahead, if reading suggestions are what you’re after.
My editor, Danielle, who is our community manager, suggested I start from “the idea,” as the notional inception of the process. So I will, if only to disabuse you of any illusions.
The Idea Is Almost Never Yours
Our conventional notion of creativity is that some lone genius in a garret is inspired by a muse, and in a frenzy of creation, works passionately to concretize a fantastic idea in a revolutionary new form.
Over the course of my career, I have – I won’t say never but extremely rarely – been asked to work on a game that I originate creatively. Nine plus times out of ten, there are severe constraints on “the idea.” Here are some (snarky) examples.
- Our game SHINOLA LEGENDS was modestly successful, we want you to design SHINOLA LEGENDS II, but it has to sell better, make it better than the first game.
- SHINOLA LEGENDS II was a big success, but it’s an FPS title, and we want to extend our IP to the match-three market on mobile, design us SHINOLA LEGENDS 3 CRUSH SAGA.
- We see that our competitor’s game, SHINOLA LEGENDS was a modest success, but they pioneered a new genre, which we are calling the farmer-and-battler-style game, so we can avoid calling our new game a SHINOLA LEGENDS clone. But we think we can do better with some improvements to the basic gameplay, so we want you to create EVEN BETTER FARMER BATTLER.
- EVEN BETTER FARMER BATTLER was a big hit, and we have a Marvel license and we think that attaching a hot license to the basic gameplay of that game will reduce our user acquisition costs, and if we add some nifty thematic elements from the IP we can have a big hit; create us MARVEL BATTLE FARMER.
The point: As a game designer, you will almost never be asked to come up with a new idea for a game. Most of the time, you will be handed an existing IP (whether that comes from a previous game, a license, or an existing genre) and asked to tweak it slightly. Alas, our industry does not thrive on ideas. It limps on, on clones, brand extension, and tweaks to successful genres.
As a designer, I kind of hate this; but as a participant in a commercial medium, I also understand it. If someone is going to invest a lot of money in developing a new game, they want to minimize their risk; and their (often unwarranted) assumption is that by building on a previous game, licensing popular IP, or copying the tropes of a successful genre, they are more likely to make money. I’ve worked on a lot of games like this. Please don’t ask me about My Little Pony Puzzle Party (which, to be honest, I had only tangential participation in).
Show Me the Money
Uh, I fear I’ve left you with the idea that Playable Worlds is creating an open-world, sandbox MMO, Raph Koster-helmed My Little Pony game.
And that’s totally true! Friendship is magical!
The next step is finding the money. Not always; often you need a first playable to show the people with money, but fundamentally, moolah rules.
As shocking as it may be, game developers are averse to starving for their art. And at least beyond the indie level, they mostly expect fairly decent pay for their efforts. Mind you, there are plenty of indie developers who survive off savings or family support while pursuing their dream; and I remember Rami Ismail talking about living off ramen while developing his first game, and God bless him.
A game development project can (and typically does) go on for years. And during that time, you’re paying out money for salary (and licenses, and office space, and benefits, and other expenses, but salary is the big hit) before you ever see a dime of income. Whole lotta money up front for a hope of money down the road. It’s not an easy sell.
There are a bunch of ways you can find that money: If you work for a big publisher, you can maybe sell the suits on an idea you have, and that they should fund it. If you’re an independent developer, maybe you can maybe sell a publisher on your idea, or agree to implement some idea they have (My Little Pony Puzzle Party, surefire hit, banzai!). If you go to an industry show, you’ll find that lots of developers are pitching publishers in hotel rooms to try to get funding.
One of the hardest rows to hoe is to try to get venture funding, but that can happen.
Oh, wait. That’s what we did. Raph got a bunch of people with MBAs to give him money to make the game we want to build.
Sweet!
Stages of Development
So now you know how an idea leads to funding…What happens next?
Pre-Production
“Pre-production” for the game industry means something rather different from pre-production in the film industry. There are some similarities: we both do visual explorations, and I guess you could say that writing an initial design spec is sorta kinda like writing a screenplay (although not really).
Pre-production in the game industry means assembling an initial, relatively small, core team: a handful of engineers, artists, and designers. The artists work on defining the graphical look for the game, concepting graphical assets and building out your art development pipeline. The engineers work on developing the server- and client-side technological underpinnings for the game (which, in our case, took quite a while, as our architecture is highly unusual for the game industry). The designers spec the main gameplay systems, make wireframes (UI designs), and define what the data the game will consume looks like.
Quite often during this period, you’re also building prototypes of key game systems. Prototypes can be almost anything: sometimes they’re paper (we have a card game based on one of our systems), sometimes they’re spreadsheets, but often they’re in code – created either by more technical designers, or designers in collaboration with engineers. The point of a prototype is to prove that the idea behind the system produces interesting and fun results – but the underlying code is typically not directly ported into the game itself, because prototypes are supposed to be developed quickly and iteratively, and don’t necessarily work with your game’s underlying architecture (which at this point is only beginning development anyway).
First Playable
You can log into the game. You can run around in it. Maybe there are a handful of other things you can do.
Vertical Slice
That’s our next major goal. Traditionally, a vertical slice is “one playable level,” but we don’t have traditional levels, so instead we’re aiming at “some implementation of game systems an early player will encounter.”
Alpha
Technically, alpha means “all systems in place,” but not all content, and probably still buggy as hell. More cynically, alpha often means “welp, our publisher will pay us a big chunk of money when we hit alpha, and we need the money now, so we’re calling what we’ve got an alpha, and hoping we can buffalo them into giving us the money.”
Closed Beta
At this point, you’ve got a lot of what you want for launch ready to show, and invite external players in for the first time. But you’re selective about who you invite in, because you know lots of things are rough, and your content is limited, and you want user feedback but don’t want harsh criticism in public fora.
Also, if your game has a micropayment component, you keep that turned off, because you may have to reset everything, and don’t want players to lose stuff they paid for.
Open Beta
You open the doors to everyone, but with the caveat that “things aren’t final yet.” You refine and tune your gameplay in response to player metrics and feedback.
Launch
Yay! Big marketing push, hopefully lots of people show up, and you start making actual money. Then you get to weep at the reviews and tear your hair out as the servers keep crashing because they can’t keep up with the load. And many engineers work long days as you struggle to fix all the problems that didn’t show up with a handful of users but are now blatant with lots of them in the game.
Live Ops
The work doesn’t end just because you’ve launched. MMOs in particular can last for years – decades, even. Your players want more content. Your designers want to implement all the pretty systems they imagined back in the day that got triaged because of the reality that you can’t do everything at once. Your product managers want to improve your monetization metrics. Your story arc needs to be extended. The cherry blossom festival is coming up, and we need an event for it. And so on… Your work is basically never done.
Speaking of which…
Who Does What?
Once you’ve got the start of a functioning system, confidence in your design, and agreement on an art style, you move into production. This is when you start building out your full team, moving from a small pre-production team to a much larger one capable of fulfilling the game’s ambitions in a reasonable amount of time. (I am talking about AAA, or at least single-A game development here; most indies are implemented by quite small teams.) In our case, we’re up to about 40 people now, and still growing; some AAA games have teams of hundreds of people, but we don’t plan on getting that huge (thankfully).
There are four key disciplines involved in game development — engineering, art, design, and product — and a couple of others that don’t get as much credit but are essential to the project (and I’m not even including management and HR and stuff, which Eric, Raph’s co-founder, likes to refer to, self-deprecatingly, as “useless overhead”).
Design
I’ll start with designers, because I am one. Designers do a lot of different things, actually, and on a sizable team, they typically specialize.
It all begins with a spec. A spec is a document that describes a system and how it is expected to work. That includes wireframes and diagrams; sometimes it includes user flows, storyboards, and even entity-relationship diagrams, which define the supporting data for the system and the relations between different actors in the system. Designers who specialize in this are called systems designers, and they also typically work intensively in data definition.
What do I mean by data definition? Particularly for a game-as-a-service (pretty much any game with an online component), you want all data to be external to code. That is, if a weapon has a particular rate of fire, you don’t want that hard-coded, you want it in an external data file. There are two reasons for this: First, when you are testing and balancing your game, you want to be able to change that number quickly and easily, without having to rebuild the executable. Second, when you are in live ops, and the team decides it needs to change that number, they can do it easily by changing the external data file, without requiring every player to patch their client. So designers become the masters of the data, because engineers have better things to do. There’s no particular name for designers who specialize in data-tweaking (other than “spreadsheet jockey”, because data is often kept in a spreadsheet, and exported to JSON or XML for game consumption).
Levels are typically created by level designers rather than artists, although this is definitely a collaboration. See that tree over there? A designer decided it would be a good place for a tree, and put it there. See this corridor layout that creates interesting dynamics in an FPS fight? A designer built it. And so on. In our case, since we’re doing procedurally generated worlds, it’s not quite like that, but it is something along the lines of “this scheme for procedurally generated worlds ensures that there are four equidistant starting areas connected by paths to create a world suitable for four-team MOBA-style combat.”
Scripters write scripts. What does that mean? Depends on the game, and it can mean anything. I’ve scripted dialogs, quests, magic spells, and special abilities. In our game, any gameplay system that isn’t critically processor- or server-dependent will be scripted – some by gameplay engineers, some by technical designers (which is what a designer who specializes in this is called). Most large projects use a language like Javascript, Lua, or Python for scripting, so in essence a technical designer is a kind of engineer, but we can pay them less because they have “designer” in their title rather than “engineer,” and they don’t mind because they want to grow up to be Shigeru Miyamoto and not John Carmack. Besides which, designers have more fun.
Finally, we come to UI/UX designers (that’s “user interface/user experience”). Any designer worth their salt should be able to sketch out a wireframe or define how a system functions, but a UI/UX specialist thinks long and hard about how users will actually interact with the system, what’s the simplest and best way of getting players to grok it, and what’s the best functionality for the UI. So in other words, they take my crude wireframes and grotty ideas and make them sing. They typically work closely with a UI artist, who defines the look and feel of things and makes the actual assets used in the game.
Oh, also designers spend a lot of time testing the game, because it’s QA’s job to say “this isn’t implemented to spec,” or “this is buggy,” but it’s design’s job to say “actually, this sucks, how do we fix it?”
Bonus Joke: Q. How many game designers does it take to change a lightbulb? A. We don’t change light bulbs; we create incentives for our players to change light bulbs.
Everyone Else
Obviously, designers rule, and all the other disciplines involved in game development are far less important. (Which I totally don’t believe. And also I like my co-workers and don’t want them to kill me.) But I wound up writing a 5000-word screed on this subject (as is my wont, I don’t tweet because nothing that can be expressed in a few hundred words is worth saying), and Danielle decided to split my screed in two. Which I can understand; long is long.
So come back next week for what artists, producers, engineers, and QA people actually do.
And for some more cogent thoughts. Also, more Bonus Jokes.
Recommended Reading
I said at the beginning of this that I’d recommend some books that actually get across what it feels like to work as a game developer, and it seems cruel to make you wait for Part 2 for them. So here they are.
Austin Grossman’s You
Rich Dansky’s Vaporware
Not surprisingly, Austin used to work in game development, and Rich still does.
And no, neither evil AI nor paranormal phenomena are common in game development, but both novels do a good job of imparting what game development feels like.