Category Archives: Theory & Practice

Musing on game design theory and the practice of making games.

GDC 2015 Talks on Design in Sunset Overdrive

My blog’s been silent for a little while because I’ve been really busy with preparing for GDC. This was the first year that I’ve spoken at the event and gave not one but two talks on design in Sunset Overdrive.

Since I’ve now given both my talks, I’m going to share my slides and – since there are no notes on the slides – my talking points.  Keep in mind that these notes are rough drafts and since I practice and memorize my talks they eventually fall out of date to the actual presentation. Regardless, my talks should be pretty easy to follow without the video if you consult the slides and notes together, but I expect them both to be on the GDCVault eventually.

Level Design in a Day: The Worlds of Sunset Overdrive

This is a 25 minute talk that covers the first two cities we built before we made our final city, and talks about what happened with those cities that made us decide to throw them out and start over again. I focus on how the changing design of the game – the emphasis on traversal, the open world vs. linear spaces – led to major changes in the geometry.

Transitioning from Linear to Open World Design with Sunset Overdrive

This is an hour long talk that goes into Insomniac’s changes in the design department to adapt to the new needs of an open world game, but also the specific needs of a game like Sunset Overdrive. I talk about the structural differences between a linear and an open world game, how designer roles and responsibilities changed, what our new workflow looked like, and the pros and cons of those changes. Whenever possible, I compare and contrast development on Sunset Overdrive with development on Resistance 3.

Mini Post Mortem

So I mentioned before that this was the first year I had ever given a GDC talk, so maybe some of my experiences might help others thinking about giving their first talk. I made it a goal the year before to pitch a talk, but the day proposals were due I still had no idea what to write about.  So I recruited Lisa Brown (@Wertle) for an emergency lunch session, and somehow dragged Drew Murray (@PlaidKnuckles) into the conversation at one point. By the end I realized that I had a lot to talk about with how things changed at work for designers as we moved into open world development.

(My advice for others who want to give a GDC talk and don’t know what to talk about? Recruit others. It’s hard to know what you know without others pointing it out.)

So I wrote a pitch for my talk on transitioning from linear to open world design, sent it in, and the GDC advisory board approved it. I had some emails back and forth with my advisor, Clint Hocking, who gave me some really excellent feedback and asked if I’d be interested in also participating in the Level Design in a Day summit. If I had to do it over again I might not have agreed to two talks – at least not for my first GDC. It was a bit overwhelming, especially since I went off travelling for a bulk of that preparation time.

There are some things I learned after the fact. Like, did you guys know there’s a “presentation mode” for slideshows that actually displays your current and next slides AND your notes? I didn’t. I never used it. I didn’t have any notes to read off of for my talks – it was entirely a mix of ad-lib and memorization. I also learned to ignore people who say that you’ll talk faster at a podium: as friends pointed out, I am already a fast talker. My practice times and my actual presentation times were the same, so my Level Design in a Day talk ended up cut off short (and I quietly snipped a few bits from my longer talk the next day to get in on time).

Some other things I learned:

  • Most people use something called “Presenter Mode” that shows them their notes and the previews the next slide and… I didn’t know this. I just memorized everything. I did it the hard way, apparently.
  • I was warned the speaker’s party would be terribly lame but instead it was just perfect
  • 25 minutes is too short to go really in depth, and not short enough for a distillation of a single idea. Go 60 minutes or join a 10 minute microtalk.
  • I get more nervous speaking to smaller groups, but the large GDC crowds didn’t intimidate me at all when it came time to speak.
  • There’s a LOT of studios that shall go unnamed that found my presentation on moving from linear to open world incredibly relevant.

That last bit was really important to me – I didn’t want the crowd to feel like I was wasting their time. I’ve been to too many GDC talks that I really didn’t enjoy because I didn’t find them relevant, or they were too basic and didn’t dive deeply enough into a topic.

One side effect of doing a GDC talk is that I learned a ton during the preparation stage. I had to focus deeply on a topic and dredge up everything I knew, research what I didn’t know, and then determine what parts make the ‘cut’ into the presentation and which don’t. I had a lot of doubt about the content of my talks since I was (unfairly) concerned about being wrong and not having the time to get more team members to proofread my talks. But then, Drew Murray, our creative director, may or may not have said, “Look, we’re all just making shit up” and he’s one of the best presenters I know.

Hopefully my evaluations come in positively because I already have a topic in mind that I’d love to speak on next year.

Types of Designers

“So who writes the story? Who designs the bosses? Do you make the levels? What about skill trees?”

In an effort to help clarify “what does a game designer do?”, I want to go over all the different TYPES of designers. There are designers who are affectionately called “jack of all trades” who dip their hands in all elements of design and sometimes even art and programming, and then there’s specialized roles like “systems designer” and “combat designer” and “level designer”.

The truth is, any general definition of design has flaws because the actual responsibilities of a designer varies depending on the size of the studio, the platform, the genre, the size of the game, the studio culture regarding roles, how specialized people are, and even whether there is a “design department” at that studio. The designer on a first person shooter has very different practical responsibilities than the designer on your next favorite match-three mobile game.

 

GENERALISTS

Designer / Game Designer

