Google Ventures: Not Every Product Needs to Be Beautiful | WIRED


When trying to figure out what kind of investment to make in design, technology entrepreneurs and CEOs often are tempted to focus on visual design, to create a beautiful product and a sophisticated brand with indescribably cool style.

That’s understandable in an Apple-dominated tech world. There are plenty of successful companies with gorgeous products. And visual design is the most noticeable kind of design—it is what we often think of first when we think of design.

But what about those successful companies that don’t have great visual design, you ask. They appear to have succeeded in spite of their disregard for design. And in some cases, that’s true. Maybe they didn’t have any competitors, maybe their technology was so useful that it didn’t matter how it looked, or maybe they were just lucky.



John Zeratsky is a designer and writer who’s worked on consumer, enterprise, and medical software products. As a design partner at Google Ventures, he helps startups use design successfully.

Many of the successful yet “badly designed” companies used as examples—Craigslist or Google circa 2004—chose not to focus on beautiful products, but rather focused their design efforts elsewhere, in areas more critical to their business. They were doing the right design at the right time. If you’re figuring out how to invest your design resources, you’ll want to do the same. Maybe, like Craiglist, you don’t need to create a beautiful product at all.

A Hierarchy of Design

If you’re building a new website or app, where do you begin? With the color scheme? The sign-up flow? The navigation?

No. You’ll likely start by identifying a market and an opportunity, and define a product that meets that opportunity. Once you’re confident that your product will solve an important problem for a lot of people, you move on to figuring out exactly what it should do, how it should work, and how it should look.

There’s a hierarchy of design that all great companies move through:

  • Level 1, Product Design: Create a product that solves a problem or satisfies a desire.
  • Level 2, Interaction Design: Make it easy to understand and use.
  • Level 3, Visual Design: Make it beautiful.

So, that poorly designed company that succeeded anyway? Let’s give it a bit more credit—chances are it was focused on product design, when we were expecting great visual design.

Every company makes its own decisions about where to invest in design, and when. Some companies make it all the way to Level 3. Some stop at Level 2, creating products that are functional and useful but not particularly beautiful. And others have delivered sufficient value at Level 1 that they don’t see additional design investment as worthwhile.

Three Use Cases

Craigslist: Basic product design
Craig Newmark identified a huge opportunity: use the Internet to provide free classified advertising. Because it was free, Craigslist was more attractive to advertisers, which in turn drew people who were looking for the broadest collection of jobs for hire, cars for sale, and people looking for love. The network effect kicked in, and it became very difficult for anyone to compete with Craigslist (especially newspapers, who couldn’t offer classifieds for free).

Craigslist’s product design is excellent, and their interaction design is good enough, so they haven’t thought it necessary to make further investments in design.

Uber: Started with product design; invested in interaction and visual design when necessary
When Uber launched in San Francisco in 2010, it provided a magical experience: You press a button on your phone and a car picks you up. Uber focused on getting this experience right, which meant designing the basic experience, building a balanced market so rides were always available, and maintaining high quality for drivers and cars. They were focused on product design.

Uber’s first iPhone app was pretty clunky. But it was OK—the company nailed its product design, and it didn’t have much competition.

As competition grew and the service gained features, Uber decided to invest in interaction and visual design. In late 2012, it finally launched a new version of the app that was much easier to use and more beautiful. The company has used visual design to create a high-end brand, which helps build demand throughout the market.

Square: Invested in product, interaction, and visual design from the start
Square wasn’t the first company to offer credit-card processing, point-of-sale software, online appointment scheduling, or the business products it introduced. The company had competition, and knew it wasn’t enough to provide merely functional products. Square invested in product, interaction, and visual design from the start.

The Square Reader, which plugs into a smartphone and allows merchants to accept credit card payments, succeeded on all three levels. It was the fastest and cheapest way to scan credit cards; it was easy to set up and use; it was distinctive and it looked cool.

As Square expanded its business, it knew it would face competition, so it continued its broad investment in design.

How to Do the Right Design at the Right Time

It’s easy to look back and see how successful companies have made smart investments in design based on their market, stage of life, and competition. How can you make the right investment in design for your company?

When I work with startups in the Google Ventures portfolio, one of the best things I can do is help teams identify the risks facing their business, then use design to prototype and test ways to minimize those risks.

Here are some common risk-assessing questions startups ask and some ideas for how to focus on the right design for finding the answers.

Is there a market for my product?
Focus on product design, as opposed to visual design. Build a basic product (or the marketing for a basic product) and test it with customers. Every new product and feature should start here. Once you’ve established the market need for what you’re building, you can assess what kind of design investment makes sense next.

Can we compete in a crowded market?
Good product design alone may not be enough. Unless you can figure out a new business model (as Craigslist did when it offered free classified ads) or a new way of attracting users (like Facebook did by conquering college campuses), you’ll need to focus on interaction and visual design. Talk to your competitors’ customers and look for opportunities to offer products that are more useful, easier to use, and better looking.

Will people trust us? For products where trust is very important, you may need an early focus on interaction and visual design. Two financial-services startups in our portfolio, LendUp and OnDeck, followed this playbook—their products succeed at Level 1 (better rates, faster approvals, etc.), but they made significant investments in interaction design, visual design, and copywriting to help build trust with customers.

