Well, now we start diving into the deep wells of what people classically think of when running a game, and I wanted to start off by talking about the two most commons structures for a game. If you've moved around in RPG circles for awhile, you've doubtlessly heard of them and might even have opinions on which is better: "railroads" vs "sandboxes." I'm going to tell you what I think in brief, and then we'll dive into what I mean.
In short:
- Sandboxes are better than rails
- But it's not really a choice between one or the other; you'll really need to understand both and to realize that it's more of a sliding continuum.
- As a beginner, you should focus on learning and mastering rails; sandboxes will begin to come naturally to you as you become more experienced.
If you're unfamiliar with the concepts here, let me briefly outline them.
A railroad or a game that's on rails is very linear. A good example would be a typical "linear" computer game. You show up, you get objectives, you go down narrow hallways that never branch, you achieve your objective and you advance to the next stage. Your progress is so linear that you never deviate, as though you are a train on rails (hence the name). If we use our basic story concept from post II, that of monster hunters rescuing a doomed child from a cult, then our story might go something like this:
First, the heroes go to their homebase and receive an assignment. Then they accept the assignment and go to the particular world where they need to do their mission. Then they journey on a direct route to the fortress, and fight some monsters along the way, then they fight their way through the fortress and rescue the child. Then they decide to protect the child, which brings us to the next act.
A key realization to take away here is that the players don't have a choice. In the strictest sense of a railroad, they are going to do these things, and they cannot advance the plot if they don't. The last one is particularly noteworthy, as many players might say "Wait, why would I protect this child? Why wouldn't I just turn him over and get a payday?" the answer is, of course, to advance the plot, but a lot of players tend to buck against this sort of thing and resist it.
A sandbox, by contrast is very open. A good example of a typical "sandbox" game would be most open-world games, or games like Minecraft with no real objectives. You show up and ask what you can do, and the GM shrugs and says "I dunno, what do you want to do?" You're tossed into a vast ocean, able to go wherever you want, and given no real objectives or direction. Your progress is entirely up to you, and there's no sense of urgency or directive. If we use our basic story concept form post II, then we focus on the monster hunters as a group or a faction, and the world in which they inhabit. They can choose from any number of possible jobs, go anywhere they like, and do whatever they want. Our story might look something like this:
First our heroes go to their homebase, and then look over a board of possible jobs, and pick one and then decide what to do, and they can really do anything, or any combination of things.
A key realization here is that when you're building a sandbox, you're not creating a plot, you're creating a setting, and the plot naturally emerges from how the players interact with the world. The two major problems you run into with this approach is a sense or aimlessness or purposelessness from the players (they don't know what to do or where to go and any direction seems as good as another). The other is that you have to plan for all of this. In our above example, if we dedicate a week to working out the "rescue the doomed child" plot, and nobody chooses to go there or take up that mission, we've wasted all of that time. A key to mastering sandboxes is understanding what to plan for, and how to make sure you waste as little time on needless elements as possible.
So, why are sandboxes better?
At the end of the day, an RPG turns on choice. You are more likely to have players who bristle at you presenting false choices or removing choices than they are at having a sense of aimlessness. Taken to its ultimate extreme, rails aren't even games, they're just plays where everyone says their line and performs their pre-determined action.
Rails are brittle. What happens if your players don't want to rescue the child? What if they just turn him over to the cultists and wash their hands of it? Then your entire story has been derailed and you're lost, while if you've built a sandbox, if the players decide they don't want to rescue the child, well, you still have the Space Dragon and the Space Princess and that extra-special training on a secret world, etc. Sandboxes are more resilient in the long term and broadly more pleasing to players.
In the long run, thinking of your game as a setting in which narrative naturally emerges becomes a more resilient way of prepping a game, because in the long term, you can return over and over again to your sandbox and "construct" stories from it fairly easily.
Oh, so I should just sandbox then. Why are we even talking about rails?
Because nobody runs a pure railroad game or a pure sandbox game.
A better way to think of sandboxes vs rails is to think about setting-driven games vs plot-driven games. When you're prepping a sandbox, you're really prepping a setting. You're creating a context for your players and inserting them into it. When you're prepping a railroad, you're really writing down plot. Games honestly need both. You need to have a setting with which the players can meaningfully interact, and you need a plot that drives the action forward. There are lots of ways to do this, from creating a "rail" that consists if a sequence of small, tightly bounded sandboxes, or a "branching" set of rails, where players need to follow a long a particular story, but they reach certain "choice points" where the GM has a good understanding of both branches (like "if the players don't choose to rescue the child, this happens instead..."), or a broadly defined setting with lots of interesting hooks and features from which the GM and players can collectively improvise a coherent plot that follows predictable lines.
I personally find this last the most desirable sort of game, but to create it, we first need to understand a lot of things, especially about how plots work, which means we need to understand rails.
So why, as a beginner, should I focus on rails?
Because you need to learn to walk before you can learn to run. In the end, railroad games work a lot like how a book works, and people tend to think more in those lines. If you go back and look at my initial inspiration in post II, it fits more neatly and more intuitively into a railroad-sort of game ("the monster hunters accept a mission; the monster hunters go to the planet; the monster hunters fight the cultists; the monster hunters rescue the child") than it does into a sandbox game. It's easier to get you started, and getting started is the most important part of all of this.
Rails also teach you the structure of a story. You can think more easily in terms of act structures, in terms of "escalation of tension," and in cause-and-effect. If I may make a musical analogy: learning to run a game "on rails" is like learning to read sheet music and learning to play a musical instrument. Once you've learned to do that, then it's easier to learn to improvise music in things like "jazz," as people start to teach you scales and you start to "play" with the music you learned on sheets. By the same token, eventually, you'll need to learn to improvise a story, but it's easier to do that if you know how a story works, and it's easier to learn how a story works if you follow easy-to-understand linear stories.
As you get better at rails, you'll learn how to bound your players reasonably. For example, consider the choice of rescuing the child. In a lot of ways, it doesn't make sense: the monster hunters were hired to retrieve the child, so they should. Why wouldn't they? If you just inform them that they've made such a decision, they'll likely rebel, so it's better to think of plausible reasons for them to make the choice you want them to make, or for you to shift the context enough that the choice is no longer particularly relevant, then the story will naturally flow along the lines you intended.
For example,
- if the child heals or helps the party, they are less likely to turn him over to people who will hurt him
- If the cultists betray the party, the party is less likely to want to complete their given mission
- If the cultists already believe the party has betrayed them and act as though it is so, the choice if largely mooted.
- If the players understand that this is the story, or that they are heroic characters, and that this fits genre conventions, they're likely go to along with it
"Good" railroad GMs learn to hide the rails, to make the players think it's all their own idea, or accept that they have only specific choices. This makes the bounds places on the players harder to see, and the whole story feel organic. This is a vital step to learn, even for sandbox games, because you cannot provide an infinite sandbox. You must, inevitably, bound your player's choices, and learning rails helps teach you how to bound them in an efficient and effective way.
Well-bounded plots are also just easier to plan for. Trying to "plan the world" is a recipe for failure for a starting GM.
Once you've learned how to write a proper plot and how to guide the players down that plotted path, then the next step after that is to learn how to loosen up those rails, to give them real choices and to highlight major choices so they don't assume they're perpetually going down rails. Then, eventually, you'll learn to discard all of that, you'll have "learned the form so you can master the formless" and you'll learn to think in terms of setting and natural, emergent plot using the plot beats you mastered on rails, as well as how to focus your planning on what really matters, as well as to predict the typical choices of your players, then you'll be ready for the "better" sort of game in the form of a sandbox.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.