Generic term to mean any or all of the design specializations, used at any size studio, any genre, etc. Most companies just use this term for job titles, while individual designers might still specialize informally. The larger the studio, the more likely they will have specialized designer titles.

Overall, designers are concerned with the rules  of the game, what ways a player can interact with the game, how the mechanics and story work to provide a desired experience to the player. This is the vague description that gets clarified as you read on.

Junior Designer / Associate Designer

Junior or Associate designers usually have less experience, and less creative control. They may spend more time implementing under the eyes of a Designer or Senior Designer. This is often an entry level position, catering to new hires from outside the industry (such as students), those transitioning between roles within a company (from art to design), or existing designers hired into very different scale of games (moving from a 2D game studio to a AAA studio).

Senior Designer

A senior-level position in the design department. Someone who could fill the position of “lead” and usually takes charge of a large system in the game, such as all combat or all levels, and delegates to or guides other designers. They may be the major point-person for a system and work with programmers and artists and the leads to bring it from an idea to a fully featured system.

Lead Designer

Leads translate the Creative Directors vision to the design team (much like the Art Director or Lead does for the art team). They review the gameplay from its macro to the moment-to-moment bits, giving direction and feedback to designers and making decisions regarding the gameplay mechanics.

Creative Director

The top of the game development pyramid who reports directly to the owner of the company and to the publisher funding the game. They hold the ‘vision’ of the game – this is the closest to “the idea guy” that you can get. They are analogous to a film director, and are usually the most visible in the media as the face of the development team.

Creative Directors can come from any department – art, programming, design, or even an owner of the company. Some studios use Director or Executive Producer to describe this role, but Creative Director is the most common.

 

LEVELS & MISSIONS

Level Designer

A level designer is responsible for the architecture and gameplay in a chunk of physical space – a level. They care about how the player flows through the level, puzzles or enemies or other obstacles they encounter, and implement basic geometry of the level and the moment-to-moment gameplay. They work closely with level artists to get the aesthetics in place, and gameplay programmers for specialized functionality they may need, and the writer and creative director to ensure the level fits within the overall game.

Where do I hide the intel? Where is the next objective? How does the player get from A to B – an elevator or a ladder? Which enemies attack the player in this room? Where is the cover placed? What kinds of puzzles exist? Where are the exploratory spaces? What story elements do I need to communicate to the player, and when?

Multiplayer Level Designer

These designers have the same basic responsibilities as other level designers, but they focus on the unique needs and challenges of multiplayer gameplay. They focus on designing levels that accommodate competitive and/or cooperative gameplay and the placement of any elements specific to a certain mode (flags, control points, enemy waves).

How long is this racetrack, and is it wide enough to accommodate all the players? Where are the control points that players need to take over? How far apart are the flags in Capture the Flag? Where do players respawn and how do you prevent spawn-camping? How many players need to be in this arena to defeat the boss? What architectural features of the level best cater to different player classes, such as a sniper vs. short-ranged melee attacker?

World Builder

World builders are a type of level designer – many of their responsibilities are the same, and someone qualified as one would usually be able to move to the other. The world builder title tend to exist more in open world and MMO spaces – games that don’t have individual concrete levels but rather large areas for the players to traverse around. As such, these spaces usually have multiple purposes (story missions, side quests, activities or minigames, multiplayer hubs) as opposed to traditional level design where the space has a single purpose.

Does this area have large city buildings, highways, shops, mountains, rivers, or flat? How does this area fit in with the areas directly around it? What landmarks make this area unique? What kinds of enemies, architecture, plants, or other features populate this area? How does the player navigate through it? What are the critical paths players take as shortcut, and what are the dead spaces players tend to avoid?

Mission Designer

Sometimes a mission designer and a level designer are interchangeable, but in cases like open world games or MMOs a mission designer usually handcrafts gameplay in a space that already exists, or exists for multiple purposes. Mission designers are focused on what the player is doing during a mission – the gameplay beats, objectives, combat, implementing dialogue and ensuring story elements are communicated to player.

What is the player’s current objective – is it interesting? How does this mission fit into the overarching story? Where does the player traverse to in order to complete the mission? What is the pay-off at the end? Is there any new functionality being introduced in this mission? What kind of combat, puzzles, or other obstacles does the player encounter? Is there appropriate spectacle in the mission to signify its importance in the game?

Quest Designer

Very similar role to the Mission Designer (and sometimes interchangeable), Quests tend to be secondary story-focused gameplay, usually smaller but still using many of the same mechanics as a mission or main story line. You find quest designers in studios making role-playing games and MMORPGs.

Is this quest part of a quest chain? What is the ultimate pay-off of this quest? What kind of quest archetype is it – explore and discover, fetch, combat, or something else? What enemies are involved? Where does the player have to go to get, engage in, and complete the quest? What area of the world does the quest cover? When does the player first get the quest? What story does the quest tell and how does that fit into the overall design of the game?

 

SYSTEMS

Systems Designer

A catch-all term for various systems design. Systems refers to global rules or things the player interacts with across the entire game, not specific to missions, quests, areas, or levels.  They aren’t focused on the moment-to-moment experience so much as the overall birds-eye-view of the game. To help clarify, a system may be something like “combat” while a mechanic may be “throwing grenades”. They spend a lot of their time in excel sheets and organizing information.

