Design and uncertainty: How to work with people who don’t know what they want… including yourself 

You might have been in a situation where you and your team are creating a game, but each of you wants to do something different – and in a way, you don’t exactly know what you really want to achieve. 

Well, PixelAnt Games has some top tips on how you can easily discover information that will help you and your team understand or specify what is important in the game you’re making. 

You’ve probably been in a situation, for example, where you go on Steam and there’s this game has this comment: 

“This game is amazing! Swordplay is great. I’m 40 hours in and I still cannot get enough of it!” 

But then you see the same game but with a different comment, from a different player:  

“It’s quite an okay game but magic is not useful at all, which made me leave the game after a few hours – I even asked for a refund”.  

Why such a difference? Of course, for the second player it turns out that this wasn’t the game for them, but what can we do about that – is this even a problem, and how can a designer address such an issue?  

Sometimes designers tend to design a game with their own preferences in mind – they design for themselves, where they assume “I know what I want, so surely other players will enjoy it” – and that’s okay to have that gut feeling and to use their intuition. Plenty of people will indeed have a good time with such a game, but there’s also a lot of other players who will play and it turns out they didn’t quite understand what kind of game it was and may be disappointed. It’s a complicated situation, it’s a bit like the tip of the iceberg of designing, in general. 

At PixelAnt Games, we work according to the mantra “player-centric design”, which means we focus on designing for the player and not ourselves, i.e., based on our own preferences. The two main pillars of such an approach are the target audience, which is the people we make the game for, and the playstyle. 

TARGET AUDIENCE VS PLAYSTYLE 

When it comes to the target audience, the ones we are primarily making the game for, there are different aspects of those audiences to consider.  

For example, one of them is the ‘hardcore’ players, who play on next-gen consoles and love FPS games. But the second type of players may have only 30 minutes to play during the day – preferably in the evening – and utilizing this specific knowledge while designing a game means we won’t make levels that take three to four hours to complete or said players will quickly give up.  

Playstyle, on the other hand, is the style of playing the game, which means there are people of different characters, and those people approach problem solving in different ways. They try to beat the game using different methods. We call these specific behaviors ‘patterns’, which reflect people’s motivation.  

For example, let’s say we’re making a Doom-type game, and the first playstyle will be ‘combat’, so this would be a perfect fit for the group of people that really want to get engaged in fighting, eliminating the enemies. Then there’s the example of the ‘sneaky’ playstyle, which is something like sneaking around, where people avoid fighting and use a whole array of different tools, just to get from point A to point B without getting involved in combat. 

These are two completely different approaches, and in Doom you would not be able to use the second one. If we were to make Doom with sneaking mechanics, it would turn out that we have comments like “OK, but that doesn’t belong in this game, why is it even made like that?” 

It is also worth noting that players often never play 100% in one playstyle. It might be that someone was playing the ‘sneaky’ playstyle, but at some point, the enemies see them and now they must switch to ‘combat’ – or load a save file.  

A lot of people may say “Alright, I’ll go with combat, I am not going through all of that again, because I have no time”, for example, which makes it a very important aspect not to assume that a certain type of player always plays 100% in one exact style.  

FIVE STEPS THAT WILL LET YOU APPROACH THE PROBLEM 

1. Design approach 

Here we suggest the ‘Top-Down Approach’, which means that first we start with the experience that we want to create for the player, and then move on to the motivations behind it. Understanding those motivations, we can understand why the players want to do something – and what systems of mechanics and functionalities can allow them to do it – which means we start with experience, then move to the needs, and then features at the end. 

The problem is that the designers who design based on their own preferences start with solutions from the bottom, which makes it a “Bottom-Up Approach”. 

It’s not the wrong approach, but it’s great to have two people on the team, one with the ‘Top-Down’ approach who understands the experience, and the second person that starts with the ‘Bottom-Up’ and is a master of mechanics. 

Those people can complement each other nicely. When designers only have a ‘Bottom-Up’ approach, tthey probably haven’t asked themselves questions like “What do players need to draw satisfaction from the game?” or “Who exactly needs this mechanics, this functionality?” 

2. Acquiring information 

Games research 

First, we go to a place like Steam, and check who likes different types of games. For example, we’d look at Doom’s store page and look up what people like and don’t like about it, and what they think it lacks. What exactly is this game like, what are its mechanics and who buys games like this. 

Telemetry 

If we’re working on a next installment of a franchise, it’s good to have telemetry implemented in previous games, so we can better understand how players behave. This data gives us a lot of information on what is popular in the game and what is not. Like, for example, whether anyone even uses the ‘sneaky’ playstyle at all. 

Motivation Model  

To understand a game’s research and telemetry, we need to know the motivation behind why people play. There’s a nice motivation model called ‘Gamer Motivation Profile’ which Nick Yee created and made available on the Quantic Foundry website. 

You can fill out a mini-survey and find out what your main playstyle is; it also gives you hints on which games you may like. Then your data is added to a poll of about 500,000 results of such surveys, and based on this exact data, developers can find out if that when someone likes Doom, what other games they might like and the motivations behind it. 

3. Defining the designed game  

The third step is moving on to the pure design. This is where we specify exactly who the game is for, which means we narrow down a whole spectrum of people to a very specific group, utilizing the data we had before so that it can be used now.  

Then we define, based on that data, the playstyles that we want to support because we believe that those will be useful.  

Finally, we define the mechanics, systems and functionalities that we would actually need to create the particular experiences for the player. 

