Systems Thinking Chapter 2: Green Slime
As a graph, this is what a
The vertical axis could be all kinds of things. In graph 1 it might be player dis-satisfaction. In graph 2 it might be game challenge. The point is that the problem gets worse over time exponentially.
Here's the green slime loop as a generic system diagram:
Performance is some measurable quality (not necessarily quantifiable), such as player satisfaction.
Consequences are what happens as performance changes.
Growth Action is an action or requirement that drives the loop, usually a rule or maybe a behavior.
Performance Drive/Action Consequences is simply how this action reinforces the performance change.
THIS IS ONLY AN ILLUSTRATION. It's meant to give a generic idea of how the loop functions. It's not a template into which you can plug bits of your game and get a magic result!
Actual Play Example
This isn't a great example, but it's the best one I can think of right now.
When my friends and I were relatively new to RPGs, we achieved the impressive coup of getting my older brother to play with us. A buddy of mine GMed a pretty standard D&D adventure. The GM wasn't sure how to determine what monsters to put us up against, so he went through the Monster Manual and looked for monster whose combat damage was low enough that even if the monsters did maximum damage, it would take two hits to kill us. The monsters were underpowered, and the players started to get bored and restless. In an effort to fix the problem, he upped the number of monsters. Instead of 4 goblins, there were 6, and then 8. Combat took longer, but the monsters still weren't able to actually threaten the survival of the characters. This made the players even more bored and annoyed. Eventually, my brother suggested a better foe for us: an ettin. "But that can kill you in one hit!" the GM objected. "Exactly" was the response. The GM relented and we had a close combat where a couple of characters almost died. Everyone had fun.
The problem was the GM's unstated rules of "use monsters that need two maximum damage hits to kill the PCs". This was a perfectly reasonable action to take in a game system that provided a large number of monsters, but no rules for matching them to the strength of the characters. Here is that situation as a system diagram:
In this case, the solution was to discard the ad-hoc rule that was reinforcing the loop and increasing player boredom.
The point of the whole systems exercise was to identify the issue so that you can work towards a solution. In this case, the more experienced player (my brother), could see the trap the GM was falling into and use his own experience, or perhaps his own ad-hoc rules to suggest a better solution.
You might have noticed that this loop was also a symptom of a lack in the larger game system. In this case, it's likely that more problems would crop up later in the campaign because there's still a bigger root problem to be tackled. Figuring that out is part of systems thinking too. Hopefully we'll get to talk about identifying larger systems issues later on.
Can anyone suggest a better example of a reinforcing loop? Anyone have an example of a case where a reinforcing loop has a positive impact on gameplay, rather than negative? PLEASE COMMENT even if it's just to say you think this is a load of bunk. I really want to hear if anyone else is finding this as helpful as I am.
Labels: systems thinking