What kinds of slots can the player equip armor or clothing to? How does the player level up, and at what rate? How often does the player get a new weapon? How many pieces of intel are they, and what is their spread across the entire game? What are all the different puzzle mechanics and at what rate do you introduce them to the player? How many quests, challenges, minigames, and other optional pieces of gameplay are there?

Combat Designer

These designers are often at large studios that make games where the main interaction is fighting. Combat designers are concerned with enemies, weapons, bosses, ammo, difficulty balancing, and any class-based combat skills. While they are focused a lot on the combat systems, they also govern the moment-to-moment experience a player has in various combat scenarios throughout the game.

When does the player encounter a new enemy type? What is the optimal combat distance for a shotgun and a sniper rifle? How many bullets is in an enemy volley, how often do they fire, and how accurate is each bullet? Does the game use dynamic difficulty adjustments to the player’s style, or a flat easy/medium/hard setting? How much do you want to starve the player of ammo? Do bosses have weak points and, if so, what is the optimal way to attack them? How much health does a player has, and how much can a medic class heal them for?

Combat designers on competitive fighting games like Street Fighter actually have a pretty unique role that differs a bit from the above. They are concerned with such details as how many frames it takes for an attack animation to play, and dealing with the rock-paper-scissors elements to ensure that each character is extremely well-balanced.

Economy Designer

Economy designers are focused on the design, implementation, and – most importantly – the balance of a virtual economy. This mainly covers how the player earns and where they spend in-game currency. This is rarely a job title on its own but rather a descriptor for a type of system a design may be in charge of. For example, both Valve and CCP have full-time economists on staff, but any game that has loot and vendors would need a designer to oversee this system.

What ingredients are required to craft a new potion? How many experience points do you need to level up? What kind of loot drops from enemies? What are the loop drop rates, and how often do rare or common items drop?  Can players trade items with each other? How does an auction house work? If there are vendors, how does the player interact with them?

Multiplayer Designer

Multiplayer Designers focus on custom  cooperative or competitive gameplay modes and design, such as deathmatch, horde modes, MMO groups, guilds or clans, and leaderboards. They also serve the role of Multiplayer Level Designer where appropriate (depending on the size of the team or style of game).

Is the multiplayer mode cooperative, competitive, or both? What type of modes are in this game – horde, deathmatch, capture the flag? Can players organize their own guilds or clans? How many players can play together in a single match? How do leaderboard work and what do they score on? What, if any, rewards do players earn from multiplayer achievements? How do players enter and exit multiplayer from the singleplayer campaign?

Puzzle Designer

Puzzle designers are kind of the mirror of a combat designer, except that the obstacle is not an enemy but a piece of logic, like a locked door or a series of scrambled letters. Puzzle designers are often a level designer, such as in Portal or any sokoban style block-moving game. However, the role extends to puzzle games that are not based about hand-made stages – they also include balancing games like Candy Crush Saga or Bejeweled.

What new mechanic am I teaching in this puzzle? How can I re-use the same mechanics, such as a switch and a door, in different ways that feel new to the player? Does each puzzle become progressively harder? Does the player have all the necessary information to complete the puzzle? Is there a timer and how fast does it count down? In this gem-matching game, what is the bonus mechanic for matching 3, 4, or 6 gems in a row?

Narrative Designer

Narrative designers are concerned with gameplay elements or mechanics that allow the player to interact with the story, whether that’s in a linear fashion or through meaningful choices that result in branching stories. While they certainly deal with some level of writing (which varies by studio), they mostly focus on the design and implementation of narrative-related gameplay. While many studios hire writers (because most games, particularly AAA titles, have a story), narrative designer roles tend to exist at studios that specialized in story-oriented games, like Bioware or Tell Tale.

How does the player interact with story elements – through dialogue options, quick time events, or text input? Is the story linear or branching? If it branches, how many branches are there and do they always branch or do they loop back together at key moments? Is there a morality system tied to player choices? How do you communicate that a choice is meaningful?

 

CROSSOVER POSITIONS

Crossover roles are usually a hybrid of design and another specialization, so they may exist in the design department or not.

Monetization Designer

A cross between design and business, a monetization designer deals with how to take gameplay or aesthetic (non-gameplay) elements and sell them to players for real money, and how much these elements should cost. These positions exist at mobile and social games companies,  studios that make free-to-play games (like Riot’s League of Legends), studios that make MMOs (like Blizzard), and at large publishers that have microtransactions and small DLC packets in their games.

Normally your regular developers at large studios don’t worry about money or costs – that’s the job of producers, upper management, and business people. Since monetization designers deal with revenue so much they usually have a business or marketing background and come from upper management rather than up through design.

Technical Designer

Usually qualified to be a software engineer or gameplay programmer, tech designers actually bridge the engineering and design departments. Sometimes this means they take the specs given to them by designers and work with the programming department to implement them. This can be full coding and the development of new features, or it can be using scripting languages to set up gameplay such as missions and then pass them to the designers to make modifications (depending on the studio’s needs and the tech designer’s skillset). You find this role at larger companies, open world studios, and few other places, but it’s not particularly common as a job title.

