GameDev Protips: How To Design Challenging Games That Aren’t Way Too Punishing

Gamers today are familiar with truly “challenging” games such as Dark Souls or Super Meat Boy, and a few “punishing” games such as Fire Emblem Awakening (in some places) and lots of traditional JRPGs (usually referring to their bosses), but what is the distinction between a game being “challenging” and a game being “punishing”? There are tons of hard games besides the aforementioned ones, but lots of them fail to scratch that “itch” that we had for older games that just “seemed” to be harder. Why is that? Here are the answers.

For starters, the primary difference between a game being challenging and a game being punishing is its fairness. If everything in the game obeys the rules, the difficulty will be challenging. After all, the game isn’t cheating; you can find a solution for any problems you’re running into. Punishing games are quite the opposite; they cheat. This isn’t always malicious, such as with warp pipes in Mario, but games that break the rules necessitate memorization, lest the player falls into a trap that shouldn’t be there in the first place. An example of this would be if a boss in Dark Souls instantly killed the player if they weren’t standing on the high ground when it dropped below half health. The player has no way of knowing that would happen without first encountering it, so that event will have to be memorized for the player to proceed. The game is blatantly cheating so the difficulty introduced there is punishing.

There are a few exceptions to this rule, however. In Super Meat Boy, some of the bosses have attacks you couldn’t possibly dodge the first time you fight them without luck. However, because each individual iteration of gameplay is so short, these don’t frustrate like they would if you died after a 20-minute boss fight in the Dark Souls example. The respawn time is practically nonexistent so you can instantly adjust your play to fit the challenge. Also, even otherwise fair games can be perceived as having punishing difficulty if usability is disregarded. If mechanics aren’t properly explained, difficulty spikes exist, or other similar elements that make the game artificially harder, an otherwise fair game can be rendered punishing because the player can’t effectively overcome challenges.

As a general rule of thumb, if you want to determine a game’s position on the challenging versus punishing difficulty scale, you should look at what happens after the player fails. If the player feels as if they could’ve done something better, be that not making a mistake or using a different approach, the game is probably fair but challenging. If the player gets frustrated and blames the game for their failure, the game likely has elements that are out of their control which makes it punishing.

Important Takeaways: It’s important to be able to distinguish a challenging game from a punishing one. Challenging games are those that follow the rules and allow the player to overcome challenges with enough skill. Punishing games will be those that throw curveballs at the player that require memorization to avoid in the future; no amount of skill can prevent those obstacles from stopping the player the first time around. Exceptions to this rule apply if a game’s individual iterations don’t last long enough to cause frustration, as with Super Meat Boy’s bosses and the low respawn time. Similarly, an otherwise fair game can become artificially unfair if the player is forgotten about and thus their ability to complete the game is artificially hindered, such as with mechanics not being explained properly or difficulty spikes being present; it’s not that the game is unfair, it’s just that the player has no way of approaching the problem and knowing what to do before they’re knee-deep in it. As a general rule, if failing causes the player to feel that they could’ve done something better, the game is challenging. If a failure causes the player to blame the game for their mistakes, the game is likely skewed towards being a bit too punishing.