This is, in most cases, created at the vision stage during preproduction. Sometimes, even at the conceptual phase, we already have it in the back of our minds. 

Again, let’s take the Doom player base as an example – note that the data we’re talking about right now doesn’t overlap with real Doom’s data, it’s just made up. 

The stealthy approaches, which are ‘Stealth Midcore’ and ‘Stealth Hardcore are at 0% here. No one should even try to play this game using stealth approach, because it’s not a game about that, this game is not for these kinds of people – stealth is not how we will market this game, and that’s not how we would design the mechanics and overall experiences.  

Then, 22% are those hardcore combat gamers who finish their game on the very hardest difficulty level, and they need to collect every weapon because they are really into it. Doom targets the players who are more mid-core, which is people who have more time to play – they like to shoot around, and they’ve already played games like these. 

They understand a lot of concepts in such games, but they still don’t care about finishing the whole game or about collecting all the weapons.  

These factors all have an impact on the level structure. If we were to design levels with this player base in mind then, say, 67% would be combat. There is no sneaking here at all, but we also need to provide the players with a little moment to catch their breath, as it can’t be just ‘combat, combat, combat’ all the time, because the players would just get worn down by it.  

As for the 22% mentioned above – this is where they can relax a little, explore, heal wounds, collect ammo and so on, exploring the world in general. 

All of this is important to the mid-cores. If we have hardcore players, those breaks are not so important, as they will continue and take on enemies. The 11% in this case are boss fights because that’s what the game is about, which is also a nod towards those hardcore players who like challenges. But thanks to adjusting the difficulty level, everyone can have fun here.  

4. Bullet-proofing design 

Bullet-proof design means that the game must pass through a sieve of our methods. First, we test a lot – we test very early and, thanks to cooperating with Sumo, we are able to test our design – not only at focus tests here in Poland, but also in places such as the US market, the Asian market and so on. 

These not only provide us with information on whether the game works, or whether our assumptions are correct, but also how it impacts different markets, which is incredibly useful. 

The next step will be a ‘QA Overhead’. This is where we check if players really enjoy using those playstyles in the game, and if there are enough players using specific playstyles percentagewise to make using this playstyle worth it. If it turned out that one of the playstyles is not polished enough to make it worth playing (and supporting), then we could cut it out of the game; because every single playstyle occupies the QA department. 

Even if we automate testing, it will still take twice as long to do it. Each level needs to be finished twice; first by playing very aggressively, and then by doing things like sneaking.  

Later, we balance those playstyles to make it fair – for example, we don’t want to completely lean towards combat or sneaking. What is important here is to reward the players adequately for their effort and, of course, to reward them fairly – for instance if someone plays using the ‘combat’ style, they won’t suddenly get a whole lot of weapons and experience points, and the one who sneaks around won’t see half of the game because of their actions.  

5. Creating implementation guidelines 

In our fifth and final step, we create the implementation guidelines. If, say, the design ends up on the desk of the level designer, we need to make sure that the work of all the level designers and game designers is consistent so that we’re making the same game. 

Imagine that we’re creating an action RPG game and want to support the following two archetypes: the Knight and the Bard.  

The Knight will be a player who always wants to fight and is not afraid to explore dungeons, search for cool loot, and doesn’t care that much about the story in the game. 

The second playstyle is the Bard, a player that is completely different – they avoid combat, want to learn the story, help others and make their own stories; they want to discover the game’s actual world rather than just experience combat. 

So, now we have those two playstyles on the table – imagine there’s an obstacle to overcome in the game, say a closed door. It would be nice if the way of overcoming this obstacle were different for individual playstyles, which is why the Knight can kick the door open, or they may also defeat an enemy, take their key, and open the door. 

The Bard, on the other hand, would have a completely different approach. First, they can break in using things such as a lock pick when the guard is not looking, they may also steal the key from the guard, use that key on the door and get inside – on top of that, they can use a disguise, so that no one can recognize them. 

Additionally, if there are dialogues available for example, they may bribe or convince such a guard to open the door for them. 

There are also solutions that are typical for both playstyles, for example, if we have magic available, players can use it to teleport to the other side – or look for a secret passage that will lead to the same room. 

If I were to only think about my own approaches, I might only come up with part of them, meaning I would only think about how the Knight might deal with the obstacle, so we need to have that balance from the wider team’s input. 

IMPLEMENTATIONS EXAMPLES 

Dishonored 2 has two main playstyles: sneaking and fighting. There’s also a sub-playstyle, where the player decides that they want to finish the whole game without killing anyone. The way these playstyles work here is that, if the player won’t eliminate enemies, their ending and the whole story will be completely different than for someone who solves all the problems by force. 

Another example is Deus Ex: Human Revolution (pre-Director’s Cut), where we have the following playstyles: combat, sneaking and hacking (because it’s a game in a Cyberpunk setting). There’s only one problem here; when it comes to boss fights, many players use one specific playstyle, which is combat. 

Imagine that someone played the hacker playstyle throughout the whole game. In that moment, they have no weapons on themselves, and suddenly it turns out that to defeat the enemy they must use a weapon – this could cause issues when attempting to progress in the game. 

CLOSING THOUGHTS 

Player-centric design is a tool that helps design games for the players, not the designers. It structuralizes and unifies the design language people use in the project. 

This helps make informed decisions on small and large problems, and it reduces production costs, creating unnecessary content can be reduced. 

WATCH VIDEO: