(re-post from Google+ — seriously, that’s where I most ramble now but someone suggested I should make this mutter more permanent, so it goes here)
I think I stumbled on what I dislike about “railroaded” game campaigns and, as usual, it’s by way of an analogy.
First, railroading is obviously a continuum. It’s a kind of failure in scenario design but it’s not a make-break failure. As with any design defect (I’m thinking of other design contexts, like hardware or software, and there’s the analogy pointed out for those of you that don’t like solving my little puzzles) it’s not necessarily catastrophic in itself but rather makes the follow-on work (the implementation and the maintenance) harder and that’s what’s a problem.In system design we’d call this a problem of brittleness: increasing railroading makes the design more brittle. That is, it’s less resistant to unanticipated events. It’s harder to change a small part without impacting other aspects of the design. So if a railroad (and this is funny to me since I design real railroads sometimes) is a brittle design, maybe the reasons for brittleness in system design are similar?
Usually it’s a problem with coupling. You see coupling errors (they aren’t really errors, but from my perspective they break things so I flag them as errors) in software all the time and often they are a result of Bad Laziness (distinct from Good Laziness): part of the problem is hard to solve so the designer makes it someone elses problem and now an inappropriate subsystem has to do work that impacts the appropriate subsystem. Now changing one black box affects the functionality of another in ways not covered by the interface spec. This is brittle: I can’t change the design of one component without investigating other components. In a big system this becomes a whack-a-mole game worth millions of dollars and thousands of ergs of customer good-will. Brittle is bad.
Coupling is the problem in railroading, too. Events later depend on the outcome of events earlier in a way that is inappropriate. In system design we’d solve this in a way that’s useless to a scenario designer though: in a game we want more flexibility with less dependence whereas in a system I’d just lock down the functionality and the interfaces and analyze for coupling, moving functions and features as necessary to recover the design. In a scenario this might be boring as hell. It might not even be possible. I’m not even sure where the analogy goes if you head down that route.
The coupling in scenario design happens when a planned scene can only happen if a previous scene resolves in the way predicted by the designer. This strikes me as a red flag right out of the gate: the scenario design depends on reliable prediction of the future. You need a fair amount of magical thinking to believe that will work. When trying to plan for the future (this actually relates to safety design methods by the way) you can try to enumerate all possible outcomes and address each, of course. This will not work. It’s a novice’s first guess at solving this kind of problem and it fails because you will miss something.
What you can do, though, is categorize the kinds of future events rather than plan in detail, and create plans that are similarly categorized. If the villain is thwarted in this scene then we need some kind of new threat. If the players decide their characters are interested in another direction of exploration then we need something there to explore. This leads to general solutions: I need a map that extends in all directions. I don’t need to know in detail what’s everywhere, though, I just need some tools to slow pace until I can go home and plan the next session (here’s where I fall in love with random encounters, by the way — they don’t need to fit the plot because everyone already knows they are random and, frankly, if the players cleverly find a way in which the encounter is consistent with the plot, well, yoink, I am totally using that). If they are disinterested in the objective I thought was interesting, then I need a few ways to make it interesting (your tool here is the character sheet: what did they say was interesting?) and see if those work. If not, listen and delay!
Anyway, I admit that’s just rambling and not an argument. Railroading is brittle. That’s why it sucks. Not sure if any of that other stuff follows.