Can we add features to our product without alienating customers?
At some point, most companies will face this challenge: How to add features to a product without confusing or frustrating customers? Companies who successfully grow their product’s footprint invest in design across all three levels. At Level 1, new features need to be useful. And at Levels 2 and 3, these features need to fit a framework or mental model that makes sense to customers. Like Apple has done with iOS, you need broad investment in design to add features successfully without frustrating your customers.

It’s OK to Focus

As a designer, I’m impressed by companies who invest and succeed at all three levels of design—their products are useful, intuitive, and beautiful. I’m often tempted to encourage startups to make the same type of investment in design. But after working with close to 100 startups in the past few years, I know that’s not always the right advice. Startups have limited time, limited money, and small teams, so they can’t do everything at once.

There are different kinds of design, and you will need to decide what kind of design to focus on at your company, and when. These decisions will influence who you hire, how you work with design agencies, how you set goals, and the priorities you set for your company.

You may not be able to invest in product, interaction, and visual design all at once. But by looking closely at other companies who have succeeded, and at your own risks and challenges, you can do the right design at the right time.

Go Back to Top. Skip To: Start of Article.

Google Ventures: Not Every Product Needs to Be Beautiful | WIRED.

Don’t Miss: What does a game designer do, exactly?

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


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.


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


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.


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.


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

Reposted from:

Source: Don’t Miss: What does a game designer do, exactly?

Turning Feelings Into Mechanics — The narrative design of Apartment: A Separated Place – by Richard Emms


This is an article about the design process behind a•part•ment: a separated place, which is now nearing the end of its Kickstarter campaign. It was written by The Elsewhere Company’s Robyn Gray and Richard Emms, with collaborator Raghav Bashyal. a•part•ment is currently in production. You can find out more on our website.



a•part•ment: a separated place is a game about relationships. It’s an interactive narrative with an emphasis on conveying story through text and using different, character-centric mechanics. The main character, Nick, mopes around the apartment he shared with Madison, his now ex-girlfriend. The player gets to experience Nick’s reflection on his time with Madison and his journey through the post-breakup process.

But Nick is not alone. About half the game takes place within his apartment, while the other half explores the lives and relationships of Nick’s neighbors. The neighbors are all at different stages of life and have different relationship-related issues. There’s a struggling pair of newlyweds, a man who feels detached from society, a widow, and an estranged father and daughter.

After a failed experiment in almost purely branching dialogue, we moved in a character-driven direction. We chose an immediate impetus for our players — you just got dumped, now what do you do? The characters in this apartment complex had already been designed and developed thanks to the previous game iteration, so we decided to create short interactive experiences reflecting their individual lives. We structured the game with Nick’s breakup at the center and the neighbors orbiting (and reflecting) his situation.

a•part•ment is a collection of interactive vignettes. Nick and Madison’s story and environment serves as an anchor or hub to the game’s narrative. Each neighbor’s story is told through a number of different interactive vignettes. Upon completing a Nick and Madison portion of the story, players then enter a neighbor’s vignette. On completing that vignette, they return to Nick and Madison’s story and so on.

One of our biggest questions when we approached a•part•ment was how we could take an everyday story and make it compelling to play. It’s common to make a game “fun,” but we didn’t intend for a•part•ment to be action-packed and skill-based. It’s also common to write a dramatic script, but adding interactivity begs so many questions that don’t have definite answers. What should players be doing as the story unfolds? Should they be controlling how the story reveals itself, have agency over the lives of the characters? Who is the player in this situation? Our game’s premise was very different from most games we’d encountered. We realized we had to do some deep narrative and gameplay exploration to figure out how to do our characters’ stories justice in a game.

Tugging at the Heart Strings

a•part•ment is a game about relationships, a theme that is only recently emerging in the game development community. The relationships we have in life, even the ones that end poorly, shape us as people. They can change how we think and the way we do things. They can introduce us to new ideas, new hobbies, new tastes. Even if a person exits your life, they leave footprints behind.

Nick and Madison’s story and the stories of their neighbors revolve around this concept of footprints — about the ways your relationships irreversibly change you. a•part•ment is not only about romantic relationships: it’s about the universal feelings and experiences we share in all kinds of relationships. We wanted to design mechanics that would evoke strong emotions in our players and allow them to relate their own experiences with those of our characters.

Translating feelings and moments into playable experiences is a challenge. After we scrapped our original branching narrative approach, we decided to play to our strengths. In this case, that meant rapid prototyping. The previously developed cast of characters was our primary constraint. We wanted to design narrative-centric prototypes that strongly conveyed each character’s emotional state.

Step Into Their Shoes

The best thing about prototyping — and why a•part•ment eventually evolved to have a modular structure — is that this approach gave us absolute freedom to develop different experiences for different characters. Each of our characters has a different background, relationship, and problem — it was only right that their individual vignettes reflect these differences.

When initially developing these characters we created biographies, concept art, and short stories. Some of these pieces were about the playable relationship-related moments in the game, while others were explorations into other times in their lives. These explorations allowed us to flesh out their personalities further. Our writing exercises helped us define who these characters are outside of their relationships. Defining their histories informed our narrative design process, so we could craft mechanics and aesthetics that reflected who the characters are and how they react to their experiences.

For example, Rose is a novelist. The fact that she is a novelist is one of the causes of her relationship woes, but not the direct cause. It is part of her identity but it is not the focus of her story in a•part•ment. It did, however, serve as the inspiration for the mechanic behind her first vignette.