UI Designer

This person is usually part of the User Interface team, not part of the design team, but has a lot of crossover responsibilities so it’s not unheard of for them to be considered a designer. Their job is to organize and present information to the player in the form of HUDs and menus – any of the graphical elements that are displayed on screen for the player. These elements include health indicators, objective text, tutorials, button prompts, inventories, maps, and crafting interfaces.

Writer

Writers focus on the overall narrative of the game, which is informed by the creative director’s vision as well as the needs of individual designers (jn the case of a mission or level-focused game). They also write the text, descriptions, names, and dialogue throughout the entire game and work with (usually external) teams to localize this text into other languages.

Sometimes writers exist on the design team, since they work very closely with them, and sometimes narrative designers may take on writing duties.  At very small companies, there may be no on-staff writer and this position maybe filled by a designer. But typically if you want to write for games, you need to be good at writing not at designing.

Design Support

This role is a low-level design position that focuses mostly on implementing tedious grunt tasks, freeing up other designers to concentrate on bigger issues. They may go through and populate the world with crates or fish, or use scripting to trigger FX explosions as the player fights in a big battle. They may place volumes or clues around pieces of cover that tells the game how AI can interact with them, and then place those volumes throughout every combat scenario in the game.

I know this role exists at my studio and at least a couple other places, which is why I am including it (we technically call it QA Support, as they are all QA people we’ve brought into support roles to help designers). This role might be that of an Associate or Junior Designer, depending on the company, or fall into a more generalized “contract work” temporary hire.

 

NOT-DESIGNERS DESIGNERS

These are roles that have “design” in their name but are not traditionally considered part of the design team at a game development studio.

Graphic Designer

A term for an artist that specializes in 2D art such as UI buttons, forum icons, web design, logos, splash screens, and similar graphic elements. They do not typically create any in-game content unless they are part of the user interface team, at which point they are usually called a UI artist and not a graphic designer.

User Experience Designer

Also sometimes called UX Designers or Usability Professionals,  these people are usually not directly developing the game. Their job is to take the game in various forms – often demos or larger chunks – and put it in front of potential players in focus groups to test it. They’re concerned about whether players understand the game, are engaging with its mechanics,  and where communication is breaking down – and then passing that information on to the rest of the team. This kind of testing is not about identifying technical bugs, but about poor or misleading design.

UX Designers often work for publishers like EA or Activision, large developers like Blizzard, or hired on a freelance basis. Smaller studios will rely on their publisher to organize focus tests or usability tests for the game.

Sound Designer

Part of the audio department, a sound designer deals with the sound effects found throughout the game world (from the player’s footsteps, to the firing of a gun, to the ch-ching of money earned), in its user interface (button clicks, new objective dings), and the music that accompanies it. They may create their own sound effects, or choose effects from a sound library their company subscribes to and modify them to fit the needs of the game.

Software Designer

A software designer is one of many terms to describe the role of a programmer. Despite the name, this is not a design position.

Hardware Designer

This is a pretty specialized role that exists at companies that deal with hardware – console manufacturers such as Sony, Nintendo, Microsoft, and Valve, for example. There are also companies that deal with peripherals, such as the belated RedOctane and upcoming Oculus Rift. You may also find these roles at toy companies that create electronics for kids, which may also use the terms Toy Designer and Product Designer.

Game Architect

Despite architecture and level design having a lot of shared elements, a “game architect” is actually a highly technical and senior role in the programming or engineering department.

 

EXCEPTIONS

Oh boy are there a lot of exceptions, but I think if you internalize this list you’ll be 90% of the way there. Remember that titles and roles usually share a lot of responsibilities. For example, on one project I was a level designer and mission designer for a one-hour chunk of gameplay, while also juggling systems design for skill trees/perks/leveling.

One of the big exceptions is that some companies still use different titles than the ones listed above, so there are still some weird cases out there that you might not recognize. For this article, I looked at a bunch of job posting at AAA companies and found titles like “Lead Gameplay Designer” and “motion designer” and an “industrial designer”. Some of these reflect unique jobs that don’t exist everywhere in the industry (ex: Valve), and others are just quirks of the studio’s organization, often reflecting specific gameplay experiences they deliver (ex: Bioware).

The Restaurant Analogy of Level Design

Today I want to talk about something that seems to confuse a lot of design students: the difference between a level designer and an environment artist.

Both a level designer and an environment artist have to work together in order to create a finished, polished, level that looks good and plays well.

ART vs. DESIGN

The level designer is most focused on “plays well”. They are trying to solve problems like:

    • What is the player doing in this space?
    • How long is the player in this space?
    • Is there combat in this space?
    • How big does the space have to be for the player (and allies) to fight the enemies (and/or bosses)?
    • Are there puzzles? Where? What is the structure of the puzzle?
    • Am I making the player traverse through the environment vertically as well as horizontally?
    • What are the different areas? Is it just one big flat landscape or are there twists and turns? Is it claustrophobic and oppressive or open and exploratory?
    • I need to put the player into a small, narrow hallway. What is the length of the hallway? Where are the turns?
    • I am hiding a piece of intel in the level. Where do I put it?
    • There will be combat in this room. Where is the enemy’s front line? Where is the player’s? How do enemies enter the room? Where do they enter from? What are they defending? Is there cover? Where? How much? What size? How close to each other?
    • Where do the doors go?

