Take, for instance, the Agile Methodology, complete with manifesto. Yes, it's a big buzzword with a certain amount of "The Latest Big Thing" attached to it. I've used it at work, and it's got some decent ideas.
What Is Agile?
(NOTE: If you're interested in debating the semantics of Agile, please find a different forum. These are my personal observations in the pursuit of hijacking disparate ideas to improve gaming, not a commentary on Agile.)
In my mind, Agile gets the management out of the way of the project to let the workers develop their own solutions. There's more to it than that, obviously, but that's my core idea of Agile. Agile values the individual more than centralized authority. Agile breaks projects down into small chunks for development and testing in a shorter time cycle, and it improves customer satisfaction through constant interaction and delivering those chunks incrementally instead of waiting for the entire project to be done. Under Agile, it's easier to adapt to change, and isn't that something we're dealing with at the game table all the time?
Scrum is a form of Agile which breaks projects into 30-day "sprints". So you carefully define something to develop and give the team 30 days to make it happen. The team meets for quick daily update meetings colloquially called "scrums" for its relationship to the huddle-like formation in rugby. There's a customer representative (called the Product Owner) at these scrums for near-instant feedback from the user to any question the group comes up with. At the end of 30 days, something gets delivered.
Sprinting at the Game Table
So what if you treat your game group's adventure like a sprint? There's a well-defined goal, like recover the artifact, or stop the orc invasion, or convince the duke to raise you to lordship. The party goes off and tries stuff in support of that goal. The party meets and adjusts its plan based on encounter results, so if someone botches a Diplomacy roll they'll have to switch tactics to something other than talking. At the end of the adventure they get rewarded and update the playing field to choose another adventure to sprint through.
Concept: GM as Product Owner
 |
| Reimagined technical book covers shanghaied from Global Nerdy. |
For a GM, this shifts the focus away from angsting over how the party is going off the carefully-constructed script you've mentally organized and toward being present to deal with the party's decisions as they happen. This frees you up to play the game and dance one step ahead of the party, pulling in plot dominos and building an interesting story on the fly. You may have an idea of what's going on behind the scenes, but since nothing becomes real until the characters experience it, don't be afraid to change things in the name of a more interesting story.
Concept: Encouraging Party Scrums
In my games, I'm always dropping scattered bits of information, usually to a single character at a time. If the players take the time to go through their notes and start putting pieces together, they may be able to find a pattern and jump to a whole new plotline. But they're never going to do this if they don't share information regularly, even if you need to create an NPC to ask questions or demand answers.
In some cases all the players are present as one or two characters find out a new tidbit of information, but it pays to encourage everyone to talk about what's happening in the game. Someone may forget a key piece of information until prompted to look it up when someone else mentions it. A character may not realize they have a scrap of paper containing half of the recipe for a Philosopher's Stone because they're illiterate. Information is the medium for a deep game, and the more you can encourage the players to ask questions, the more ideas you'll have and the quicker you can pick an interesting plot to develop. Curious players can feed you plots without even realizing it.
 |
| Iron Coast relationship map nicked from One Seven Design Studio |
I know that I'm doing a good job GMing if I can leave the room and the game continues without me. In my games, this usually happens during a party information exchange session. When the players talk in character debating in-game strategies and what to do next without me there, I feel like I've created some interesting choices and gotten the players engaged in the game. It feels like I've created something much larger than I could do alone, and even larger than the sum of what the entire group could do.
It feels like I'm a gaming superhero. That feeling? That's why I GM.
Granted, some instances require the GM's participation. Combat usually needs the GM to play the antagonizing side, but you can do great things with someone who can step up and play an NPC for you. I did this for tabletop RPGs way back in the Gamut O' Games, but it's far more common in LARP.
The point is, you're not the be-all, end-all of your game. You're creating the game for you and your players to play with. If you use your GM powers jealously to maintain what's in your head, like a more traditional rigid project manager might do, then you're not playing the game any more. Soon trying to control your players will feel like a crushing workload that you've chosen to bear in the name of your game.
There's more to unpack here, but I'm not all that experienced with Agile, and I thought I'd stop after a few ideas. It struck me that Agile and Schrödinger's Gun GMing had at least a few philosophical points in common, and I needed to get that out of my head and onto virtual paper.
Maybe now I'll take my own advice from this article and just write about Schrödinger's Gun GMing rather than trying to stick to an outline. I can always reorganize it later. Or as the film director would say, "Good enough; we'll fix it in Post." Onward!
Thanks for reading!
Go to the Schrödinger's Gun GMing Cover Page.
No comments:
Post a Comment