I’ve been thinking a lot lately about something I call Player-Facing Design. I’m sure I didn’t come up with this concept. I bet it’s not even an old one. But it’s something I don’t see people talking about too much, so I’m going to talk about it.
The idea comes from consumer-facing initiatives in business. You want the customer to have everything they need so that their experience is as easy and pleasant as possible. The same goes for game design. You want things to be as simple and forward-facing as possible so that the players (and the GM) have an easy time grasping and playing the game. It’s the design-concept that brought us things like Beginner Boxes and Quick-Startup Guides. The problem is, of course, that it can get a little…sticky.
What It Looks Like
Crack open your Player’s Handbook, if it’s within reach. Or click on over to the 5th Edition SRD or D&D Beyond if it’s not. Look up the fighter class and check its very first class feature: Fighting Style. Fighting Style is an excellent example of Player-facing design. It does everything right. It gives a basic description of the overall concept of the feature, gives multiple options with easy-to-understand labels, and each option has a simple mechanic that is completely within the player’s control.
If the player wants to choose the Dueling style, they understand everything about it. The prerequisite (wielding one weapon in one hand) is within their control, and the benefit (+2 damage with that weapon) is simple and easy to put on a character sheet.
Another good example is our old friend, page 274 of the Dungeon Master’s Guide (or under Creating a Monster if you have the Dungeon Master’s Guide on D&D Beyond). This is our “Monster Statistics by CR” table. In this case, the player is the Game Master, and the table gives them everything they need to know in order to create basic monsters. Turn a few more pages, and you have a list of features that modify those numbers, all available for the GM to use as they see fit in designing their own creepy-crawlies.
Player-facing design is design that is clear in its intention and readily available for the player to access and use as they see fit.
What It Does Not Look Like
Okay. Now, let’s turn back the clock to the days of 3rd edition and 3.5 D&D. You might not have these books available, but Wizards of the Coast were kind enough to make almost all of the rules free to use, so go ahead and click over to the 3.5 SRD and click on the Ranger class. Let’s take a look at that Favored Enemy feature.
At first, this seems like decent player-facing design, right? Choose a thing, get a bonus, choose more things and get bigger bonuses as you increase in level. Simple, right? Unfortunately not. The problem here isn’t necessarily in the written words on the page, but with the underlying system. See, the ranger has 32 favored enemy options at their disposal. A WEALTH of bad decisions. Not only are some of them horribly-specific (Humanoid (gnoll) huh? How many creatures is that useful against?), but you have absolutely no control over whether or not you get to use the feature. Even if you choose a broad option like “magical beast.” How are you supposed to determine the difference between a magical beast and, say, an outsider that just happens to have a bestial shape, or a fey that looks like a beast?
The GM should, of course, do their part in letting you know when your attacks are more effective to give you a hint, but that also goes against the text of the feature. If your favored enemy is a magical beast, you should KNOW when you’re fighting one, right? Except to tell you would not only circumvent the creature-identification rules as-written, but is also not present in the text of the feature. It doesn’t even confer a bonus on checks made to identify creatures of that type.
Therefore, what we have is a feature that doesn’t confer a benefit unless the GM wills it, doesn’t give the player any information to help them choose between options (I STILL don’t know what a native outsider is, other than an oxymoron), and is completely inconsistent with its own fiction.
It’s not just player-opposing design. It’s plain bad design.
But we’ve had a couple editions since then, haven’t we? Let’s see if the designers have remedied these problems since then? 4e skipped Favored Enemy, but in 5th edition, Favored Enemy gives a different ruleset from the one presented in 3.5. You choose from one of 13 different creature options, or two humanoid options (it suggests gnolls and orcs as examples). You then gain advantage on tracking and checks to recall information about them, and a bonus language. You gain additional favored enemies at 6th and 14th levels.
This…is better? It gives you advantage when recalling lore about your favored enemy—meaning that it aids with the “fey that looks like a plant” problem—but still doesn’t give you any indication of what you might be facing along the way.
A better version of this is presented in the Revised Ranger from Unearthed Arcana 18. In this version of the ranger, it specifically limits you to one of five creature types at level 1, and all of these creature types are ones you’ll likely face at early levels. Then, at level 6, you gain access to creature types you’re more likely to face at higher levels. It also combines humanoids into one creature type, which is what should have been done all along.
Overall, the Unearthed Arcana version is probably the best iteration of this class feature. You can also see, as you look at the different editions, how the feature slowly evolved away from GM-secrecy toward a more player-facing design.
The Sticky Wicket of Player-GM Opposition
Reading this, a couple thoughts probably occurred to you. First of all, what about Armor Class? Or combat in general, for that matter? Or ability check DCs, or any number of other design elements that require the game master to withhold pieces of information? Doesn’t that, by its very nature, make the concept of secret target numbers and GM rolls behind a GM screen player-opposing design?
Kind of. But not really.
I feel obligated to bring up the idea that you don’t HAVE to roll behind a screen, and you don’t HAVE to withhold things like armor class or DCs. There are entire systems where the players always understand what number they have to roll (Dungeon World, Savage Worlds, etc.) HOWEVER, I also understand that the default, understood version of running D&D has the GM behind a screen and holding more metaphorical cards than the players.
The thing about this Player-GM Opposition, or the idea that the roles of the players and the GM are often opposed to one-another (NOT that they are opponents in any sense, to be clear), is that it is an inherent part of D&D’s design. It’s not a board game or video game where the story and the challenges are automated. The nature of the GM being required to present challenges with degrees of difficulty means that they will occasionally be in command of information that is not available to the rest of the players. This does NOT mean that the design itself is not player-facing. Just as the monster-stat-table is player-facing by making things plain and obvious, if only to one side, the fiction being created between players and GM during combat or a skill challenge makes the information player-facing even when it is being kept secret from one side. The players might look at an orc and be able to tell that he has heavy armor and a large weapon, and that will give them useful information about his AC and damage output. In this way, GMs can convey ideas without necessarily tipping their hand and revealing too much.
Using Player-Facing Design Ourselves
Since I spent all this time talking about how great player-facing design is, how can we make sure that we’re using it ourselves? I don’t have all the answers, but I think I can give a few tips to help you in your future design.
Make Your Intentions Clear
This is where most well-intentioned design fails. A mechanic will exist within a game, and all the information will be present, but the intended way to actually use the mechanic isn’t communicated clearly.
We can see this in the Favored Enemy mechanic we looked at earlier. The obvious intention is to choose a creature type at level one that is likely to appear at level one, then choose creature types that are more consistent with higher levels as you reach higher levels. However, without a thorough knowledge of the monster-pool of the game, there’s no way to actually know what creatures to choose.
In a similar vein, many claim that several feats in D&D 3.5 and Pathfinder were designed as “trap” feats for less-experienced players to choose before realizing that said feats were actually quite useless. While this isn’t necessarily true, the fact remains that some options are always going to be niche. It needs to be made clear that said options might only be appropriate in certain games, and that open communication with your GM is important in determining which you should pick.
Instead of writing this intent into the feature—or better yet, actually designing around said intent—we’re left interpreting the design based on witness marks left in the text.
There’s a lot to be said about the merits of complex design—and I intend to say those things some day—but as a general rule: Keep It Simple, Stupid.
This doesn’t mean that every single mechanic you put to paper needs to be a bog-standard modifier to a roll. Instead, try to keep mechanics immediate, and ensure that they leave an impression. If we’re being honest, players and GMs probably won’t remember more than two or three effects at a time, and if those effects need to be remembered over a period of multiple turns, things start getting complicated and details get lost.
This is why the addition of poison damage in 4th and 5th edition was such a breath of fresh air. Instead of keeping track of which poison was damaging which enemy on which turn, most attacks simply do immediate poison damage on hit. Specialized poisons that lower ability scores or put opponents to sleep still exist, but for those immediate effects, poison damage helps to keep bookkeeping at a minimum and keep everyone focused on the parts of the game that matter.
Tell Everyone Everything
Let’s say you’re designing an investigation system, and you want it to be clue-based. The players need to find X number of clues in order to uncover a lead. Instead of writing the clue-discovery mechanic in the player’s section and the difficulty-to-clues ratio in the Game Master’s section, write it all in one big section. Hell, write it twice in both the Player’s and GM’s sections. The fact that players know that a “Bamboozling” lead requires seven clues isn’t going to make the GM’s job any harder, and will actually add to the drama of the mystery when the players discover five clues and STILL haven’t uncovered a lead.
By ensuring that all information is out in the open and readily available, players and GMs are much less likely to get confused and lost in the design, and are more likely to have fun actually playing the game.
Header Image by Jeremiah Morelli
Did you enjoy this article? Want to see more? Then click the Join button on the right-hand side of this page to follow the blog and stay up to date every time a new article lands. And if you really did enjoy this article and want to see the blog get some more traffic, then I encourage you to click the Like button below, and share it with your friends and fellow gamers by clicking the share buttons as well. It’s positive feedback like that which inspires me to keep writing and sharing my thoughts with all of you.
And, of course, if you want to contact me, then you can use my Contact Page or e-mail me at LootTheBodyBlog@Gmail.com.