How can game developers better design experiences around their players? This often-asked question is one that Celia Hodent has a particularly strong grasp on, given her expertise in the field of User Experience design (AKA UX).
This December, Hodent will be teaching a day-long Masterclass course on player psychology and UX principles. We wanted to give you a taste of her class in advance, so we reached out to her for a quick Q&A that may help you in your day-to-day game development life.
For your benefit, here’s a conversation between Hodent and a hypothetical game developer looking to solve specific challenges with their game based on player feedback.
Hey Celia, I’m a game designer looking to understand more about UX and player psychology. We’re working on an online multiplayer RPG with a lot of moving parts. We have a solid A/B testing process for new features but we’re looking for ways to introduce player psychology into our process.
What are some of the first steps you take in your work when doing this kind of testing? How do you make sure you’re getting useful data out of it?
Gathering data is a great start! But data is not information. Telemetry data is great to figure out WHAT is going on in your game, but not easily WHY. Let’s say that you see that many players are dying from a specific telemetry event (whether it is from a specific AI enemy, against a specific weapon in PvP, or in a specific location). That’s good to know, but it’s not very helpful by itself.
You need to understand why in order to make decisions. Is it because players don’t understand what is killing them? or because a specific weapon is overpowered? or is it because there’s a usability issue leading players to not even realize that they are getting damage? Making shots in the dark based on gut feelings is not an efficient process to solve problems affecting the player experience. In order to get meaningful insights from telemetry data that will help you make the right decisions faster, you need to start by posing hypotheses very early on the development process.
When considering UX and cognitive science, a common hypothesis would be “If players don’t understand how [feature] works, they won’t be able to feel competent at playing the game and they will therefore churn” (not feeling competent at playing is strongly hampering engagement).
If prior to your beta you have conducted playtests where you observed players and asked them questions, chances are that you’ve spotted early on UX issues that will help you anticipate what precise telemetry hooks you will need once the game is launched to make enlightened decisions faster.
In summary, the first step is to very early on think about what players need to understand in your game in order to progress, feel competent, and master it (among many other things). So that you can spot much faster when something goes wrong and fix it. This mindset (which is the essence of UX) is what will help you once you’re in the beta stage.
You can’t “introduce player psychology into the process”. Considering human factors at every step IS the process.
That’s helpful!! Here’s my next question: we’ve gotten some feedback from players over time as we’ve problem-solved various issues that the game seems to be getting easier, but not necessarily more fun. We think we may have overcorrected in our process by sanding off the edges of some encounters.
In your work, what’s been a useful step for figuring out when player frustration is good frustration, versus when it’s frustration developers should be trying to eliminate?
That’s a great question. Fine-tuning the difficulty curve is important to offer a good UX, as it’s one of the key components of game flow, which in turn is one of the three pillars of engageability (along with motivation and emotion).
A game should not be too easy, or too hard. The problem is that different players have different levels of expertise and need different levels of challenge. Also, some games are specifically sought out for their high level of challenge (such as Souls games), while other games can be appreciated when they are more chill. Thus, many factors are at play.
Generally speaking, when a game is too easy players get bored and might stop playing. When it’s too hard, they might rage-quit. This is one of the things that we can only fine-tune once the game is in beta and played by thousands of players, thanks to telemetry data and player feedback.
Both are important to look into, as there can be a big gap between what players say and what they do. But if they say that they find the game too easy in surveys and telemetry data tells you that players are churning, it can indeed be a sign that you need to raise the level of challenge in your game.
If these sound like the kinds of questions you’d ask Hodent if you had the chance, get your own answers and sign up for her GDC Masterclass before seats fill up!
Gamasutra and GDC are sibling organizations under Informa Tech.