Don't Be the Fun Police: Why Games Shouldn't Force Playstyles

This article is about a pretty simple idea, so not much got cut, but it did take me a while to find the right framing.

I first got the idea to write on this subject when I watched Mark Brown’s video, Playing Past Your Mistakes. The video’s premise is basically “save scumming is bad; here are ways to encourage players not to do that.” It frames the goal as designing the game to make players want to keep playing even if things go wrong, and indeed suggests several strategies in that direction (such as making partial failure recoverable in interesting ways). But then right alongside these strategies, it suggests tricks like a single save slot with constant autosaves to just prevent save scumming without actually changing any of the incentives.

That struck me as a really bad idea for the reasons I ended up laying out in this article, and I was surprised it wasn’t obvious that this was a totally different type of “solution” - a crutch that technically avoided the outcome the designer wanted to avoid but didn’t actually fix the underlying cause and would mostly just frustrate many players. I took some notes and filed it away as something to maybe write about someday.

More recently, I was drafting up a short post about a design decision I disliked in Dragon Quest Builders 2. A couple of sentences in, I found myself saying, “To explain my theory here, I need to first discuss the concept of a ‘design crutch.’ I hope to write a full article about this at some point, but here’s a quick summary for now.” And then I proceeded to write a full article’s worth about design crutches and why they were a bad idea.

So I pulled out the Dragon Quest intro and polished this up into a standalone piece. It’s a useful concept and I’m glad to have a full writeup that I can refer back to - that’s what I’ll do when I return to that Dragon Quest post. But that also meant having higher standards for the text, and I had to come up with a clearer name for the concept. I briefly considered calling it “mechanical railroading”, by analogy with narrative railroading, but when I described it to Allie she said it sounded like “play policing.” I tweaked the wording slightly into “playstyle forcing” but that was clearly a more useful framing that got at both why someone would design in this way and what it does to the player. Thanks, Allie!

One angle I hinted at but didn’t elaborate further on is wrangling rebellious players. Every once in a while, I hear about a design decision made to prevent players from doing something not because it’s more efficient and less fun, but because it breaks the game’s mood or tone. I feel like this is almost always misguided. The fact that some players might, say, use cheat codes to one-shot the final boss before they finish their pre-fight monologue loaded with dramatic reveals is not a good reason to remove cheat codes! The players who want to do that are already opting out of your story experience for whatever reason. Taking out the codes won’t make them suddenly care about the story. All it does is block off the players who need or want the cheats to enable or enhance their experience.

You’re making a game, not a security system - you should assume the player is interested in being at least somewhat cooperative and design accordingly. Know your audience and design for it; don’t worry about anyone who isn’t in your audience. Otherwise, you worsen the experience of people who are in your audience in a doomed attempt to inflict your vision on people who aren’t in your audience.

There are also connections to the ideas in my previous article The Designer is Dead: Five Reasons to Go Beyond Intended Experiences, so check that out if you haven’t and you find this topic interesting.

That’s about it for this one. Hope you enjoyed!