Ray Mazza's Website

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.

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: 

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.

If you're still looking for the right university (or if you want to go back), there are a handful of great programs designed to give you the skills you need to excel at game design. Here are the top undergraduate schools according to the Princeton Review, along with the top graduate schools:

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.

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...

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. 

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...

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:

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.

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:

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. 

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:

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.

New designers tend to write design docs like they’re compiling a Christmas list to a stodgy Santa Claus:

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: 

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).

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:

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.

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:

Here’s a fictitious example for an interaction between a Sim and a Piñata:

Key:
Green = 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.

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:

And if a design point is vague with words alone, consider supplementing with an image:

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:

A lot goes into writing and formatting a great design document. This list is the best of what I’ve learned, but there are plenty of finer details. I highly recommend you follow the links to Damion Schubert’s presentation, Stone Librande’s presentation, and the Slate article Lazy Eyes (How we read online) for more advice and inspiration.

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.