Subjectivity in Game Design

Is Candy Crush good? Is Dark Souls hard? Is ARMA 3 complicated? Is Battlefield V fast-paced? Is Hearts of Iron IV accessible?

Unlike the academic theories of gravity or evolution, game design is entertainment. This means there’s no such thing as an objective truth. For every player who thinks Dark Souls is hard or Hearts of Iron IV inaccessible, there’s at least one player who disagrees. Loudly.

Metacritic grades and sales figures can tell you something about what reviewers think or how the market is voting with its wallets, but when it comes to a game design’s inherent qualities nothing can ever be objective. We sometimes forget that a game’s financial merits doesn’t necessarily mirror its creative ones.

This often makes the conversation on game design problematic, since two creatives may have widely different opinions on what the right way forward should be, and there’s no unbiased way to make a decision.

Worst case, the decision is made from executive fiat – the boss decides – but what tends to happen is that we start discussing from the only common ground we do have: the design of other games.

Yes, our game should have a Stamina meter, because this works well in Dark Souls.

No, we shouldn’t have a power that lets you fly, because Call of Duty doesn’t have one.

Our game must have a quick-melee button, because Overwatch has one and it’s a lot of fun in Overwatch.

You’d think I’m exaggerating. I’m not. All three are examples from design processes I’ve been involved in.

The Problems of Subjectivity

At a high level, subjectivity makes it impossible to make simple theoretical decisions. Especially when you combine it with the nature of game design as something everyone on a team can have opinions about. If the CEO played a cool game last night, or saw a cool trailer, chances are they’ll swing by someone’s desk the next day and talk about how our game should do the same thing.

Casual banter and brainstorming can become the same conversation as the one about practical implementation and personal tastes will often coexist with other kinds of arguments in a way that makes it hard to consider which is which.

What’s Fun

The first issue is when we talk about what we think is fun. Partly because fun isn’t always a goal and partly because fun is completely subjective. Many players enjoy competition, for example, and play hours upon hours of player versus player games. Personally, I don’t enjoy this, even if I do try many digital PvP games because I like to stay current with what’s released and what’s trending. In my tiny subjective world of single-player games, PvP isn’t “fun.”

But more importantly, pursuing fun can sometimes be detrimental to what you are making. Games like the inimitable QWOP deliberately makes the control scheme frustrating to create a very different kind of fun from almost every other game where running is a feature. And of course, the Resident Evil series thrived for years on having you decide between shooting or moving, building a more intense zombie survival horror experience by doing so.

Basically, arguing on the basis of what’s “fun” is a completely useless argument. Not because someone is wrong, necessarily, but because everyone will be right.

Good and Bad

The mainstream knowledgebase on what’s commonly seen as ‘good’ or ‘bad’ can often be discerned from the more vocal voices in YouTube comment sections or trends in user scores on various platforms. At least that’s how it feels when you observe it.

But picking features or ideas from a good game doesn’t mean your game will gain the same benefits, nor does picking ideas from a bad game mean your game will be bad either. Pretty much every game will have merits of some kind. Technical, aesthetic, mechanical. Dismissing or approving of games based on the common notion of their merits will make you miss interesting and clever ideas.

Just as with fun, using a game’s perceived goodness or badness as an argument makes for a useless argument. Especially if you are using it to evaluate a tiny part of the game.

Feature Prejudice

You’re talking about the player needing a solution to a problem, and you’re looking at games who have solutions to said problem. In most conversations, you’re more likely to use examples from games you think are fun or good, and you will then pick mechanics from those games to solve your problem – even if the problem is completely unrelated.

I was working on a first-person shooter once, where the player moved very fast. It felt nice and supernatural, and we had a lot of fun with it in development. At some point, a long empty segment of hallway was added to the test level. The immediate response was, “let’s add a sprint feature!”

My argument against this had always been that you moved at sprint speed all the time, more or less, and that sprinting would be a very artificial feature. In Call of Duty, as a good example of a sprinting mechanic, the sprinting serves a much more important purpose than giving you a slight boost in speed in empty hallways. You move slower in Call of Duty, partly because sideways movement tracking on a controller is trickier and a slower pace therefore fits the PvP matches, and partly because it’s supposed to emulate more regular soldiers and not superhumans. The sprinting then allows you to cover distances, for example to reach cover, faster, but also robs you of your ability to shoot without first stopping. This exposes you to danger if you didn’t already reach your cover.

Sprinting, in Call of Duty, isn’t just a convenient mechanic – it serves a wider dynamic.

In our case, the sprinting feature was added anyway, “because it’s expected from a first-person shooter.”

This is feature prejudice, where you make the mistake of equating a dynamic with one of its mechanics, and as we’ll get into soon, it’s a direct consequence of our lack of respect for subjectivity.

As with fun, good, and bad, you shouldn’t wantonly borrow mechanics like this.

Game Design Language

We say what’s fun, we say what’s good or bad, and we mistake mechanics for their dynamics. Subjective reality is already wreaking havoc with game design. But there’s another thing that makes it an even bigger issue: there’s no established way to talk about game design objectively.

Most game design books (that I’ve read) go through game design, not in practical terms, but in abstracts. In high level terms. You will learn how to pitch, how to write documents, and possibly read a few paragraphs about what a game is or isn’t. None of it helps you all that much in your day to day work as a designer.

Moreover, few professional game designers have actually read any of these books. Instead, you will often find yourself working in different ways as a designer depending on which company you work at, what kind of games you make, and how senior your position is. You may use a certain technique to solve a problem, and your company will have a name for that technique that you won’t find anywhere else.