The environment artist is most focused on “looks good”. They are trying to solve problems like:

    • It is manmade architecture or organic forms or alien?
    • Is this an open space or an enclosed space? It is an exterior, with a sky and atmosphere and wind and plants, or an interior with ceilings and windows?
    • Is it a modern building? Or one in a traditional style? What style – art deco? Renaissance France? 1890’s Japan? 2090’s post-apocalyptic space station?
    • What is the texture of the walls? Stone? What kind of stone – granite? Sandstone? Concrete?
    • Are the rooms sized realistically? Are the ceiling heights normal? Are the doorways the correct size? Does the ceiling need support columns?
    • Was there battle here previously? Should there be broken glass and bullet holes and bodies?
    • Was the place vandalized? Does it need graffiti and rubble?
    • There is a piece of cover that is 4m x 1m x 1m needed for combat. What kind of prop matches the environment and this size? Is it a pile of crates? A planter? A conspicuously shaped rock?
    • What is the mood of this place?
    • What do the doors look like?

(I apologize to the environment artists who read this. I am obviously a designer and not an artist).

You need both the level designer and the environment artist in order to finish the game, and they need to work together and negotiate the aesthetics of the level.

Unfortunately, a lot of student designers are applying for jobs with subpar environment art portfolios, rather than good design portfolios. Usually these students have one big thing going for them – they have a portfolio of work created in 3D engines similar to what’s used at AAA studios (Unreal, Source, Unity). Unfortunately, their work is very light on design, and very heavy on environment art skills, but they actually aren’t trained artists.

It’s confusing to us, too, because we have to ask “So what job are you applying for again?”

RESTAURANT ANALOGY

Look at it this way: think of a level as a restaurant (a very simple restaurant for the sake of this example). To get the food on a diner’s plate, you need someone to cook the food and someone to take the order and deliver the food. We’ll call these the chef and the waiter.

If you’re applying for a  job as a chef at a restaurant, you don’t say “I want to cook the food” and then show off how well you talk to customers and refill their glasses. You don’t apply for a job to serve at the front of the house to wait on the customers, and then go fry up some bacon on your interview. Unless we’re talking food trucks, these are totally separate jobs. A manager looking for a new hire is going to think you’re an idiot if you confuse cooking with waiting tables.

The same is true for level design and art. You don’t apply for a level design job and then show off a portfolio full of pretty plants you modeled in Maya, textured in Photoshop, and then decorated your Unreal map with.  You don’t present a video walkthrough of your level highlighted the “moodiness” and “ambient sounds” and “custom animation of trees in the wind” and expect to get hired for a level designer job.

Similarly, you don’t fill your portfolio up with grayboxed multiplayer maps, combat scenarios, custom boss battles, and devilish Portal 2 puzzles and expect to get a job decorating rooms with carefully crafted rubble. (I’ve never actually seen a designer apply for an art role, though).

When a designer fills up their portfolios with art and barely a piece of gameplay, they are basically applying for a position as a chef, and then completely avoiding the kitchen.

Would you trust a chef that refused to cook for you? Would you trust a chef that didn’t know any recipes? Would you hire a chef that refused to talk about food and instead told you about that time a customer tipped them for recommending the lobster? Or how they handled the family of forty people that arrived without a reservation? If I am hiring a chef, I really don’t care. I care that you can cook.

A designer doesn’t care about polys or normal maps of what kind of stone goes on the walls. A waiter doesn’t care about the difference between a saute pan and a skillet. They care about the end result – the level or the food – but their expertise lies in different domains.

Now, there are the “food trucks” of game development – smaller studios, non-traditional studios that merge roles, indie developers that buck trends. They might look for someone who can cook and serve customers – someone who can build the level and create the art assets and maybe place sounds and fx and create simple cinematics. It’s a much rarer role these days than it was ten or twenty years ago. I’m not entirely convinced that role exists in AAA anymore. Our roles are much more specialized and well-defined these days.

So when I get a portfolio from a level designer that is full of art and moody environments and not a single puzzle or enemy or GAMEPLAY to be found, I look at them like they just applied as a chef and then started taking orders from the customers. It  tells me they don’t understand the very obvious (to me) role breakdown at a game company. It tells me they don’t understand what “design” means. It tells me they are clearly unsuited for the job.

(Unless that level is called “Dear Esther”…)

I write this not so much to rant, but because there’s a lot of students out there with portfolios targeting the wrong job. Any design student would be wise to look at their portfolios and ask themselves, “Is this a design portfolio or an art portfolio?”

What Players Do In Usability Tests

There are 17 buttons on the PS3 controller and two analog sticks with variable input. Can you name them all? Do you know what they all do? Can you remember what they do in the middle of an intense combat scenario? Can you remember how to switch weapons, switch grenades, throw grenades, shoot weapons, use alt fire, aim down your sights, crouch behind cover, strafe, melee, bring up your objectives, sprint, reload, pick up items, heal allies, craft molotov cocktails… all while getting shot at? Did you even notice you were getting shot at?!

