Understanding Pain Points in Game Design
By: Josh Bycer
Tags: Gaming, Game Design, Videogames, Game Development, UX

Understanding Pain Points in Game Design

What are “pain points”, and why are they important to address?

One often-overlooked issue when it comes to the quality of a video game is the pain points: aspects of a game that make it frustrating to play. Like a skip in a record, these moments can at best take the player out of the moment, and at worse, ruin the game for them. We are going to talk about how consumers respond to pain points, and why if you send me your video game, it damn well better include an audio slider and control rebindings.

Defining pain

The concept of spotting pain points in video games is not something that is often talked about among consumers and reviewers. What we are referring to are elements in a video game that either break the immersion of the experience or make the game worse to play.

What makes this tricky to spot is that it is rare to see egregious examples, like having a game with a literally unbeatable section. Most pain points are small, and depending on the person, they may gloss over them. To put it another way, it is like someone who has their favorite car they have had all their life, and the windshield wipers do not work right. “You just learn to live with it,” is a phrase often uttered when it comes to pain points.

For harden fans of popular genres, they have completely internalized any pain points as just the learning curve of the title. For them, it cannot be that the game has a problem, it is just outsiders not understanding it. This is often why many pain points in titles tend to center around the new player’s experience and onboarding. Another term often used is “gamer tax” that someone must pay before they can fully enjoy a game. In my previous article about soulslike design, I talked about the fine line between challenge and frustration in titles.

One surefire way to distinguish the two is that frustration is often caused by a pain point while challenge is not. When you have played as many games as I have, you tend to see patterns in terms of pain points that developers miss, and that brings up an important point about players’ limits.

User tolerance

On our weekly live show on game dev topics over at Game-Wisdom, my cohost Sharky came up with a brilliant way to describe this phenomenon for a consumer by making pain points a literal measure. Everyone has a tolerance level to frustration when it comes to a game, and each time they run into something that would be considered a pain point, it begins a tally for them.

Without realizing it, once a game’s pain point level reaches the person’s internal limit, they just stop playing. Not only does everyone have different tolerance levels, but they also have different things that cause this point buildup to multiply.

For me, I no longer have any patience for user interface and user experience (UI/UX) issues. If your core gameplay loop cannot be enjoyed comfortably, my interest in your game nosedives. And that takes me back to the start about audio sliders — basic UI quality of life features should be standard in games by now. That includes, but not limited to, audio sliders, key rebinding, accessibility features, and even just allowing someone to exit the game from the main menu. Further examples would be tutorial design and basic onboarding to make sure that someone knows how to play your game.

What makes pain points so problematic is that they aren’t that hard to spot when you know what you’re looking for.

Reducing pain

Spotting pain points in a game begin and end at the user experience. As always — anything that interferes or prevents someone from experiencing your core gameplay loop is a pain point. For ARPGs, a common one is not having a sort feature for inventories full of items.

Even something as innocuous as an annoying sound bite that repeats constantly would be considered a pain point. A common theme is that a pain point is something that stays consistent during the play. A consideration would be having a difficult section that would be more of a difficulty spike rather than a pain point.

Part of the challenge of identifying pain points is that they are often conflated together with other issues. Asking someone about what is annoying them in a game is kind of like asking a patient what is wrong with them. People can talk about the symptoms, but they will not be able to tell a doctor what they have.

Here is a little example of some of the challenge of spotting pain points. A game has two negative reviews, “This game sucks and is a waste of time, I keep dying no matter what I do,” and “This game is horrible, the bosses are stupidly designed by crappy game developers who should drop dead.” Some of you reading this would completely tune out these reviews due to the vitriol in them, and I know that some developers have been taught to disregard negative reviews.

However, part of being a game developer is being able to read between the lines of comments. I have spoken with designer and playtesting expert John Brieger on several occasions. One of the things we talked about was how you are not going to get perfect feedback from testers. Those two reviews tell us something beyond just attacking the developer — something is not clicking with the combat system. If we push further, we could possibly spot something going on with how responsive combat is, the overall difficulty of the enemies, attack buffering, and many other possible problems.

Remember, one pain point is not enough to raise alarms. However, what I have found is that if a game has one, chances are there are multiple others waiting to rear their head and ruin the experience. Good quality-of-life features can help to reduce pain points, and even if you don’t realize it consciously, they make the game more enjoyable to play and are a sign that the developer understands their game design well.

As we have said many times before: it is very easy to design complex systems but making them easy to understand is another story entirely.

Play testing, play testing, play testing…

For our final point, as it seems to have become the standard conclusion for my design-focused articles lately, we turn to play testing. If you want to know if your game has pain points, put it in the hands of consumers and see if they complain about anything. Remember, you not only want fans of the genre to play your game but non-fans or critics who are more receptive to pain points.

As a developer, you are going to need play testing no matter what kind of game you are making. Look for game clubs in your local area, or while you are networking, ask people if they would like to look at your game (shameless plug: this is something I do professionally, feel free to reach out to me if you’re interested).

Regardless, designing a game in a bubble is the easiest way to make a pain point-filled experience. With play testing, one session is not enough: you want multiple tests across various different groups. And again, you are going to have to take all the feedback, especially the ones that are constructive — that you might not like to hear. A good video game is always about being greater than the sum of its parts, and pain points subtract from that.

If you enjoyed my article, consider joining the Game-Wisdom Discord server. It’s open to everyone.