Rose Wright: The Uncertain Newlywed

Rose’s first vignette was the second prototype we created for the game. This part of her story was inspired by two key facts:

  • Rose is a novelist.


  • Rose has difficulty balancing her time between her spouse and her career.


The process of writing is wonderful and horrible. Moments of flow where the words just come to you are magical; writer’s block, on the other hand, is awful. But the moment when someone — your mom, your child, your significant other — interrupts what you’re doing (even if it’s just to ask if you want a cookie) is the worst.

Rose’s first vignette was originally a two-part design. We wanted the player to be Rose while she’s writing her next great novel. That meant coming up with a mechanic for writing and a mechanic to mimic flow.

In Rose’s first vignette you literally type her novel. You are shown a few shadow letters ahead, giving you a preview of what to type. The more accurately you type, the more characters are revealed. After typing a sentence or two you’ll hit the “Return” key and an entire paragraph will fade in, finishing the passage for you and rewarding you with content. With playtesting, we managed to find a good balance between the amount of typing and the story payoff.

But we didn’t want to just create a sense of in-game writing flow. We also wanted to interrupt that flow. Rose’s loving but off-screen spouse is a steady interruption. You’ll be typing away, getting into the task and the story you’re writing, when suddenly —

Alex kindly offers you a sandwich. No, I’m writing a novel! Go away! In order to dismiss the interruption we force you to take your hands off the keyboard, grab your mouse, move the mouse to the outlined red button (its location changes each time an interruption occurs), and click on it from anywhere between one and six times.

Intertwined with the typing and interruption mechanic are two concurrent stories. There’s the story you’re writing as Rose — a romance about a woman deciding whether or not to marry her current beau — and the story of Rose and Alex. About halfway through the experience, an additional twist to the Rose and Alex story emerges in the form of simple text messages. It alters the thread of the novel Rose is writing but, more noticeably, alters how players view Rose and Alex’s story and the way they treat the two characters.

The best part of this system is how genuinely players react. As they get closer to the vignette’s finale (and the end of the story Rose is writing) they get more agitated. They click that “NO” button as fast as they can. We’ve had players confess that they felt guilty because Alex is clearly trying to be nice — but damn it, they were trying to write a novel!

Jim Spencer: The Displaced Loner

From the outset, Jim was always a lonely character. When we began writing and working on a prototype about him a lot of our classmates, including us, were in a similar position to him. We’d uprooted ourselves from our previous homes to begin our graduate program at USC. Jim’s story captures moments we experience when we’re trying to carve out a new place for ourselves.

Jim’s first vignette was our first prototype for a•part•ment. His story is one of isolation and the depressive state that can come from it. We needed to find a way to evoke in players the weight of detachment and a creeping feeling of disquiet.

To create a strong sense of isolation and disembodiment we adjusted the first person controls. You feel like you’re floating, weightless, through the hallways of a darkened apartment. You don’t quite feel like a person — more like a ghost peering in on Jim and his troubles. We adjusted the first-person mouse and keyboard controls to slow everything down, encouraging players to read and reflect. The weight of the controls is unique to Jim and closely matches his lonely, depressed emotional state.

Visually we created a hollow aesthetic using a dark, desaturated palette. We draw attention to story beat locations with brighter colors. The sink, which contains the first mandatory piece of story, is light gray and directly visible at the end of the first hallway.

We also put in a dense pink fog far away from the player, inviting them to distant areas with a slightly warmer, brighter hue. It promises a relief from the oppressive darkness of their immediate surroundings, but the fog always clears as they approach to reveal the same dark spaces no matter where they visit.

Aurally we peppered the soundscape with sparse piano and guitar riffs. This creates a sense of emptiness with its pacing and a sense of melancholy with its somber tones. We also used music in space as a mechanic to direct player attention. We found these 3D audio cues were vital to guiding the player’s focus and informing them that new text had appeared.

All of this is in direct contrast to Nick’s apartment, where we use a range of colors and music is playing constantly. This really brings home the lifelessness in Jim’s apartment, and makes returning to Nick’s apartment a breath of fresh air. Nick’s environment reflects his strong feelings over the end of his relationship, whereas Jim’s environment gives the sense that he really isn’t feeling much more than a dull emptiness.

Words fade in and out of existence on the walls and floor, presenting Jim’s memories and feelings as you travel through his space. The word “drip” appears accompanied with a dripping sound — a noise that plagues Jim. We mimic how terrible the sound of a drip in an empty apartment is, how it rings through and holds power over your mind. “Drip” appears in your view with a regular, unending cadence, haunting the player in the same way it haunts Jim.

About halfway through the experience players find the source of the drips: the sink in Jim’s kitchen. The word and sound cease as players turn off the faucet, a satisfying moment of resolution. But later the dripping returns —

“Somewhere in the space his sink dripped, a sound that plagued him beyond irritation. It seemed, instead, to feed the empty feeling.”

This time players can again see the drip appearing in front of them, yet there’s no audio accompaniment. Is the sound just in Jim’s head? Is it a sound he’s merely anticipating? It’s a moment we’re familiar with, when we strain to hear this chronic sound of annoyance that just won’t happen.