(That’s not even getting into touch pads, motion sensing, cameras interpreting your every move, voice control, and 3D!)

We expect a lot from players. Games are complex. The more detail in your games, the more buttons, the more things the player can do in your world, and the more people you want to play your game, the harder it is to deliver something that is understandable and non-frustrating, let alone fun to play.

How a Usability Test Works

What happens from a player’s point of view:

    • You are recruited for a usability test (from various sources)
    • You fill out some questionnaire about your game habits to make sure you fit our demographic (i.e.,  you play similar games, play X hours a week, own a console)
    • You arrive at the developer or publisher and are escorted into the room with console and monitor.
    • There’s sometimes a cheat sheet on controls or a bit of backstory, depending on what part of the game you will be playing.
    • There’s a camera watching you and a speaker for someone to talk to you from a different room.
    • You play the game for 1-4 hours. You might return the next day.
    • At the end they’ll interview you a bit, and often have you fill out another survey, on what you thought, fun and frustration levels, games you’d compare it to, etc.

What happens from a developer’s point of view:

    • If the usability test is done at the studio, there’s usually a room with various leads, project managers, QA, designers, and other misc. people.
    • If the usability test is done offsite, you sometimes get a video feed you can watch from your desk while a couple leads go to the location to be there in person.
    • You watch two screens – one of the playtester in the room so you can see their expressions, and one that’s a video feed of their gameplay.
    • There’s usually a usability person there to handle most of the details and talk with the player (they’re better about not accidentally leading the player when asking questions).
    • Sometimes there’s donuts or pizza.
    • You write down notes that will turn into future tasks or bugs to fix.
    • You cry as the player takes your carefully crafted experience you spent the last two years working on and shows you all its ugly flaws.

So note, these are players familiar with the genre conventions and control schemes. They are gamers, many of whom identify as “hardcore” players, who play our games and games like ours and read about games on popular gaming websites. They represent a cross-section of regular players, not the overly competitive players, not the most expert users, not the journalists whose job it is to analyze games.

What Players Actually Do

Here’s the stuff I’ve seen in usability tests. I’ve narrowed it down to shooters specifically for this post, else the list would be way too long:

    • Find a new gun. Never use it.
    • Find a new gun. Use it and never switch back to a previous gun.
    • Play through a five-minute tutorial on alt-fire abilities on your weapons. Never use alt-fire again.
    • Pick up a grenade. Never use it.
    • Attempt to pick up a grenade, ammo drop, or extra health even though you have full ammo, full health, and full grenades. Use all your buttons to try to pick them up.
    • Attempt to pick up a piece of intel. Throw all your grenades instead.
    • Carry a heavy weapon that has low ammo and slows your character down considerably. Carry it up three flights of stairs with no combat. Spend two minutes trying to get it onto the elevator. Do this while your other three teammates wait.
    • Try to follow an objective marker, but there’s a wall between you and it. Jump at the wall. Melee the wall.
    • Jump at an indistinguishable rock for at least two minutes trying to get on top of it.
    • Immediately after starting the game, turn around and jump at the wall for at least a minute.
    • Melee doors that can’t open. Shoot doors that can’t open. Throw grenades at doors that can’t open.
    • Shoot your allies with every type of gun, grenade, and use every melee attack you can. Do this while they are delivering a passionate speech about rallying the troops, or when they are sharing a personal loss with you.
    • Stare at the floor. Especially during cinematic moments or while getting shot.
    • If you’re not staring at the floor, make sure to point your camera so all interesting events like boss intros, cave-ins, helicopter crashes, volcanoes transforming into secret military bases, ally deaths, and nuclear explosions are juuuuuust out of view.*
    • Attempt to interact with every single computer screen, box, briefcase, wire, piece of paper, light switch, and coffee mug in the room while your ally tells you to hurry up we’re under attack! Do this in the next four rooms, too.
    • Melee everything. EVERYTHING. Don’t press any other buttons than the melee button.
    • Melee bosses.
    • Melee flying bosses equipped with rocket launchers.
    • Attempt to jump on top of the flying boss enemy. Note: there is a chasm below you.
    • Melee an explosive barrel.
    • When attacking a boss, ignore the bright glowing pulsating orange weakpoint. Instead, shoot everywhere except at the weakpoint.
    • If your ally tells you, “Shoot at its eyes! Its EYES! Shoot the eyes!” shoot everywhere except the eyes.
    • If a boss has a shield, ignore the shield and just shoot the boss with your gun. Don’t try to take the shield down. (What shield? The one that’s a big blue sphere around the enemy and lights up every time you shoot it. The one your allies keep telling you about.)
    • Die a lot because the game is really hard, but don’t use the rocket launcher in your pocket or the mannable turret next to you.
    • In a multiplayer campaign, run forward as fast as you can. Don’t let anyone else to trigger those cinematic events but you. Definitely don’t wait for any of your teammates to catch up.
    • In a multiplayer campaign, walk in the opposite direction than the rest of the players.
    • In a multiplayer campaign, if the objective requires all players to pick up their new guns, do not take the gun. Ignore the other players communicating to you that the door won’t open unless you pick up the gun. Ignore the objective marker, objective text, allies pointing at the gun, dialogue telling you to take the gun, and hint text pop-ups that tell you that you cannot progress until you take the gun. Instead, wait at the door.
    • In a multiplayer campaign, when you go into a downed state, crawl away from your allies.
    • In a multiplayer campaign, when your downed ally crawls next to you and asks you to revive them and a giant red indicator tells you they are dying, run away.
    • Run at enemies. Especially if it’s a cover shooter. It’s okay if you die because you can just try running at the enemies again.**
    • Run past all the enemies. Do not engage with them. Just avoid them and try to get to the exit. Completely bypass six minutes of intense, carefully crafted gameplay with the sprint button.
    • Run at enemy turrets.
    • Run into laser beams.
    • Attempt to melee or push your allies into laser beams.
    • If a crate doesn’t break when you melee it, then unload all your ammo into it.
    • The objective tells you to “Climb to the top of the sewers.” You walk around in circles at the bottom.
    • Normally play games with inverted X-axis controls. Not Y-axis – X. Where you swap left and right. Attempt to play a first-person shooter where this is not an option.
    • Use the analog sticks as though you can only move one of them at a time. Need to move the camera? Better stop moving. Need to move sideways or forward? Don’t touch that camera.
    • Don’t move the camera at all. Do not use the left analog stick. Attempt to navigate through the level facing the same direction the entire time and rely on your teammates to describe to you how to get around cover that is in your way as you walk backwards. (This was not an isolated incident…)
    • Critique the graphics. Whenever someone asks you about gameplay, bring it back to the visuals. If the developer explains the game is a year from being shipped, continue to comment on the gray textures and placeholder cinematics.

