Saturday, February 5, 2011

The Campaign: Gosub, Return

If you're intent on running a roleplaying campaign, there are things you can learn from the programming languages of the 1970s.

No, seriously.

Those whom the gods would destroy...

No, seriously. I am comparing running a roleplaying campaign to programming in BASIC.

It's possible you don't even remember BASIC. (It's also possible you didn't have to deal with it the first time around, you lucky, lucky stiff.) It stood for Beginner's All-purpose Symbolic Instruction Code, and in the late 70s when the "home computer" first caught on, BASIC was the language of choice.

It was designed to be easy to learn—heck, the word "Beginner's" is right there in the acronym. It was also easy to write software in BASIC, inasmuch as it was easy to do anything on a command-line based terminal. You'd write your code one numbered line at a time and the computer would keep everything straight for you. You could type lines in out of order, and the computer would sort them for you. And then you'd type RUN...

Unstructured Programming

Mention BASIC these days, and some folks who know programming will instead hear LEPROSY. There's a problem inherent not just in the various implementations of the language, but the design of the language itself: it doesn't defend itself sufficiently against sloppy programming or bad programmers.

That sounds like a strange way to put it, I know, but there are many ways that a system can defend against programming errors. And the implementations of BASIC in the 1970s... just didn't have those safeguards. There were numerous reasons why, including (and especially) that there was no room for them in the computers of old, but those aren't so important for this posting.

Come on, how is any of this important for this posting??

Creating a campaign isn't just like creating a story. The campaign is a series of events, some of them highlights of the main story and some of them sidelights (side quests, if you will).

A program is also a series of events, many of which are part of a main sequence of steps. And a few of those events are sidelights, out of the normal flow of the program but still important in their own right. The GOSUB statement I referenced above is the command that would send processing of a BASIC program into a subroutine. And the RETURN statement would bring it back.

If your subroutines called too many other subroutines, a BASIC program on certain computers would break. Nest six GOSUBs on the TRS-80, and your program went down like a poleaxed steer. (I know this from experience. Used it to good effect, too, but that's a story for another time.)

Likewise, if you stack too many of those sidelights in sequence, you'll lose sight of the story that you had originally planned to tell.

That's the danger of both unstructured programming and unstructured campaigning: the unstructured program becomes a morass of tangled logic and confused steps, not quite sure where it's supposed to be going. The same can happen with a campaign: it starts out with a clear direction and the best of intentions, but as the detours pile up one on another, that original direction and purpose get lost and nobody's quite sure what anybody's supposed to be doing.

But I'm not writing a program! I'm just having fun with the guys!

I'm sure you are, you intrepid adventurer you.

But have you ever been in a campaign where you were tasked with an important noble task, like rescuing a princess, then you set out to where she's being held, hear about some other exciting adventure, go heading off toward that, have a dozen other adventures which takes you halfway across the continent, and then suddenly someone asks, "Hey, whatever happened to that princess?" You may have had a moment of confusion as you realize that there's a whole bunch of stuff that you set out to do that you never quite did.


Fun, certainly, but it's a campaign in much the same way that cotton candy is a food. Or to return (ahem) to the previous metaphor, in much the same way a subroutine is a program. What you may have experienced there is a whole bunch of campaign snippets, things which could be fine campaigns if carried out to their logical conclusion but never quite make it because you keep finding newer and better quests to get sidetracked by.

Structured Adventuring

The proposition here is that the campaign should have one overarching story at a time. It provides a level of focus, presents a clear goal that people should work toward, and allows for a sense of satisfaction when that major obstacle is finally cleared. It does not mean that a campaign can only have one major story, but for the sake of keeping things sorted out, it should only have one major story at a time.

Linear is So One-Dimensional

This would be such a linear structure.


It's a valid structure. It's also very easy to follow—the only way to make this simpler would be to reduce its length. This is a structure that only the most stupid and/or devious could lose their way in.

That simplicity comes at a cost, though. It's a bit unrealistic; it assumes that absolutely no interesting distractions will arise between beginning and end. For that reason, your players might resent being put on something so straightforward. It's akin to riding a train. There are no opportunities for detours, just a single plot that one rides from beginning to end. The structure is not just childproof, it's not just tamperproof, it's playerproof too. They'll feel like they have no control whatsoever. I have it on good authority that players hate that feeling.

Linear, But With Scenic Overlooks

The trapped-on-the-rails feeling can be eased a bit by including some options in the journey. Consider this variation of the linear structure:


As you can see, there's more going on here than a strictly linear plot. The chain of events is still unbroken, but there are a few places where the players can "stop and smell the roses." Assuming they start at 1, they have options (which they took) at 2, 4, and 7 to detour out to 3, 5, and 8. At 6, there was no detour to be taken; this would keep them focused on the goal. And at 9, something happened. Either the players didn't pick up a hint or earn a side-quest, or they decided that it wasn't something they had to pursue at that time.

Here we also run the risk of repeating the earlier problem. Remember that first diagram I posted? Consider the problem it had: you had one linear path, which led onto a second linear path which had a spur onto a third path... Seven detours in, and the original quest was pretty much toast.

That's something to watch out for. Rule of thumb: Either limit how many steps you take off the original path, or make the reward at the end of a path like that something that'll not only help the PCs on their original quest but remind them what that quest was.

Gosubs, Returns, and now Ifs

The problem with any linear structure, at least when storytelling, is that you've got one and only one destination. The denouement might not adequately reflect the characters' hard work or abilities.

Up until now, I've been talking about the plot structure as if it should only have the one destination. It doesn't have to be this way, though. Here's a rather extreme case:


We know where the start is. But this graph is radically different because it has a lot of decision points: depending on what happens in an encounter (or an adventure; this structure could be a lot larger than a single series of combats), as the game progresses in time (from left to right), the PCs will have varying degrees of success (from top to bottom) on their ultimate mission.

For instance, after the start, they get into a situation (1) where the outcome will either put them at an advantage (2) or disadvantage (3). Note that from 3, it's impossible to get to the best success; even from the start, they'll have to ace three different encounters (or adventures) to get there, and that shouldn't be easy. The situation deteriorates further (4), but the PCs get a chance at a reprieve: if they can capitalize fully on that situation and the next one (5), they still have a chance to get back on track for at least the second best ending.

The graph doesn't have to look like that. That is just me experimenting with graphics. If you draw a decision grid, you could make it as small or as large as you like. Even a single decision node allows for two endings. As long as you understand the concept, you can apply it to your game.

The Combination Application

I've tossed out two concepts: create a decision-based flow for your adventure or campaign, and include short side-quests. They can be combined. A timely short detour for additional information or resources could, for instance, give the characters an edge when running through a situation that could turn out badly.

Actual Mileage May Vary (Beware of Falling Rock)

Ultimately, what works and what doesn't work will depend on your players. It may take a little practice to determine just how far out from the main adventure's flow you can stray without sidetracking them, and how badly they'll chafe under the tyranny of a literal flow.

No comments:

Post a Comment