We’re shown Jim’s innermost feelings throughout the entire experience but everything is written in third person, letting us know that we’re not Jim. The entire vignette culminates when he appears while you’re looking at a dead-end corner near the final part of the experience. When you turn around he’s suddenly there, curled up and motionless, ignoring your intrusion. Jim is no longer just a collection of thoughts or an empty apartment. He’s suddenly a physical presence sharing this space with us. The feelings we have been ruminating over for the entire experience are given an owner, which makes them suddenly quite overwhelming. No sooner do players join Jim, then they’re forced to leave him behind as the vignette ends and they are returned to Nick’s apartment.

May Tipton: The Grieving Widow

May’s character is loosely based on Robyn and Raghav’s grandparents. She is 80 years old, lives in an apartment by herself, and is dealing with the death of her husband, William, after a 60-year marriage.

May’s story is told in three vignettes. Her vignettes are simple in gameplay; in each one, you walk through a series of scenes in a linear fashion while reading text along the way. What’s interesting about these vignettes is that the transitions between the scenes are cuts.

In this example, the game cuts from a scene where you’re driving a car to a scene where you’re walking in a snowfield.

Each of May’s vignettes explores different ways to create cuts in games. May 1 cuts back-and-forth between first person and third person. May 2 cuts between first-person scenes. May 3 cuts between third-person scenes. The main challenges were figuring out how to cut from scene to scene without:

  1. Jarring the player’s focus
  2. Making the player lose control of the character
  3. Confusing the player about the narrative of each vignette.

Raghav developed several scene-cutting techniques to solve these problems and implemented them in May’s vignettes. You might be thinking, what’s so cool about cuts? It turns out they’re a very versatile tool. Cuts are useful as a transitional tool for taking the player from one place to another without making them take the time to walk, or use an ill-contrived door.

How can we cut from third person to first person?

During this scenario the player starts an action in one scene and continues it into the next. In this case, they are moving forward in the first scene and continuing the motion into the second scene. It is notable that, though the control scheme differs between the two scenes, the button that moves the character forward is the same (the W key). You can read more about this and other techniques in Raghav’s thesis paper linked below.

Cuts are also useful for creating powerful or delicate emotional moments from the juxtaposition of two scenes. Take, for example, this cut from May 1.

The player is driving, then suddenly walking in a graveyard. Notice that the signpost fills the screen, serving as a wipe before the cut occurs.

If you ever sit down to watch a Twitch stream of this vignette, you’ll notice that the chatbox erupts in morbid understanding right after this cut. The streamer will wince. “Oh no…” they’ll say, “he’s dead.” The use of a cut here reveals information in a way that surprises and shocks the player.

So why are cuts so central to May’s character? Her story covers a large swath of time — 80 years — and cuts allow us to cover that amount of time efficiently. They also let players experience May’s thoughts the same way she experiences them — jumping from one moment to another.

May 1 is a rumination: a dreamlike collection of flashbacks that illuminate May’s relationship with William. This dreamlike quality comes in part from the painterly visuals (May herself being a painter) and in part from the cuts, which allow each scene to take place in a different time and location.

May 2 is similar to May 1 in that its scenes are dreamlike, but differs in that the scenes are not memories: they take place in the present. It does not tell a story so much as it tells a poem. The player walks around in first person reading May’s thoughts as she travels from her apartment, to the roof, to the forest, to her bedroom. The vignette mimics a lonely consciousness. The cuts are softer — each scene takes time to dissolve into the next, giving the vignette a slow, surreal quality that reflects her loneliness.

May 3 utilizes the power of cuts to the fullest. The vignette was a response to the prompt, “70 years in 7 cuts.” The final version of the vignette contains a few more cuts than 7, but succeeds in taking the player through May’s childhood, adolescence, adulthood, old age, her loss of William, and beyond — a look at her entire life in a span of 2 to 4 minutes.

Their abilities to transcend time and space make cuts a unique tool both in the designer’s toolbox and in the storyteller’s. Cuts give May’s vignettes their distinct flavor — they feel like dreams or memories: the gameplay equivalent of watching someone’s life flash before their eyes.

To read more about cuts in videogames, check out Raghav’s thesis paper titled No Jump Cuts.

Tying the Threads Together

Developing a•part•ment has been unique because each vignette’s design process has been different. We’ve only outlined some of them here. The overarching modular structure of our game offers us the freedom to give every vignette a unique format, allowing us to tell each story in the way that suits it best. Each vignette can be a standalone piece, yet the experience is strongest when the game is played as a whole.

“By weaving these other threads into Nick’s story, a•part•ment seems poised to be about more than just one person’s breakup. It seems to be concerned with how contemporary life can make any of us feel stuck in separated places, and perhaps in exploring and illuminating our shared isolation, it can suggest a different kind of connection.”

– Carolyn Petit, “Separated Places”

a•part•ment: a separated place will be released on Steam in Spring 2016. We’re currently approaching the end of our Kickstarter campaign, which you can check out below. We hope this article on our design process is helpful. Thanks for reading!


Source: Turning Feelings Into Mechanics — The narrative design of Apartment: A Separated Place – by Richard Emms

Postmortem – Invasion 101: Perception (Mobile VR Game Jam) – by Kyle D’Aoust

Invasion 101: Perception is essentially “Where’s Waldo?” for mobile VR. It was developed by a team of three developers consisting of two artists and a programmer(myself). We made this as part of the Oculus Mobile VR Game Jam. The Game Jam durations was one month with a milestone due every week to show progress and push along development.

