The Player Is Not the End

Originally published January 24, 2020.

I’ve seen this pop up a few times now. First with Sid Meier’s talk about design (2010) where he is constantly kowtowing to a hypothetical playtester and filing off the rough edges he likes in order to appeal to the lowest common denominator. Then in a paper prototyping lecture there was a lot about how to realize your idea in writing, communicate it with the team, and what you should be aiming for; the audience was obviously part of this. But the way “player experience goals” were presented, I’m not a fan. These are a description of what your players should feel when they play your game, kind of similar to saying “I want my game to be fun” and then cutting any features that a playtester doesn’t find directly contributes to fun for them. A lot of games are about challenge, and a very common design mantra is how you shouldn’t listen to your players because they will actively ruin their own experience. They may have a motivation (like treasure in D&D), but that isn’t what they actually want; most players don’t like Monty Hauls. One of the players may, but by pandering to them you would ruin the campaign for many others.

Dark Souls (From Software, 2011) would never be made under this mantra, and Valve goes too far in this direction of focus testing and making sure anyone will understand what to do and where to go (see Portal 2’s (Valve, 2011) handholding compared to the first game, or the famous example of a playtester going around in circles in a Half-Life 2 (Valve, 2004) level because he’s bad at navigating, so they cut out that interconnection and made the level worse for everyone else). You may say that Dark Souls is a rule breaker, an example of a designer that knows the rules and breaks them intentionally for great effect. I think this is entirely wrong, and the only significant rule broken is in Anor Londo (normally new enemies should be introduced in a safe 1v1 scenario, while silver knights are introduced two at the same time, far away from a checkpoint, and you have to fight them on ledges). Yes, DaS doesn’t handhold the player, it’s obscure, it doesn’t make it easy for every player to experience all the content, and it’s more punishing than most modern games, but these aren’t rules, they’re conventions. Just like you don’t follow tropes 100% when writing a book, they may be a good tool and exist for a reason, but they are not inherently good design and shouldn’t be taken as anything more than guidelines.

Now you don’t necessarily have to have poorly constructed goals or audience, it may not directly cause you to commit to worse design to pander to players, but I still have a couple of qualms with this approach. First is that I find it a terrible mindset and attitude. It’s essentially a lack of confidence in your own abilities as a designer and having to rely on players to tell you what is good and what isn’t when it comes to evaluating features or the game as a whole. Playtesting is valuable of course, to see what decisions players make and whether they do what you expect them to (or rather: what ways they diverge from that expectation), but they are not the master in this relationship. The audience is great for giving feedback, but terrible for seeking guidance.

Second is related to the title, in that player experience goals “inform[ing] your design process at all times” sounds very impractical. While a good step along the way, if it’s the ultimate goal you become wholly dependent on that guidance from playtesters. If you want players to feel immersed due to realism, you don’t implement every feature hoping that playtesters will say it adds to the realism, and scrap it if they say it doesn’t. The better approach would be to figure out what makes players feel immersed and what makes them find a game realistic, and then set those as goals, which is pretty much what design pillars is about. Take simulators or simulation-y strategy games, which emulate real life’s overwhelming complexity to immerse the player. With that as your goal, you can evaluate features and how they add to the game without spending a day on consulting your players who will never agree anyway. You have a more practical approach to playtesting with designing for a tangible goal instead of chasing feelings, and you can then playtest and incorporate feedback into that structure without the consumer always being right.

References

FROM SOFTWARE. (2011). Dark Souls. Namco Bandai.

MEIER, S. (2010). Everything You Know is Wrong. GDC. Accessed 24.01.2020 from: https://www.youtube.com/watch?v=bY7aRJE-oOY.

VALVE. (2005). Half-Life 2.

VALVE. (2011). Portal 2.