Mind you, I am not calling players stupid. What you learn from sitting in on many usability tests is just how much you take for granted about what players know. You realize how little you’ve taught them. You realize all the different ways in which players have a bad experience or just give up in frustration.  You’ve spent two or three years working on a game and know all the mechanics and how it’s supposed to be played. A new player doesn’t.

On the flip side, usability tests can also lie. Players tend to tell you how much they enjoyed it and go blank when you ask them if there was anything they didn’t like, even though they died constantly and nearly threw the controller on the ground. Sometimes they do things they wouldn’t normally do just to see what happens because in a way they have been put on a stage to perform. Often they don’t spend as much time in exploring and completing secondary objectives because they feel pressured by time and unspoken expectations of the people in the other room.

Interpretation

For something a bit more useful, in my experience usability issues mostly fall into the following categories:

    • Player does not understand or internalize a secondary mechanic: “I spend all my time shooting enemies, but I didn’t realize or forgot there were grenades, alt fire, decoys, turrets, vehicles, or crafting.”
    • Player does not remember how to do an action or they find it too complex, so they skip it: “I know I have four guns but I forgot how to switch between them so I guess I will just stick to this one for the rest of the game.”
    • Player does an action but it is too difficult, complex, or results are inconsistent: “I dropped the grenade at my feet. While driving a vehicle to the exit, I constantly crashed it. It takes me too long to use a special gun and I die when trying to aim it.”
    • Player needs to do a specific action and does not know it: “I need to kill the boss. I am shooting it. Why isn’t it dying? You mean I need to shoot its eyes first? How was I supposed to know that?”
    • Player does not comprehend narrative moments and how they affect their current objectives: “I know we’re going to a bridge but I don’t know why. Who are these allies again? Why am I hacking this thing?”
    • Player does not understand what is or is not interactive: “I hacked a computer once before, so I should try to hack every computer I see. My objective tells me to climb but I don’t see anything I can climb on.”
    • Player doesn’t get appropriate feedback for actions or their consequences: “I died. I don’t know why I died. What killed me? Was I low on health? I didn’t even notice.”
    • Player is lost: “I don’t know where I am supposed to go. All these rooms look alike. Was I here before? The objective marker is telling me to go somewhere on the other side of this wall, but I don’t know how to get there.”
    • Player is frustrated and not having fun: “I have given up on the core gameplay so now I will just run at enemies and melee them.”

Some problems are fixed with a variety of clues (audio, visual, lighting, HUD indicators, hint text, dialogue, more granular objectives). Some are fixed by removing an element (cut a secondary ability because it’s just too complex or not useful or not fun, remove extra doors or computer consoles distracting the player from their goal). Others are fixed by adding a tutorial (gun ranges, training modes, situations where your abilities are limited and you’re asked to do very specific things, taking control from the player to show them a cinematic moment). And others we choose not to address because it’s totally okay so long as the player knows or learns the expected result (i.e. it’s okay to melee a boss enemy and die, so long as they don’t think they NEED to melee the boss and the boss reacts appropriately).

* The closer you get to seeing it without actually viewing the event, the more the developers cry.
** This is also me. I run at enemies.

“The Door Problem”

“So what does a game designer do? Are you an artist? Do you design characters and write the story? Or no, wait, you’re a programmer?”

Game design is one of those nebulous terms to people outside the game industry that’s about as clear as the “astrophysicist” job title is to me. It’s also my job, so I find myself explaining what game design means to a lot of people from different backgrounds, some of whom don’t know anything about games.

The Door Problem

I like to describe my job in terms of “The Door Problem”.