Game Description

There are playable maps, multiple difficulties, and a highscore table. The objective of the game is to find a specific object from the clue that’s given. In the game maps there’s a UI board that shows time, score, and the clue for the object. The clues are the primary color of the object, the first letter of the name of the object, and a number representing an amount in a group of objects.
Starting the game shows a “How to Play” menu with a description of the clues and gameplay. The game is played only with the touchpad on the side of the GearVR and your head to look around the map. To select an object you simply look at it and tap the touchpad. Correctly matching objects earns you points, while incorrect ones gets you nothing.The Bedroom level, showing the in-game UI as well.

What Went Right

Playable Prototype since Day 1

Since the game had no locomotion, the main chunk of work I had to make was the class for items so the game knows the characteristics of the item. Prior to actually working on the game I had already known exactly what was needed to create the class so by the end of the first day of development, I had a playable demo with the core mechanics. You could select objects, gain score, and had a timer that ended the game when it ran out.


I had been initially worried about creating a complex and/or really great looking game since the Game Jam was about making a VR game on a mobile platform. Making a game for VR on a phone can make any great idea difficult to do without killing the phone or a terrible experience for the player. So I had told the artists to focus on textures and have lower poly models to ensure a silky smooth 60+ FPS game.
The game was also entirely done on one Unity scene. I had set up different “Scenes” within that scene by enabling and disabling objects. By loading all of the objects at once in the beginning, I didn’t need to deal with loading screens and memory build up.


During the early playtesting periods it was obvious that this game needed a crosshair. Doing a crosshair in VR is actually challenging at first. You can’t simply slap it in the middle of the screen like in non-VR games, you can’t see it unless you move it away from the player. You also can’t just have it floating x amount of distance from the player. Not only would it visibly clip through objects in the world, everyone has a different Interpupilary Distance(IPD) which could cause the crosshair to not be usable for some people.
To solve this problem you would need to have the crosshair tied to the center of the cameras and have it move to the point that the player is looking at while keeping a visible scale, essentially like a laser pointer. Initially this wasn’t an easy task, but after looking around the community I found someone who had made a tutorial for a VR crosshair. eVRydayVR had made a Unity tutorial for making a VR crosshair which helped a great amount.

Easy Build Iterations and Playtesting

This was actually my first time at mobile development, so I wasn’t sure how to go about building and testing the game. I had followed a presentation by Mark Schoennagel about setting up Unity with the Samsung GearVR for development. What it came down to was just plugging in my Note 4 USB charger into my computer, hitting the Build/Run button, then plugging my Note 4 into the GearVR. It’ll automatically start the game you just built, as well as install the APK onto your phone to play whenever you want.The School level, non-textured with random colors upon each playthrough.

What Went Wrong

Game Design

For mobile VR you have a choice of using a gamepad, the touchpad, or a combination of the two for input. Since we didn’t have a gamepad to use our only option was the touchpad, which presented a roadblock for us in the original ideas we wanted to go with. We weren’t entirely sure about how to create a fun VR game with just a touchpad, which I think held us back in creating a fun idea.

Rebuilding the Project

For about half of the Game Jam I was building the game in Unity 5, which does work with the GearVR but has some bugs. I didn’t experience these bugs until we imported the actual art for the game. The main bug that was present was texture bleeding. Essentially moving your head left or right would make random textures from one object to be mapped onto a different object. This was something I couldn’t figure out until I remembered Oculus warning us about some minor bugs using Unity 5. So I rebuilt the project in an older Unity version and it fixed the problem. This could’ve been avoided if I had experienced the bug earlier on, or even just heeded Oculus’ warning.


One of our artists had a vacation planned out of country for a week long before the game jam, which happened to occur during the last week or so of the jam. So while he had completed his work before he left, some stuff needed to be fixed while he was gone and he wasn’t able to do it until he got back on the last day of the jam. This wasn’t too much of a problem, but it did add a little extra stress on that last day crunch. We also had sporratic meetings during the jam due to time constraints, we still got the work done for the milestones but I feel we could’ve had a stronger project with better communication.

The Future

Now that the Jam is over and the finalists have been selected, we’re looking forward to doing another project. Not only are we all motivated and inspired to work on something new, we’ve added another artist to our growing team. This has been a learning experience not only for us, but for every developer in the Jam. We’d like to thank Oculus and Samsung for bringing this Game Jam to life, creating hundreds of games and experiences for a platform that not too long ago didn’t exist.
For more information on our upcoming projects, follow @kdd9000 on Twitter.


Source: Postmortem – Invasion 101: Perception (Mobile VR Game Jam) – by Kyle D’Aoust

Discussing Positive False Choices in Game Design – by Josh Bycer

The last time I looked at false choices in game design, I talked about options that were across the board weaker than your other available options rendering the choice meaningless. For today’s post I want to expand on that discussion with a talk about the same problem but from the opposite end of the spectrum when a choice is too good.

Beyond Earth

Positive False Choices:

The idea that a choice could be too good sounds like a weird complaint as you want the player to have options that are great. The problem is when the choice is so good that it becomes required due to how useful it is. Similar to our talk last time, these false choices punish the player for not choosing them while the previous post talked about options that punish you for choosing them.

