Player Centric Design - Part 1

Introduction

Designing and implementing gameplay that is fun is a hard problem, often met with subjectivity, generalizations and criticism. For the scope of this two part post, I will discuss the design of gameplay as it pertains to the player's mechanics (what the player can do) and the AI (NPCs and/or the world simulation) within the game world. In two parts, I will describe a methodology that game developers can use to formally express the design of the intended gameplay which tries to ensure a positive and fun player experience. This methodology is highly inspired from ideas presented by Paul Tozour and discussions I’ve had with other game developers. There is a wide range of material available that describe varying processes across the industry centered on designing "the fun" in gameplay. At times these techniques tend to be inconsistent or rely heavily on subjective feedback. We also sometimes find ourselves using other games to drive our design decision making. While this is an important part of game design, it is not the only way to drive ideas forward. We can and should think about what our intended gameplay could be rather than possibly limiting ourselves to previously established ideas. The proposed approach focuses on the player as a key gameplay ingredient in defining the rule-sets that then drive the design of the AI and world. This design process forces you to think about the player up front which ends up being player-centric and has a wide range of benefits. With that in mind, an apt name for this design methodology is player centric design.  

Gameplay Loops

loops.jpg

We can think of a game as having several gameplay loops. Within a gameplay loop, the player undergoes a series of steps to engage in and achieve an established goal. The game then reacts and influences the player to either continue or alter these set of steps, until the goal has been achieved. For example, in an open world game like Far Cry, the player may engage in the hunting gameplay loop where they must first identify a piece of equipment to craft, understand the resources required, search for an animal in the map, travel to and scout the location, set traps to lure the animal and then finally kill and harvest the animal. Another example in a first person shooter like Call of Duty would be the core combat gameplay loop where a player engaged in active combat must find and take cover, shoot from cover and keep advancing forward while the enemies react to the player's positioning and shoot back. The player must finally kill every enemy to advance to the next room and so on. While these are some simple examples, well designed gameplay loops often overlap. In most games, the player is allowed to, and often encouraged to, engage in multiple loops at any given time working towards a higher-level overarching primary goal driving the player's long term motivation.

Maintaining Longevity

fatigue.png

A key challenge in every game I've worked on is keeping the player engaged over a long period of time. As a player, I've often found myself getting bored with the game I'm playing even though the game is providing new content either via new tasks and missions, new enemies and additional content. As I begin to develop a level of mastery and familiarity with the mechanics and the underlying systems at play, the loops I'm engaging in begin to feel repetitive. Players tend to want variation within the gameplay loops with the desire for continuous and advancing cerebral engagement. In addition, when players tend to find a winning strategy, they hold that pattern within their mind and stick to this strategy even if other strategies are available. This leads to lack of engagement and eventual gameplay fatigue. 

Some ways to tackle this include adding variable constraints to our gameplay loops. This can take many forms. For example - we can alter the amount of enemies and make them harder, we can add game restrictions like time limits to create tension and increase the challenge, we can change the locations and add varying environments to create diversity, etc. While these methods all have a necessary place in providing a degree of variation within a gameplay loop, they do not guarantee that they will cause the player to try something different and alter or challenge the mental model in their mind. Cerebral engagement comes from building upon the mental strategy a player currently possesses either from previously mastered models or from discovering and becoming familiar with an entirely new one.

Another way is to provide entirely new and unique forms of scripted gameplay which I refer to as one-off moments. These moments force the player to enter a varied and unique gameplay moment that provides a momentary departure from the existing loops that the player has been engaging with. This technique is very powerful and works well for linear and scripted games. Many key narrative moments are delivered through this technique as they provide the player a memorable and one-off experience - powerful the first time you experience it. These moments tend to be expensive to create and have very minimal replayability. Encountering subsequent moments of the same type lead to a lack of discovery and drops in cerebral engagement. 

Additionally, we can also simply provide more things for the player to do. I've seen many games try to solve their problem of gameplay fatigue by adding more mechanics. In some cases, that's the right approach but we have to be careful not to cause "gameplay bloat". Having too many player choices without focused motivation and information to know when and how to use them replaces one problem with other problems of player comprehension and confusion. This also generally doesn't address the fundamental issue of the player wanting to change their strategy or learning to be creative and vary their gameplay.

cerebral engagement.jpg

I'm sure there are more solutions to this problem of fatigue and engagement including the ones I listed above, and each of these have a purpose, but I hope you get the point. Ultimately, we want our players to have and create variation in these loops and have diversity in their thought processes as they try and solve the different gameplay scenarios that the game presents.

 

Scripting the Player

A key question to ask is do these solutions alter the player's behavior? And if they do, did we plan for that behavior? An approach to better understanding this is to use the same techniques and languages AI programmers and designers use to script and author the behavior of the AI, on the player itself. This allows us to represent and design the intended behaviors of the player. In part two of this post, I'll be exploring this idea further and will use a few examples of how this approach can help us curb the challenge of player fatigue and longevity. I'll also dive into the idea of building systems that the player can interact with as the foundation of your core gameplay experience. Paul Tozour put it very eloquently in one of his talks; often we get so caught up with the structures we're building inside our games, that we lose sight of the fact that we're building structures inside the player's mind. 

The Missing Ingredient: Trust

Making games is hard enough. Making games with people you don't trust sounds impossible. I've been lucky enough to work with some amazingly talented developers that believed this same philosophy. It's like in any relationship - when you trust each other, you challenge and push each other to create, craft and develop. I think what I appreciate the most about building a trust focused environment is the amount of learning that happens. Trust doesn't just come for free, it needs to be developed within a team. Here's a a semi-rant during the 2016 GDC Animation Microtalks where I talked about building trust between programmers/designers and animators in helping to create the best gameplay experiences possible. The rest of the microtalks are also really awesome and worth checking out!