Premise: You are making a game.

  • Are there doors in your game?
  • Can the player open them?
  • Can the player open every door in the game?
  • Or are some doors for decoration?
  • How does the player know the difference?
  • Are doors you can open green and ones you can’t red? Is there trash piled up in front of doors you can’t use? Did you just remove the doorknobs and call it a day?
  • Can doors be locked and unlocked?
  • What tells a player a door is locked and will open, as opposed to a door that they will never open?
  • Does a player know how to unlock a door? Do they need a key? To hack a console? To solve a puzzle? To wait until a story moment passes?
  • Are there doors that can open but the player can never enter them?
  • Where do enemies come from? Do they run in from doors? Do those doors lock afterwards?
  • How does the player open a door? Do they just walk up to it and it slides open? Does it swing open? Does the player have to press a button to open it?
  • Do doors lock behind the player?
  • What happens if there are two players? Does it only lock after both players pass through the door?
  • What if the level is REALLY BIG and can’t all exist at the same time? If one player stays behind, the floor might disappear from under them. What do you do?
  • Do you stop one player from progressing any further until both are together in the same room?
  • Do you teleport the player that stayed behind?
  • What size is a door?
  • Does it have to be big enough for a player to get through?
  • What about co-op players? What if player 1 is standing in the doorway – does that block player 2?
  • What about allies following you? How many of them need to get through the door without getting stuck?
  • What about enemies? Do mini-bosses that are larger than a person also need to fit through the door?

It’s a pretty classic design problem. SOMEONE has to solve The Door Problem, and that someone is a designer.

The Other Door Problems

To help people understand the role breakdowns at a big company, I sometimes go into how other people deal with doors.

  • Creative Director: “Yes, we definitely need doors in this game.”
  • Project Manager: “I’ll put time on the schedule for people to make doors.”
  • Designer: “I wrote a doc explaining what we need doors to do.”
  • Concept Artist: “I made some gorgeous paintings of doors.”
  • Art Director: “This third painting is exactly the style of doors we need.”
  • Environment Artist: “I took this painting of a door and made it into an object in the game.”
  • Animator: “I made the door open and close.”
  • Sound Designer: “I made the sounds the door creates when it opens and closes.”
  • Audio Engineer: “The sound of the door opening and closing will change based on where the player is and what direction they are facing.”
  • Composer: “I created a theme song for the door.”
  • FX Artist: “I added some cool sparks to the door when it opens.”
  • Writer: “When the door opens, the player will say, ‘Hey look! The door opened!’ “
  • Lighter: “There is a bright red light over the door when it’s locked, and a green one when it’s opened.”
  • Legal: “The environment artist put a Starbucks logo on the door. You need to remove that if you don’t want to be sued.”
  • Character Artist: “I don’t really care about this door until it can start wearing hats.”
  • Gameplay Programmer: “This door asset now opens and closes based on proximity to the player. It can also be locked and unlocked through script.”
  • AI Programmer: “Enemies and allies now know if a door is there and whether they can go through it.”
  • Network Programmer: “Do all the players need to see the door open at the same time?”
  • Release Engineer: “You need to get your doors in by 3pm if you want them on the disk.”
  • Core Engine Programmer: “I have optimized the code to allow up to 1024 doors in the game.”
  • Tools Programmer: “I made it even easier for you to place doors.”
  • Level Designer: “I put the door in my level and locked it. After an event, I unlocked it.”
  • UI Designer: “There’s now an objective marker on the door, and it has its own icon on the map.”
  • Combat Designer: “Enemies will spawn behind doors, and lay cover fire as their allies enter the room. Unless the player is looking inside the door in which case they will spawn behind a different door.”
  • Systems Designer: “A level 4 player earns 148xp for opening this door at the cost of 3 gold.”
  • Monetization Designer: “We could charge the player $.99 to open the door now, or wait 24 hours for it to open automatically.”
  • QA Tester: “I walked to the door. I ran to the door. I jumped at the door. I stood in the doorway until it closed. I saved and reloaded and walked to the door. I died and reloaded then walked to the door. I threw grenades at the door.”
  • UX / Usability Researcher: “I found some people on Craigslist to go through the door so we could see what problems crop up.”
  •  Localization: “Door. Puerta. Porta. Porte. Tür. Dør. Deur. Drzwi. Drws. 문”
  • Producer: “Do we need to give everyone those doors or can we save them for a pre-order bonus?”
  • Publisher: “Those doors are really going to help this game stand out during the fall line-up.”
  • CEO: “I want you all to know how much I appreciate the time and effort put into making those doors.”
  • PR: “To all our fans, you’re going to go crazy over our next reveal #gamedev #doors #nextgen #retweet”
  • Community Manager: “I let the fans know that their concerns about doors will be addressed in the upcoming patch.”
  • Customer Support: “A player contacted us, confused about doors. I gave them detailed instructions on how to use them.”
  • Player: “I totally didn’t even notice a door there.”

One of the reasons I like this example is because it’s so mundane. There’s an impression that game design is flashy and cool and about crazy ideas and fun all the time. But when I start off with, “Let me tell you about doors…” it cuts straight to the everyday practical considerations.

Recent edits: Added localization, character artist, system designer, combat designer, composer, audio engineer, monetization designer, and I think that’ll be it for now.