To help designate the two types of wrong choices, we’ll refer to the positive examples as positive false choices and the negative ones as negative false choices for this post. A positive false choice can typically be seen in strategy guides or min-max suggestions where the person says that one choice should always be used or one set of instructions that work the best every time.

That last line is very important as that is what separates having the player decide between good options and having something as a positive false choice — If the choice is always the superior option then it can be considered a positive false choice as you always want to take it.

game design

Here’s an example of this from Payday 2, before the skill overhaul each of the classes had bonuses that unlocked for putting X amount of points into respective skill trees.

The technician class had a bonus where you could get 25% more headshot damage for going up it. Obviously this was very useful on the higher difficulties and became the go-to tree for players just for this one option.

As you can see, this choice was superior because it was useful no matter what build you were, what weapons you used or how you played the game. And because this was always good, it became a positive false choice. What the developers did to fix that was to move it to the newly created perk system and now any player can easily get access to the bonus no matter what their play style is.

Since positive false choices are complete opposites of negative false choices, so is the best way to spot them while play testing your title. Unlike a negative false choice where every player will avoid it, a positive false choice is when every player will choose the same option every time no matter what. If you’re trying to make the player decide between choices, one shouldn’t always be the superior option. But figuring out a positive false choice can be difficult as there is more than one kind of choice in games based on how the games are played.

Required vs. Optional Choices:

The problem with trying to determine if a choice is a positive false choice is that depending on how your game is designed, some choices may be required simply by the nature of the mechanics. For instance in Payday 2, because the game has both stealth and loud levels there are some skills that are just plain required for effective stealth such as increase crouch speed and quieter enemy take downs.

In this case the stealth skills appear to be positive false choices because you need them in order to stealth effectively. However because they are a foundation of the stealth gameplay, you’re going to have to take them in order to make use of that specific mechanic. When something is specialized like that, then it’s not a positive false choice as the player is limiting themselves in some other aspect in order to make use of it. As a stealth player in Payday 2, I can’t repair drills as quickly or get the best armor due to my choices with build selection.

By doing this, it means that my skills range from being okay to great depending on the situation, which is what you want your choices to do. For an example of what not to do, we turn to Civilization Beyond Earth.

In the retail version of the game, you could set up trade depots with nearby cities or stations for bonuses. The research was pretty cheap and the units didn’t take that long to build. Once a supply chain was established, you’d receive constant bonuses from it with the only thing to do was restart it after a certain amount of turns. Here, the option to set up trade depots is always good no matter what the situation is and the onetime cost to research and produce is outweighed by the benefits they provide.

game design

With the trade depots, I’m not limiting myself in some area by taking it, so they’re a win-win with no downsides and therefore the use of trade depots is a positive false choice.

Another sure sign that you have a positive false choice is if your player base says that they will not use certain items or choices to make the game harder. If a choice in your game is one that is so instrumental to play that people avoid it for a handicap, then you have a problem.

Choosy Choices:

Good game design is not about giving the player positive false choices but having them decide on what they feel is the best course of action. A good set of choices is about challenging the player to adapt to the gamescape and situations, not reading a guide and following a check list.

Usually the ways to fix a positive false choice are the same as a negative — either tweak the choice or tweak the other choices in the game. But you need to be careful as weakening a choice too much may make it too situational. If something is only good 1 out of 10 times and the rest of the time worthless, then you’re just creating another negative false choice.

Variety may be the spice of life, but you can have a case where there are just too many choices without any real value to them. If all your choices are based on incremental or not noticeable effects like +2 attack or +1 health, then the game will lack depth. It’s like being asked to choose between a high jump and a tall leap.

Good choice design is presenting the player a balanced number of options, so that there is variety while making them viable as well . No one choice should be superior/the worse and if you can nail the balance right, you’ll have one very interesting game.

( Check out Game-Wisdom for posts, podcasts and videos on game design and the industry)

Oculus acquires Surreal Vision, a startup that brings the real world to VR

Oculus VR has acquired British startup Surreal Vision, which works with “state-of-the-art 3D scene reconstruction algorithms” to recreate the real world inside VR. This technology should allow those immersed in VR to interact with their real surroundings; it also opens up the possibility of blending the real and the virtual.

The London-based team will become part of Oculus’ research arm.

The technology may put Oculus more in line with its competitors — whether they be augmented reality solutions like Magic Leap or Microsoft’s HoloLens, or Valve’s Vive headset, which at a basic level communicates the limitations of your movement in the real world within its VR simulation.

Facebook’s Mark Zuckerberg has been up-front about his expectations for the potential of Oculus since his company’s acquisition of the VR startup, suggesting that the tech has mainstream, real-world potential beyond games. This acquisition may be a piece of that puzzle.

What does the company do? It’s summed up by a statement from Surreal Vision in the announcement on the Oculus blog, which we’ve excerpted here:

“At Surreal Vision, we are overhauling state-of-the-art 3D scene reconstruction algorithms to provide a rich, up-to-date model of everything in the environment including people and their interactions with each other. We’re developing breakthrough techniques to capture, interpret, manage, analyse, and finally reproject in real-time a model of reality back to the user in a way that feels real, creating a new, mixed reality that brings together the virtual and real worlds.”

Source: Oculus acquires Surreal Vision, a startup that brings the real world to VR

Adult Swim launches its first VR entertainment project: The Virtual Brainload, with WEVR


