Weird & Wonderful Player Design Patterns (pt.1?)

This post was inspired by, or rather is a distillation of a thread I had started on The OSR Pit: I am a Bad Player, wherein I discuss my concerns about being a Player in a game, as someone who is usually a GM and also as somebody with atypical preferences. I am currently a Player in Semiurge's game Beyond the Bizarre Armoire, although I don't go into many particulars on that game in this blog post. 

This post is more broadly about how I think there are a lot of OSR / Blogosphere type analyses on how to be better at GMing, but not as many about how to be good Players, and even amongst those, I think there are certain particulars lacking, so this is an attempt to address this. The original post was very stream of consciousness, so I'm going to try to break it down after the fact into smaller and more coherent chunks. I may or may not make this part of a larger series of blog posts, but this first one will focus on what I am calling Player Design Patterns.

Here I'm differentiating between Tips & Tricks, vs. Design Patterns, vs. Specific Implementations. This is an abstraction that is intended to be useful in a heuristic sense, and not overly prescriptive. I'm not looking to get into semantics arguments over what counts as a Tip & Trick vs Design Pattern or whatever, you can define the terms differently or use different terms if you'd like, this is just about creating language and tools closer to what already exists for GMs, but for Players, to help them improve in an efficient and non-linear way (as opposed to just intuiting from experience alone, although of course experience is still crucial). 

Given this schema, here is one example from a GM perspective:

Tip & Trick: Don't Railroad

This is generally good advice. Even this shouldn't necessarily be taken as absolute, but generally, most Players prefer to have agency, and it can allow for problem-solving and emergent play and a whole bunch of other nice things. However, in itself, Don't Railroad doesn't tell you what to do, only what not to do. It doesn't tell you how to write an adventure in a non-railroaded way, or what that looks like, or all the myriad benefits that stem from that kind of design beyond just the straightforward explanation that I gave above.

Design Pattern: Modularity

Rather than prepping linearly, like if you were writing a novel, prep in a modular manner. This not only gives players more agency, but if you keep in mind a handful of specific implementations, including but not limited to those below, you'll likely see how it can actually make prep easier and can make you more adaptable to your Players' decisions when they inevitably jump off the rails.

Specific Implementation: Three Clue Rule; Random Generators; Quantum Ogres; Game Modules

The Three Clue Rule is the idea that if the Players are on an investigation, there should be at least three clues in any given scene. That way, the investigation is not dependent on the Players doing one specific thing or succeeding on one specific roll. Random Generators are a good way to create modular content, by offloading the burden from the GM to create every facet of every scenario from the ground up. That quantum ogre link is just for a specific monster, but I think the term originally came from the idea that, if the Players don't know where the monster is, or don't know which road is the correct one, then the monster is wherever the GM needs it to be, and all roads lead to Rome. This is perhaps more like an invisible railroad rather than being truly modular, but can still be a useful implementation to have in your back pocket. And then most obviously, actually game Modules, which can often be interconnected across a larger campaign given some shared setting assumptions.

You can disagree with some of my specific phrasing, or with the effectiveness of the specific implementation examples, I'm just saying in general, this is a useful way to break apart the kinds of concerns a GM may have, and what to do about them.

There are few, if any, similar kinds of design patterns and implementations for Players, besides the character sheets themselves. Most books or blog posts I've seen, not all but most, stop at the Tip & Trick level. That's better than nothing, but I think it would be even more useful to have Design Patterns, which then lend themselves naturally to Specific Implementations. Here is one example:

Tip & Trick: Write Notes

Writing notes is a good idea. It helps you remember things better. It keeps you focused. You can refer to the notes later. It shows the GM and the other Players that you're engaged with the game and you care. There is nothing wrong with this advice. However, it's vague. It doesn't in itself give you an idea of how to do it effectively. It can put a lot of pressure on the Player and even distract them from playing the game. Some notes are better than others and too many bad notes quickly become the same as having no notes.

Design Pattern: Write Event Cards 

These are short blurbs, a paragraph at most, about an NPC, place, event, etc. Any key sensory details, relationships, or significance to other important Events, etc. By discretizing them onto cards (see Specific Implementations for what that might entail) they're easier to keep track of, and by having some schema of what they are for and what goes on them, it's easier to know when and what to write, and less stressful or distracting. It's also something a GM can just as easily do for their Players or alongside them.

Specific Implementation: Aspects (FATE); Flowcharts; Pinned Discord Messages; Physical Notecards; Computer Database

The most straightforward implementation is just physical notecards. You could also do pinned discord messages if you're playing digitally, or make a SQL or noSQL database if you want to be fancy about it. I personally have grown fond of flowcharts, like you'd see in Crime Dramas, for connecting the Event Cards by their relationships like a graph. The game FATE has a mechanic called Aspects, which takes this idea one step further and actually ties it into the core gameplay loop so that they are not only not distracting, but are actively additive to the game.

If people find this interesting or helpful, I may post more Player Design Patterns in the future. I'm still early in this journey of rediscovering what it means for me to be a Player, given everything I've learned over the years about how to worldbuild, GM, and design games. Besides Design Patterns per se, I have some other thoughts, like the role of Players in a game vs. the GM, or the Player/GM interaction, or Player/Player interaction. We'll see where this goes. I'd also like to maybe just discuss my own anecdotal thoughts and experiences from being a Player, and what I want out of a game as a Player, and so on.