Understanding Pain Points in Game Design

An often-overlooked issue when it comes to the quality of a videogame are pain points—aspects that make a game 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 videogame, it damn well better include an audio slider and control rebindings.

Defining Pain

The concept of spotting pain points in videogames is not something that is often talked about among consumers and reviewers. What we are referring to are elements in a videogame that either break the illusion 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 literal 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 post 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 start to see patterns in terms of pain points that developers miss, and that brings up an important point about someone’s limit.

User Tolerance

On our weekly live show on game dev topics, 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 are not that hard to spot when you know what you are 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 about to read between the lines of comments. I have spoken with designer and expert on playtesting 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 developer has one pain point, chances are there are multiple ones 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.

Playtesting, Playtesting, Playtesting…

For our final point, this seems to become the standard conclusion for my design posts lately, we turn to playtesting. 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 playtesting 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. As a shameless plug, I am open to consulting work, and I examine indie games every week on my indie showcase streams and do my best to point out the good and bad of the titles I take a look at.

Regardless, designing a game in a bubble is the easiest way to make a pain point-filled experience. With playtesting, one playtest session is not enough: you want multiples and with different groups. And again, you are going to have to take all the feedback, especially the ones that are not going to be nice. A good videogame is always about being greater than the sum of its parts, and pain points subtract from that.

If you enjoyed my post, consider joining the Game-Wisdom discord channel open to everyone.