My Games

Wednesday, April 7, 2021

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.

2 comments:

  1. As far as I can tell, the origin of the "Quantum Ogre" concept is:

    https://dreamsinthelichhouse.blogspot.com/2011/09/fixing-quantum-ogre.html

    Dreams in the Lich House, September 10, 2011:

    The Quantum Ogre
    The problem of the quantum ogre is this: assuming the party has no additional information, there may or may not be an ogre in the woods. Once again, he's not necessarily violating agency from the player's perspective when the ogre is dropped in front of them; the player choice was to enter the woods and search for the MacGuffin, and it's a reasonable expectation there could be an ogre in there. From their viewpoint, there's no difference between these scenarios: walking into the woods and running into a scripted ogre they failed to learn about; a randomly generated ogre via an encounter table; or the ogre the DM dropped on them through sheer fiat.

    But when the DM *always* places his ogre encounter in front of the players, he's predetermining an outcome and perpetrating a railroad. We can always identify the bad behavior from the DM's side of the screen, even if the current state of player knowledge doesn't allow them to see it.

    ReplyDelete
    Replies
    1. Thank you, I couldn't remember / find the source!

      I forgot how the original explanation took such a negative stance on the idea lol. I acknowledged that it's more of an invisible railroad than true Modularity, but I personally think it can still be a useful Implementation, especially if you're just learning all of these things in the first place.

      As I said, I'm not necessarily interested in arguing the particulars here, I can definitely understand why somebody might not like the quantum ogre. Even if you don't like it though, to properly understand why you don't like it, requires that you have some sense of Modularity as a Design Pattern and how this Implementation arguably violates it. Again, my opinion is that at least to some extent, the illusion of Modularity can work towards the same ends, but I can respectfully disagree with someone on that point.

      Anyway, maybe you agree with me as well and were just pasting in the source text haha, so in any case thank you for that.

      Rather than getting into a discussion on the Quantum Ogre specifically, do you have any other thoughts about the Player Design Pattern, or other kinds of Player Design Patterns or Player Tools?

      Everyone already talks about GM Design Patterns, I'm trying to talk about stuff that hasn't already been talked about to death haha.

      Delete