FEMA ICS/CRM as TTRPG SOPs: or, Using Government Strategies In Your Game Design

    Y'ever just get a thought in your head for one of these here blog posts and go "No...no, I can't write that. There's no way that people will read this and not think my head is lodged so firmly up my own ass that when they call EMS to save me, not even the Jaws of Life will be able to pull it out?" This is one of those posts.

Not pictured: my head or ass. Use your imagination.

Get Me Those TPS Reports

    I do not and will not talk about my dayjob as a general rule - not because I'm ashamed of it nor out of any particular degree of personal safety (my name is my brand, after all, if someone's going to come and kill me there are much easier ways to find me than indulging my ramblings on this blog) but this one time I will say that during my training for a new position I've taken, I was introduced to the emergency response procedures used by the federal government here in the United States (at least, in theory, when those organizations aren't being defunded): specifically, FEMA's Incident Command Structure and Comprehensive Resource Management principles. Now, I'm not going to just re-teach you what I learned in my training - if you're really interested after you read all this, there's actually plenty of information up on FEMA's homepage and on YouTube. But after watching many, many hours of instructional videos, I began to realize a few things:

1. The people who came up with these principles designed them to be broadly adaptable to any number of situations that could arise
   
   
2. Adventuring parties are, functionally, national disasters 
   
   
3. Understanding and mapping the effective flow of information during An Event between the people in charge and the people who need to act on it is not unlike writing an adventure module, complete with the fact that optimizing that flow can highlight actors that are underperforming/can be reassigned
   
   
4. High level tactical play in certain RPGs both on the PC and GM side mirrors threat responses 

    With this in mind, and with the Appendix N Jam deadline looming ever closer and only my cover page being properly mapped out, I sought out to see if I was completely full of shit or if I might actually be onto something here that could help me write more effectively. My apologies to anyone who works at FEMA or who has had to implement any of this in an actual emergency - I'm going to be butchering this for my own needs here, but please know I think your current training is very nice.

Incident Command Structure

    Pictured above is a sample ICS diagram - at the very top, you've got the person taking ownership of the entire situation, below them you've got the people who interface with the public and with other people working The Event, and then below them you've got four separate branches: Operations, who are responsible for getting everything set up and making sure things go smoothly throughout The Event; Planning, who handle documentation before/during/after The Event; Logistics, who make sure things get where they need to go; and Admin, who manage expenditures of time and money. While not everything maps 1:1, if you start looking at the writing of an RPG adventure as An Event, you could use that map to separate things into the following categories:

• The very top level is The Author - the person responsible for shaping the flow of the game.
• The roles that report directly to The Author are basically Marketing, Art Direction, and The GM. 
• Operations would entail any NPCs or story beats that are responsible for the interstitial movement of plot - that is to say, the driving forces, the things that interact directly with the player characters to provide input on what is going on in this adventure.
• Planning would be any critical things that the players need to progress through the adventure - your MacGuffins, your Things The Players Should Already Know, the Things Your Players Must Learn To Make Meaningful Choices, things like that. 
• Logistics would entail how any information from the other sections is delivered to the players and to the GM - the "Service" side being the players, the "Support" side being the GM.
• The Admin section is the least directly analogous in shape but still looks the same in functionality - it's the ephemeral blob of levers and dials the game provides and the GM brings with them to control the flow of the adventure itself

Let's take last year's Appendix N Jam winner, The Knight Errant. Ignoring the meta elements (i.e. the Marketing, Art Direction, and The GM), an oversimplified ICS flowchart of The Knight Errant could look like this:

    You could spend a lot of time breaking down each element of the game beat by beat, which is probably what I will do when applying this to my own work, but for demonstrative purposes (and without spoiling too much for those of you who have somehow not already gone and read it/listened to the Between Two Cairns review of it) you can kind of see how this plays out - you've got your main named characters responsible for moving the plot along as well as the big random events that cause time pressure in Operations, in Planning you've got all the things that the players explicitly need to find/interact with/know about, Logistics shows how the information gets to who it needs to get to, and Admin details things that depending on how you implement them will either speed up or slow down the game - but likewise, depending on how much people players interact with them, may affect the overall "value" of the experience or perceived efficacy of the writing/GMing of the module itself.

    Is this basically just a different way to outline? Yeah, of course it is. But we're not done yet!

Comprehensive Resource Management

    What really strikes me about the layout of CRM is that this really does detail a strong approach both to playtesting as well as for players actually playing a game. From the creator side of this:

• Before running the actual module you're writing, you sit down and lay out the plot (the Incident Objectives), your interactable set pieces and/or intended solutions (Strategies), and how you envision the Platonic Ideal Run of your module going (Tactics).
  
  
• You then test your hypothesis: take stock of what the player characters have at their disposal, throw situations at them, see how they react to them, talk about what went well and what went poorly with your playtesters, then try it again with another group while making changes and documenting the new results.

From the player side of this, however, this is kind of the unspoken calculus underpinning every adventure:

• See what your party has at its disposal 
• Learn what the adventure is going to be about & stock up on supplies/information 
• Start dungeon delving, and 
• After each encounter assess if you're still able to keep delving or if it's time to pack up and go back to town.

    Obviously that just describes a very particular kind of play mostly common to the OSR (and, statistically, if you're reading this you're probably an OSR-head with a lot more experience than I have anyway so what are you doing here?) but I think it's broadly applicable to more story-focused games as well. Who among us here, after your PbtA game of choice, hasn't looked at the playbook you've chosen at the end of a session and thought "Y'know, I bet I'd be more effective at getting across the point of my character if I planned towards this move next/focused on this aspect of my character/roleplayed out this condition I've taken" or the like? I think there's real room to be explored here by people who want to quantify what they're doing - and not everyone would want to, of course, but for those who do having a standardized format to assess the choices you're making means that you have a repeatable methodology across your gaming career to help you play the kinds of characters you want to play/have the kind of gaming experience you want to have.

In Conclusion

    Was this mostly a way to try to relate the things I was learning back to something I care about that is immediately relevant to me so as not to fall asleep during training at work? A bit. But do I stand by this? Yeah, I think so! I'm going to try out the ICS breakdown once I've got March of the Eld Kin written out, and if I have a chance to do a playtest of it I'm absolutely going to be using the CRM-inspired methodology I detailed above. Do let me know if this ends up helping you at all.

Stay weird out there, and good luck to everyone else scrambling to get their Appendix N Jam submissions completed!