Cable animation/comedy/weirdness network Adult Swim is “reaching beyond the television screen to invite fans to immerse themselves in a bodiless journey of the mind with a virtual reality experience unlike anything else in the marketplace,” blurbs a press release we received today.

They have some pretty popular mobile apps out already, but this is their first crack at VR. The network teamed up with Venice Beach-based virtual reality firm WEVR to develop The Virtual Brainload [download on Google Play]. The VR app promises to take viewers “on a visual and sonic trip through outer space.” Dude.


From the network’s announcement today:

The Virtual Brainload is available now as a free app on Google Play and ready for launch with the Google Cardboard headset, which must be purchased separately. Previously only available as an in-person experiential activation with the Meatwad Fulldome Experience, The Virtual Brainload meets fans where they are with a dazzling animated presentation that gives a special glimpse of the backside of reality.

This initiative is Turner Broadcasting’s first release in the virtual reality sector and provides new and unique opportunities for creative development, programming and advertising. It kicks off an ambitious network expansion into this exciting new space, with plans for deeper, custom-created content to roll out later in 2015 and beyond.

“We know our audiences are early adopters and we aim to surprise them with new experiences like this,” said Jill King, senior vice president, consumer and partnership marketing, Cartoon Network, Adult Swim and Boomerang. “As we develop immersive content for our fans, we will keep our advertising partners front of mind and seek out opportunities to extend their brand into these experiences.”

Press Release Translation: This VR shit costs real money to produce and we have no fucking idea how we’re gonna make bank from it yet, but yo big brands, we are very eager to place your logo all up in this biznatch and take your sweet analog bitcoins.


I haven’t tried it out, and don’t have the gear required. But any app that requires this sort of legalese at the download link sure sounds fun:



The Virtual Brainload [adult swim]


Source: Adult Swim launches its first VR entertainment project: The Virtual Brainload, with WEVR

Design 101: Complexity vs. depth





Welcome back to Design 101. If you missed the first installment, you can check it out here. Today we’re going to talk about one of the most controversial topics in game design: Complexity. Since time immemorial, arguments about this subject have raged through design teams and gamer communities alike.

Does removing complexity “dumb down” your game?  When is complexity a good thing, when is it bad? Why do so many game designers treat complexity like a boogeyman to be killed, when a lot of players love it? There’s a lot to get into, so let’s get started.

What is Complexity?

As with many ongoing arguments, the controversy arises from a misunderstanding. Like many words in the English language, people use the word “complexity” to refer to several different things at once. As game designers there are three distinct types we care about. They are Comprehension Complexity, Tracking Complexity and Depth.

Why three types? Because each creates a very different player experience.

Comprehension Complexity – The Bad Kind

Comprehension Complexity refers to how difficult it is for the player to understand what the designer is communicating. This might be how difficult it is to understand a rule, a unit’s abilities, a mission objective, an interface or any number of other things. Here’s an example:

Take a moment and try to figure out what that form is actually saying. It takes some mental gymnastics. You probably find yourself re-reading it multiple times, trying to isolate certain fragments and generally feel like you’re mentally “untangling” something.

This takes a significant chunk of mental energy and can create a sense of feeling “lost”. The more mental energy we spend on figuring out what the game designer is trying to tell us, the less we have to spend on enjoying the game (especially if your game involves a lot of strategic decisions).

While the comic strip contains an extreme example, it’s not too far off from what a lot of games do. Many games are full of impenetrable instructions, counter-intuitive rules and multi-step interactions. Usually these aren’t as severe as the Dilbert example, but a reduced negative experience is still a negative experience. Dumping a spoonful of salt in your players’ water might not be as bad as filling the glass, but it’s still a distasteful experience.

Tracking Complexity – The Other Bad Kind

Tracking Complexity refers to the task of mentally keeping track of multiple things at once. Let’s do an experiment. I’m going to list 10 names, and I want you to remember all of them while reading the rest of this section. Here goes, “Alex, Jason, Kate, Michael, Wendy, Charlotte, Wan, Steve, Elizabeth, Jordan.” Got them all?

The process of trying to keep all those names in your head is probably causing you some mental strain right now. It’s probably making it harder to focus on this text as you’re reading it, and this text is the fun part. We’re talking about game design! I’m reducing your experience by asking you to remember all those names while reading this. Are you jumping back to keep checking them all? If you are, that’s breaking your flow.

Have you just given up and decided to keep reading? That means your brain has been overloaded, which is my fault as the writer of this article. You’ve decided to quit the task because the strain of mentally tracking all those names is sapping your enjoyment of what you actually came here for. Did you spend several minutes committing those names to memory before reading? If so, you’re probably in the minority and doing so messed with the overall pace of the article. All these things are negative effects on the reader’s experience.

Alright, stop trying to keep those names in your head if you haven’t stopped already. Unless you’re a person that enjoys memory games, that process probably felt like a mental strain. Unless my design goal is specifically to create that experience in the player, adding the mental strain of asking players to keep track of multiple things in their heads at once isn’t helping my design goal.

For most projects, you’re going to want to avoid forcing your players to mentally track things whenever possible. Every time you include an effect like, “Whenever a creature is played next to a lake, gain 1 life” in your game, the gameplay might be great but there’s a cost in tracking complexity. Each of your mechanics might be worth their tracking complexity on their own, but taken together they might overload your players’ brains.

Depth – The Good Kind (Mostly)