One place calls the trail of enemies that leads you to the next door in the linear story “breadcrumbing,” while another calls it “leading,” or “leashing.” You’ll quickly learn the new terms at a new place, of course, but this lack of a proper lingua franca for game design pushes much of the conversation back towards using other games as reference points… and then you’re back at square one – in subjectivity land!

Handling the Subjectivity

Subjectivity is bad, then? No! We just have to remember that it exists and work around it. Understand that our own ideas are not worth more than anyone else’s and define our game on its own terms so that we don’t get bogged down in preference discussions or stuck in designing by reference.

The best part of subjectivity is that we can take ideas that may seem completely disparate, combine them, and our game will be much better for it. But only if we can do it in an informed way.

If anything, we should embrace subjectivity. Take as many perspectives as we possibly can and run them through the gauntlet of discussion and prototyping.

But we must first set the terms for our project, or our design discussions will soon boil down into matches of reference tennis.

Respecting Design as a Craft

One very important step is to give game designers the power to actually control the game design. Just like concept artists, game designers are often the subjects of uninvited scrutiny. Game design, like art, is something everyone can have opinions about. But the fact that people can have opinions doesn’t validate those opinions. A concept artist or game designer is no less of an expert than a rendering programmer or technical artist. The only difference is that the crafts of the former are not as esoteric as those of the latter.

Understand that your opinions are just that – opinions. Also, whatever you do, don’t push things through using clout derived from title or seniority. Even if you’re the CEO, you hired that game designer to be the game designer.

The point being made is: let game designers be the ones to design your game. Let them have the say in the matter and make sure that everyone respects it.

Postpone Your Piggybacking

“Piggybacking” is what you engage in when you borrow wholesale from other games. When you grab that sprint mechanic from Call of Duty, you’re piggybacking on Call of Duty.

But with all these issues of subjectivity now fresh in memory, you can see how piggybacking can actually be a bad thing. If one superfan of Soulsborne games suggests a difficulty level for your game project based on the most recent From Software title, difficulty will be very different from when the Nintendo fan dips into their experiences to do the same.

Because of this, piggyback as little as possible early in a game’s life cycle. Learn to talk about your game using the game’s own terms. Establish pillars and facts and use them as memes in your design conversations. Only engage in piggybacking when you feel that you have a clear identity for your game project.

Using Pillars

The trickiest part of game development is to solidify what your particular game is about. This can be self-explanatory for someone who is simply plugging away at the task on their screen. They just need to finish this task and move on to the next one. But that’s the work, it’s not the product.

Using design pillars is one way to communicate what your game is about. Broad but relevant pillars that can be used as practical expressions in conversations, becoming natural staples in how you define your game. The trick is to communicate what each pillar means, and to communicate it clearly and succintly enough that everyone on the team can make good use of it. It’s something close to what genres are used for among music lovers.

The only danger here is to make pillars that are so generic that they say nothing at all, or so specific that they require too much explaining.

“Fun Gameplay” is a terrible pillar, for example. But “Quirky and Fun” could be a good one, given the right context. It’s fine if a game’s pillars change a few times through the course of a game’s development, but the more solid they are, the better they do their job: to get you away from the subjective conversation and squarely into the objective reality of your particular game.

Stating Facts

From your pillars, you can derive facts. A fact is something you can state as true and can be related to narrative, to gameplay, to the art direction, or pretty much anything else. The trick with facts is to make them extremely specific. Facts should each verify a thing that is true about your game.

Do not use facts based on falsification. I.e., things that are explicitly not true. It can sometimes be necessary, if you have tropes to rule out for example, but shouldn’t be made the norm. Mostly to keep the tone positive. This may sound weird, but believe me – it does have value.

Some sample facts could be:

• The game has three resources: Blood, Sweat, and Tears.
• Our main character’s name is G.
• The main character carries a gun.
• Guns are rare.

The more succinct and specific each fact can be made, the easier they are to remember and communicate. Filling a wiki or similar with long lists of facts will often end up having the opposite effect, however, which leads us to the next thing.

Writing One-Pagers

The way one-pagers can be used is to put pillars and facts, as they relate to a specific subject, into one single document. Say, the Gunplay One-Pager, or the Grunt Attack One-pager. This can then serve as the basis for any conversation on this topic or related topics.

This works especially well if you organise your teams in a cross-disciplinary way, since it eschews any need for discipline-specific information and gives each discipline ownership of its own respective crafts. The one-pager’s job isn’t to tell everyone what to do – it’s to lay the groundwork of what the goal is for this part of the game.

The traditional Game Design Document, often expected to provide information and detail on everything, will often waste most people’s time because the details in there are simply not relevant to them. A one-pager can keep things succinct and allow people to apply their own specific knowledge to the subject through their own planning rather than as the uninformed details of a game designer on a writing spree.

What’s important with one-pagers is to keep them short, keep them up do date, and to name everyone who is responsible for implementation so that communication can be facilitated.

Demonstrating the Game Iteratively

Facts and pillars summed up in one-pagers for cross-disciplinary teams. There’s your game design. Now go build your game.

One strength of working from a high level where everyone can ultimately understand what the game is about before they set to making it is that everyone can be part of the whole. In a very large project, this may only include the leads and directors, but the best possible situation is where this information is project-wide.

Of course, someone whose specialisation is making shruberry or shoe laces may not even want to know what the game is about, but they may still have cool ideas that can feed back into the larger conversation.

What’s most important of all once you start building things, however, is that a one-pager can be wrong. Once that feature is implemented, reevaluate it. Does it actually fit with the pillars? Should one of these facts be removed, or tweaked?

The more you do this work, the more informed your iteration, and the better your game.