| || |
A few times each year, a friend of a friend will ask for advice about becoming a game designer. It's usually someone who works a completely unrelated job, or it's a student realizing their major isn't what they had hoped. But that's completely normal – most game designers start out doing something else – animation, writing, engineering, and so on. Very few go through game design programs (although that’s becoming more common).
Regardless of who it is looking to become a game designer, I find myself giving much of the same advice time and again, so I've decided to post that advice here.
1. Make a Game!
This is by far the most important because it's the best way to get an understanding of what game design is really about, and it's also the most useful for showing an interviewer what you are capable of.
You don't have to make a colossal game with 3D graphics and online multiplayer. Don’t try that. Start as simple as possible.
If you know how to code, or are willing to learn, make a simple puzzle game or platformer with a few levels. If coding isn't your thing, try a program like Game Maker
or Game Salad
which don't require you to write code.
Or don't use a computer at all – make a card game or a board game. Print it yourself or use a service like Game Crafter
. Plenty of designers draw inspiration from a host of board games and design them in their spare time. Plenty of my lunches have been spent playing board game prototypes my friends have designed
(and sometimes they end up published
So: Brainstorm for ideas. Pick one you like. Write a design for it.
If the idea is simple (like it should be for your first games) then the design should be quick to write. Then implement it. Play it. Test it with others. Polish the hell out of it until every interaction feels super-satisfying. Iterate until both the second-to-second play is fun, and the long-term game loops are compelling – or go back to the drawing board. But do not give up.
It will take a while. Finish a full slice of the experience. Doing just this will set you apart from other aspiring designers.
I will say it again: a complete, fun game is the best thing you can bring to an interview
(or a complete slice of one). Don’t hesitate to bring your failures to an interview as well, as long as you can articulate what your intentions were, why the ideas didn't work, and what you learned from it as a designer.
2. Ideas are a Dime a Dozen. Strong Execution is the Rarity.
Actually, ideas a nickel a dozen. (A baker’s dozen at that.) Everybody and their aunt has a game idea. Ideas are plentiful. Usually, designers have scores of fantastic ideas that will never see the light of day because there isn't enough time to make them. It's the clever execution of one of those ideas and the successful solving of thousands of problems that come up along the way that counts.
So if you want to become a game designer, you cannot rely only on your list of game ideas. This is why you need to make a game first (see #1). On top of that, you must also understand the myriad other responsibilities that designers typically have when working with a team:
| || |
- Summoning a holistic vision from the depths of your creative consciousness and communicating it to the team.
- Understanding what features are possible with the team that you have.
- Articulating features in crisp detail within design docs.
- Developing prototypes to test game ideas and features [Pic 1][Pic 2][Pic 3][Pic 4][Pic 5].
- Mocking up UI.
- Writing game story and text.
- Level design.
- Leading design meetings to explain features to animators, modelers, engineers, UI designers, the audio team, and producers.
- Working with these same people on a daily basis to see features through to a satisfying completion.
- Answering thousands of questions and making hundreds of compromises.
- Scoping all designs to fit within the given schedule.
- Endlessly polishing all interactive elements, visuals, level flows, interfaces, etc.
- Running playtests to figure out and fix problem areas.
- Working with marketing to define media campaigns.
- Finding & fixing bugs (and deciding which ones not to fix).
- Working in tools and spreadsheets to mathematically determine optimal game balance, as well as balancing through instinct and feel.
After you look at this (incomprehensive) list, you should begin to realize why it not only helps to make a game before trying to break into the industry, but also to make a game with other people if you can. Find an engineer, an artist, and an audio expert, and develop something together. It doesn’t have to take over your life. Game Jams
are a great way to hook up with other people and get a quick feel for making games, and these relationships and games can lead to longer-term indy projects.
3. Consider a School with Game Development Programs
I attended CMU's Entertainment Technology Center
for the two-year Master of Entertainment Technology graduate degree. It was a fantastic program as many of the others are. The great programs like these team you up with students from other disciplines to work on game projects so you build the interdisciplinary skills that will set you up to excel
in the industry. In addition, many of these schools have great relations with some of the biggest companies, which makes it easier to get interviews, co-ops, and internships. Lastly, these programs typically make you part of an extended network of connections that will be great to have later.
Or, if you're already in a regular school, take whatever game courses they offer. You may quickly learn that you love it or hate it. When I was a sophomore in college, I took a game programming course, and that's when I knew that making video games for a living wasn’t just a dream, but a very real possibility.
4. Develop a Parallel Skill
Nurture another ability you have, or develop a new ability. Learn to program. Start modeling or drawing concept art. Write short stories. Compose music. Join an improv troupe. Delve into architecture.
Designers pull inspiration from all walks of life. Designers with parallel skills often find an easier time thinking about design problems from unique angles.
Also, having a parallel skill helps you...
5. Join as an Artist, Engineer, Producer, or Writer
It's hard to get a job as a designer right away. Most designers start out doing something else at their game dev studio.
I started as an engineer, and with my engineering skills I was able to make prototypes and features that exhibited my game design sense.
Many start as artists, producers, or writers. Some designers even work their way up from being a game tester, though that's harder (if you are embedded with the team, you have a better chance; many testing departments are so large they're separate).
Also, don't be afraid to take an internship.
I graduated with a master’s degree, but I started working as an intern because it was all that was available at the studio I wanted to join: Maxis
. Use an internship to impress your team and prove you’re worth keeping. And if you don’t interview particularly well, but you’ve got the skills, then an internship is an easier way to get in the door.
6. Be Able to Talk Intelligently about the Designs of Published Games.
It sounds obvious, but I've given plenty of interviews where candidates can't get specific enough about what makes certain games (and aspects of them) great designs or terrible designs.
I usually ask candidates to list some of their favorite games, and then I dig into one or two of them.
Portal? Why is Portal a well-designed game? The levels. Tell me more about that. Is it how the minimalist style helps convey story and contrast the dirty, hidden back chambers that the player stumbles across, which creates a sense of unease? Is it how each level teaches the player a new way to use the portal gun or a new combination of previously-learned skills, which makes for a wonderfully fluid and appropriately-challenging experience? Or is it the ingenious use of space to create puzzles of momentum that have never been seen before? What else? Tell me more about each one.
Be as specific as possible. The biggest indicator of an unskilled designer is the inability to be specific. This is just the beginning. Be able to speak this way about most aspects of the games you've played.
In order to build this discussion ability in the first place, you need to...
7. Know What Makes a Good Game
And for that matter, know what makes a bad game. It sounds easy, but it takes a lot of intentional reflection on all aspects of games: their character progressions, stories, loot systems, control schemes, interfaces, visual feedback, behavioral motivators, intrinsic and extrinsic rewards, level designs, forms of creative expression, goal systems, strategies, game loops, reward schedules, difficulty ramping, economic balance, social interaction, player types, and on and on.
There are plenty of ways to start building a wealth of this knowledge:
| || |
- Play lots of games. Don't spend all your time on one game. If you've been playing WoW for nine years and haven't played much else, it's time to diversify.
- Keep a game journal. Do it. For each game you play, record 10-20 bullets about aspects of the game that stick out to you – what tweaks your emotions, what's super fun, what's annoying, what makes you laugh? It's sometimes a pain, but it helps you reflect on your games as you play them, and your journal can be a great source for ideas in the future.
- Write game reviews. Play a game, then write a critique of it as if you were going to publish it (or go ahead and publish online). Compare what you've written to professional reviews so you can see what professionals consider the salient aspects.
- Read, read, read about game design. There's plenty available on the web. For starters, try these articles:
> Behavioral Game Design by John Hopson
> Good Design, Bad Design, Great Design by Raph Koster
> Finishing a Game by Derek Yu
> The 4 Player Types by Richard Bartle
Also, I highly recommend Jesse Schell's The Art of Game Design textbook.
- Check out Kellee Santiago's commandments of Game Design here. Excellent advice.
- Attend the Game Developer's Conference. If it’s too expensive, sign up as a volunteer. Go to all the inspiring design talks. Also, check out the GDC vault for free design lecture videos.
8. Lastly, Know your Target Company's Catalog
When you go for an interview, you should know the company's prominent games. Play them. Be able to critique them, have suggestions for improving them, and be excited about the possibility of working on them or similar titles.
Breaking into game design isn't a breeze. It's hard work, just like any other job, but fortunately, the hard work can be a lot of fun. Don't expect to just waltz or gangnam-style your way into a game studio on a whim to secure a game design job. Study games, immerse yourself in design literature, and, if you can, make something! Then, you'll be on your way, and a rewarding career will be within reach, where you can make millions of players happy every day.
Are you a game dev with other helpful tips for breaking into game design? Did anything particular help you land a design job? Please share in the comments!
When I first started writing design docs over seven years ago, they were disorganized, littered with weak language, and crammed with blocks of text so impenetrable to the discerning eye that they might have actually shielded a ring-wearing Frodo from Sauron’s gaze.
Compare this bird’s-eye view of a page from one of my first designs with a page from a design I wrote four years later:
| || |
(Design Doc, Circa 2005)
| || |
(Better Design Doc, Circa 2009)
Who sees the page on the left and doesn’t wince? It’s almost as friendly as a tome of tax codes. The page on the right, on the other hand, is inviting – it’s colorful, organized, and appropriately sparse.
The first problem any designer must overcome is getting their team to want to read a design. The second problem is presenting the information in a useful format for implementation. In this article, I’m going to share five tips I’ve learned that led to my current design doc style – a style which I’ve considered a success ever since developers who have moved onto other projects told me they missed this format.
1. Always Start with Design Goals
If you’re designing a feature, your developers need to know what its purpose is. It’s context for the rest of the design, and not only informs the developers how to read each aspect, but also helps them provide better suggestions for improvements.
More importantly, the goals are for you, the designer. Writing 3-5 goals forces you to get to the heart of a design’s importance. Once you’ve written them, you’ll think more clearly about each aspect of the feature, you’ll avoid unnecessary bloat, and you’ll be more creative when challenged to achieve those goals.
Here’s an example of goals for a Tomb Level-Scripting feature for The Sims 3 World Adventures:
| || |
- Tomb Object Modularity. Traps, puzzles, doors, and rewards should interconnect with each other such that we can create countless combinations of interesting and challenging spaces.
- Non-Linearity. Allow entry to many tombs without being on an official adventure so players can stumble upon gameplay while exploring the world.
- Recognize and track progress. Surface the player’s progress through tombs and adventures in order to offer more goals and achievement-based motivation.
These goals are short, sweet, and they drilled to the core of what we felt was important for our tomb development system. Goals like this will set you up to craft a better design.
2. Use Strong Statements. Ditch all Mitigated Speech.
New designers tend to write design docs like they’re compiling a Christmas list to a stodgy Santa Claus:
| || |
- “It would be great if we could get a seamless world with a huge playable area.”
- “We might want to let players use the character creator to make NPCs for the town.”
- “If possible, it would be cool to kick fallen enemies and have a chance of coins spilling out.”
Every time developers read lines like this in a design doc, they lose confidence in the designer, and usually file these parts of the design into their “we don’t have to do this” category. Designers need to take a stand in their designs.
Brainstorms and early design meetings are for discussing possibilities and uncertainties, but design documents are for telling the team exactly what the game will be. Even if the designer doesn’t entirely believe in what he’s writing.
All designers are filled with doubt about some of their designs. Will a HUD-less screen work? Will the engineers laugh at me because I want to pull 20,000 cooking recipes from an online database? Will animators refuse to animate a snake latching onto a character’s face and flailing about?
Yes. They will! This is normal, and this is necessary. It’s part of the process, and it leads to great conversations that narrow in on what’s right and possible for your game.
So take a stand. Ditch all mitigating speech
from your designs – no more maybe, possibly, could we, it would be cool if
, etc. (Malcolm Gladwell writes, in Outliers
, how mitigating language likely led to at least one plane crash when a cockpit engineer and first officer were too soft-spoken
to the higher authority of the pilot, rather than speaking clearly in a dangerous situation.) In addition, be as specific as possible.
Instead of “large,” say “25 square kilometers.” Here’s a rewrite of the design statements with strong and precise language:
| || |
- “The world will be a seamless, 25 square kilometer playable space.”
- “Players will be able to use the character creator to make NPCs for the town.”
- “Players can kick fallen enemies to have a tunable chance of additional coins spilling out with value proportional to the enemy’s normal loot.”
Much better. This was one of my first and most important lessons as a designer, thanks to my boss and Creative Director at the time (Matt Brown, now of Blizzard).
3. Lots of Bulleted Lists!
Design documents are, effectively, lists of tasks.
So why not present them that way? Damion Schubert says in his fantastic GDC 2007 presentation, How to Write Great Design Documents
(a must-read for all designers), “Programmers almost always want a short bullet list (they kind of like checking things off lists).”
This is a bird’s-eye view of the entire design for The Sims 3 World Adventures
tomb technology which allowed designers to script tombs by interlinking object behaviors of traps, triggers, and objects. Notice that the majority of the text appears after bullets:
A bird's eye view of The Sims 3 World Adventures "Tomb Technology" design doc.
And here’s a snippet pasted from the doc:
Each bullet is either a specific implementable task, or a header for a subset of specific implementable tasks. Write your designs like this, and they will be more readable and more actionable. And your engineers won’t hate you as much. (They may even begin to like you.)
Non-bulleted text is usually an overview, introductory text, or otherwise non-implementable.
Another benefit of bullets is that they naturally reduce vague language. It’s easy to hide uncertain statements within large blocks of text and not even know you’re doing it. But bullet points shift your mind into making strong, concrete statements.
4. Color Code for Disciplines and/or Readability
You may have noticed that I use plenty of color in my design docs. This was inspired by the great readability of gear hovertips in World of Warcraft (which had improved on a similar presentation in Diablo II). Take a look:
Even if you were illiterate, the coloring conventions would tell you that the Infernal Mittens were more rare (purple vs. blue), you could not equip either item (red text), that the Mittens had some unrealized bonuses (gray text), and that both items had additional bonuses (green) on top of normal stats.
Now, translate this to design docs. I use color for three things:
| || |
- To draw attention to specific disciplines (art vs. animation vs. UI, etc).
- To emphasize hierarchy (section headers & sub-headers).
- To emphasize importance.
Here’s a fictitious example for an interaction between a Sim and a Piñata:
= Interaction Orange
= Animation Purple
= Important Object or Related Design (like Traits) Pink
= UI Requirement Red
= Visual Effects Light Blue
= Standalone Audio (not attached to animation)
You should adapt your color styles to the needs of your game and your team. Perhaps you need to call out a lot of text requirements, or your world builders will want to easily find aspects related to level design. This may seem like a lot of effort, but it’s worth it.
Suddenly, your key disciplines will find it much easier to absorb your designs and find the portions relevant to them.
Want to know all the UI requirements in a 15-page design? Just look for the pink sections. I’ve had people move onto different teams, then tell me they miss this formatting and cannot do their jobs as easily.
The success of color in my design docs has spilled over into my style in these posts. I use bold color
to emphasize important points and to create visual anchors, which also helps prevent readers from skipping blocks of text. I highly recommend reading Lazy Eyes (How we read online) by Michael Agger
– an article that also deeply influenced my formatting style online and in design docs.
5. Use Images to Set Mood or Explain
This one is pretty simple: a picture is worth 1000 words in a design doc.
I like to use a picture at the top of every design document to set the mood and draw the reader in (and I do the same thing with almost all of the articles on my website). For example:
Place a mood-setting image at the top of each design document.
And if a design point is vague with words alone, consider supplementing with an image:
An example from The Sims 3's design doc for Painting Skill.
In fact, if you have a complex design with many interwoven parts, a design document dominated by imagery can be preferable. For more about this, check out Stone Librande’s great One Page Designs presentation
from GDC 2010:
I’ll know I’ve made it as a game designer when…
… growing up, I design games that aren’t much fun, but I have a great time doing it.
… I eventually make an amateur game that people enjoy.
… I drop out of school to become a game designer.
… I beg to be a design intern and I tell companies I’ll work for free.
… I enroll in one of those new-fangled game design programs.
… I finally design a feature for a professional game.
… I design major systems for a game.
… I ship a game.
… I go to the store on launch day to watch fans pick up copies of my game. And then I pose with them in a photo, holding armfuls of my game with a stupid grin.
… I spend hours, days reading Amazon reviews and posts in our forums. I can’t stop; it’s like a drug. Players love our game, and I love our players. I get giddy. But players hate our game, too. I get furious. I am forever influenced.
… I ship a sequel to that game.
… I’m about to ship another game, and it has already been pirated and is available on the internet.
… I balance an entire game. It takes weeks. It feels wrong. So I balance it again. And again. After it’s perfect, we release, and players find ways to break the economy within hours.
… I work on new IP.
… I have to cut 70% of the entire game because it’s so over scope. It nearly destroys my soul.
… I come to enjoy the process of cutting and scoping. It makes my designs clean and elegant.
… I spend four years on a project that gets cancelled.
… I have total faith in my designs, but when I play them, they’re terrible. I rework them. I think they’re finally good. Players get confused in focus tests. I rework them again. Some end up great. Others get cut.
… I design a game that I can’t bear to see.
… I get hate mail. It scars me and I eat soup in bed and consider becoming a doctor, someone who can make a serious difference in life.
… I design a game that’s a success. I momentarily wonder if I can ever do that again.
… I secretly think my designs are better than anyone else’s.
… I secretly think my designs are boring and uninspired.
… I become a lead designer.
… I then realize my design opinions aren’t as important as supporting my team of designers, even if we disagree.
… I care so strongly that I uncharacteristically yell and swear in meetings to protect certain designs.
… I become a creative director.
… I pitch revolutionary ideas and concepts. But they’re too crazy.
… I work on a game that sells one million copies. Five million copies. Ten million copies.
… my game scores 95 on Metacritic and wins Game of the Year in the Game Developer Choice Awards.
… the game I designed lives on years after launch, a new team keeps releasing content for it, and I’m excited about that.
… I design a game with one of my favorite celebrities in it, but never get to meet that celebrity. But we get a mannequin with one of her dresses in our lobby.
… I go to the GDC five years in a row. Ten years in a row. Twenty years. I’m inspired every time.
… I give a game design talk at the GDC. I make a name for myself. I burn or tear money on stage to make a point.
… I start a blog. And the more I talk about design, the less I actually design.
… my shelf is packed with games I’ll never have time to play.
… I no longer play games until I beat them. The games that I do play, I often play just once. I see flaws in design everywhere and the games are nothing new.
… occasionally I find a great game that I want to play for hundreds of hours, but then I feel guilty that I’m not trying other games to expand my horizons.
… I have pages and pages of design notes for games I will never have the time to make.
… I work for 5 years jumping from team to team, and never ship a single project.
… I denounce the corporate culture and quit to join a startup.
… I work for a well-funded startup with rock-star executives. It falls apart.
… I work for a different startup, and realize startups aren’t all they’re cracked up to be.
… I consider working for Zynga, and then I do.
… I consider working for Zynga, and then I don’t. But half of my friends do.
… I work on a Facebook game that 100,000,000 people play.
… I work for yet another startup, and it takes off. We get bought out.
… I get fed up with the mass market, and quit to go design indie games. Games that will be hailed as art.
… I release an indie game and only five people play it. It breaks my heart. But those five people are awesome.
… I travel from game jam to game jam, chasing novelty and heartbreaking works of staggering genius.
… I make an indie game with meaningful gameplay, and have to live with my parents so I have someone to remind me to eat and to not die.
… I design something truly original that the world has never seen.
… I earn over $50 million selling my game’s beta build on my website.
… a fan recognizes me.
… fans recognize me wherever I go. And they want to know if I’ll ever get around to making a new game.
… fans stop recognizing me. Or maybe I never had any.
… I return to my old job because the corporate culture is great and I miss my team.
… I pull all-nighters and crunch for months on end. Not because my boss makes me, but because I want to make an incredible game.
… I design a game that makes players laugh and smile, that makes them shout and cry.
… and, above all …
… I design a game that I am truly happy with.
This post was inspired by Justine Larbalestier’s “I’ll Know I’ve Made it as a Writer When…” It’s a fantastic piece and deserves to become a meme, so I’m getting the ball rolling.
Speaking of writing: I recently published a novel series about a company that grows a super-intelligent human in a computer and the mayhem that results. It is something I am truly happy with. Check it out here.