Comprehension Complexity represents how hard it is to understand how everything works.Tracking Complexity represents how hard it is to keep track of what’s actually going on. Once you’ve got all that, Depth represents how difficult it is to figure out the best possible move.

We hear Depth talked about most often in strategy games, but it exists whenever players have to make a decision based about what to do. This applies to options for character-building in an RPG, map control in an FPS, raids in an MMO, item building in a MOBA and much more.

Let’s talk about strategy games for now, because they’re the elephant in the room. Designers might be willing to accept that Flower and Dance Dance Revolution don’t need much depth, and so they’re fine with limiting complexity overall. On the other hand, Strategy games live and die on how engaging their decisions are. Isn’t removing complexity from a strategy game a bad thing?

This is where our definitions come in handy. Once you know what the factors involved in a decision are (Tracking Complexity) and understand your options (Comprehension Complexity), you finally get to start evaluating those factors and determining the correct play. This is the fun part of the game.

Here’s where the controversy comes from. People that claim to want more complexity. and are against, “dumbing down the game”, are usually defending Depth. People railing against it are usually trying to cut Comprehension Complexity and Tracking Complexity. There really isn’t a disagreement here.

Unfortunately many people perceive all three aspects as a single concept “Reducing Complexity”. Players thinking about Depth naturally don’t want to see it reduced. People thinking about Comprehension and Tracking complexity naturally want to cut it down.

How do we resolve this?

The Crucial Point

Comprehension Complexity and Tracking Complexity are almost always bad. They produce negative experiences for the player that push them away from the fun parts of the game. Unfortunately, it’s not possible to get rid of them entirely. Chess needs to have rules (Comprehension Complexity), and its pieces need to threaten other spaces on the board (Tracking Complexity). You’re going to have to include some of these negative aspects in your game.

Complexity is like a budget for your game design. You always want to cut unnecessary expenses and find ways to get the same result more efficiently. An ideal game meets its design goal while creating as little Comprehension Complexity and Tracking Complexity as possible.

Design Tool – A Tie-Breaker

This leads me to a useful tool. Last time we talked about how a clearly articulated design goal can help you decide which design choices are better for your game. However, sometimes you’re going to run into situations where you aren’t sure which choice is truly better at supporting your goal. When I run into these situations, I use the following tie-breakers.

First ask yourself, “Which of these options creates less Comprehension and/or Tracking Complexity for the player?” Since you aren’t sure which option is going to better support your design goal, go with the option that you know will create fewer harmful side-effects.

Second, if both options are equally simple for the player, ask yourself, “Which of these options is easier for the developer?” All else being equal, pursue the option that will be less work for you. You can spend that extra time and energy improving the game in other ways.

You might also run into situations where you aren’t sure whether adding something to the game is going to justify the Comprehension or Tracking Complexity that comes with it. In this situation, always go with the less complex option.

There are several reasons for this.

  1. While it’s easy to be wrong about how enjoyable something will be, you know for sure that lower complexity is a good thing

  2. It’s much easier to add complexity if needed than it is to remove it later.

  3. It’s better to try the game with the less complex option and see if it still meets your design goal. It’s very difficult to imagine the less complex version in action once you’re used to the complex one.

  4. You know your game pretty darn well. If you think it’s the right level of complexity, it’s probably going to be a lot more complex for the player. The Tappers and Listeners experiment shows how hard it is to tune out your background knowledge.

  5. You’re going to be biased to keeping your ideas in your game. Humans are naturally loss-averse, and it’s very hard to cut your own cool ideas. If you’re not 100% sure that the feature is worth the complexity, this bias ensures that it almost certainly isn’t.

  6. You might be seriously worried that the game simply won’t be deep enough to meet your design goals without the added complexity. That’s a valid concern. And yet every single time I’ve been worried about this and ended up trying the less complex version; the game has still had more than enough depth for its design goals. Not once have I ended up adding the complexity back in.

Wrapping Up

If your gameplay is a candy bar, then Comprehension Complexity and Tracking Complexity are the wrapper. Candy bars need wrappers. If they didn’t have them they’d be pretty darn unsanitary. However, you want your wrappers to be light and unobtrusive, ensuring the candy itself is easily accessible. Imagine if they put candy bars in the kind of nigh-indestructible plastic packaging they trap electronics in.

Don’t do that to your game. You’re better than that.

See you next time.

Source: Design 101: Complexity vs. depth

Learn how to design user interfaces from the masters

Blizzard surprised the gaming community when they took a left turn and released a digital card game, Hearthstone, after their wildly successful World of Warcraft. Hearthstone scales beautifully with skill level. The success of the game can also be attributed to it’s elegant UI. You can now watch a video from the designers of Hearthstone’s UI and learn from the masters at the GDC Vault.



Source: Gamasutra – Video: Designing an immersive user interface for Hearthstone

CUNY Games Network Interviewed by New Learning Times

NLTedlab_logoThe New Learning Times, a publication of the EdLab at Columbia University Teachers College, posted an interview of the CUNY Games Network. The interview summarizes the planning committee’s experience with the 1st Annual CUNY Games Festival on January 17th, 2014. Members of the CUNY Games Network advisory board discuss games in Higher-Ed, planning the conference, and supporting CUNY’s overall mission with game-based learning.

Read the article at The New Learning Times.


Learning by design

Need help with the Commons? Visit our
help page
Send us a message
Skip to toolbar