Sunday, August 6, 2017

Adventure Writing

The last post has established that we're looking for a certain type of structure, which ensures both inefficiency and success at the same time.  But how do we identify the tolerance level that the party has for either.  It's true that there isn't one tolerance level for every possible party, but that's no really helpful.  We probably won't be running with a lot of different parties and, in any case, our presence is going to skew different parties towards the same median.

The strategy for everyone to find that median is the same, no matter who is running or who is being run.  That strategy is experimentation ~ and those who won't employ it are bound to be weak or abusive DMs.

Unfortunately, most of us, the writer here included, were initially trained to think that an adventure design worked like writing a book.  We write the whole book, every inch of it diagrammed and sorted, and only when the book is complete do we dare present it for our players to try out.  Frankly, this is pretty stupid. We keep talking about how the game is supposed to be a collaboration between the DM and the players, but then we send the DM off to work in total isolation while we wait like an audience of critics waiting to tear pieces out of the DM's solo design.

We do this because this is how modules were designed.  Modules have to be designed like this because they are products, in which all the collaboration takes place between the fabricators prior to handing them over to the manufacturer.  There is NO collaboration between the maker of modules and the DM, and then no collaboration between the DM and the players.  It is passed down the line with the message, "This is as good as it gets; if you don't like it, tough."

DMs then try to rewrite the module a little (still solo), to tailor it for the players, but we still don't have much recognition of the players tailoring the module for themselves.  At best, we have this desperate ploy: a very old story describing what most DMs do when they're noobs and don't know better.  It goes like this and it's familiar: the DM has nothing planned, or has something planned which doesn't seem very good.  The players speculate about what might be up ahead; the DM hears this and thinks, "That's great!  I'll do that!"

Is this what I mean by the players collaborating with the DM to make an adventure?  No.  But we'll come back to this.

We also pre-write adventures because we think this is the only way to make them complicated and detailed, as in what happens with room #4 is very important when the party gets to #7, which has the key they need for room #9, and so on.  We can call this The Myst Method.  The Myst Method sucks.  DMs don't realize this, but they're very tiresome to play over and over and, in the end, the players will soon become savvy enough to recognize what's happening.  The key in #4 might as well have a tag on it that says, "This is very important, test it out in every hole you come to going forward until it fits in something. Thank you, the Dungeon Master."

It's a bigger surprise if the key doesn't fit anything.  Except that we're still going to spend an hour of game time trying the key a thousand times.

Finally, we pre-write adventures because we don't understand design.  We think this is proper and correct. We think this is how stuff gets designed.  It used to be, but now every company that still designs that way has been destroyed in the market place by competitors who employ what's called "agile design."

Let's not get into the particulars ~ there is plenty of stuff online to read if you're not familiar with the concept. You may realize the last post was about agile design.  At present, I want to make a point about what agile design is supposed to accomplish.

Writing the module in one go is called "waterfall design" ~ the old way of doing things.  Basically, the river goes along, goes along, goes along, then it falls off the cliff and there we are.  All designers used to do this; there were no focus groups brought in to question the design, no testing of the product (and no requirement to test it) and sometimes, no assurance that the product would do what it's supposed to do.  Movies and other artworks, for the most part, are still being made this way.  That is why so many of them suck.

Agile design is what's called "iterative."  This means that it is done frequently and repetitively, until what is desired is achieved.  Agile was invented for the software industry, which absolutely died on the vine when attempts were made to design it in a waterfall fashion.  Now, everything is released in bits in pieces, testing it and testing it, relying very heavily on the user to fix what's wrong and improve the experience.  Video game designers release an alpha version of the game, sometimes updated once, then a beta version.  The beta version is then repeatedly released as it is tweaked and fixed, relying on players to identify what must be fixed.  Finally, all the problems have been supposedly identified and the game is released.

Games are much more complex now, with fewer bugs, because of agile design.  Back in the day, when waterfall design was normal, programs were not only crippled by bugs (rather than a few annoying things, like now, it used to be impossible to use software without continuous work-arounds for bugs), there was nothing the company could do about it.  There was no proper effort to account for what had to be changed; this meant that "fixing" a program meant bringing in a completely unfamiliar team, who would have to start on the code from scratch.  It was easier to burn the code to the ground and start again.

When designing your adventure, you want to be agile about it.  But this will immediately produce the response, "How am I supposed to keep stuff secret from my players if I'm sharing the design?"

Easy.  Don't keep it secret.  Have you not noticed how game are played now?  Consider titles like Don't Starve, Oxygen Not Included and Subnautica.  Knowing what the adventure IS won't change the doubt players have about the die, their ability to overcome known enemies or steadily explore vast realms.  RPGs have vastly over-emphasized the importance of fog, as though this is the entire game, when in fact fog is a very small feature.

What is the best part of not knowing?  It produces stress from uncertainty.  But if you know you're equally matched with an enemy, does that reduce stress?  If you know the enemy's intentions or the enemy's abilities, does that detract from the player's level of stress?  No.  It doesn't.  Not in my experience (which I can prove with text from game campaigns, if necessary).

The only time knowledge removes stress is when it tells the players they are certain to win or that they are certain to lose.  Once a player is convinced of either, the game is lost.

So come clean.  Sit down and say to your NEW players in your NEW campaign, directly, that you're thinking of giving an encounter.  Warn them that it is coming.  Tell them, before it starts, before their characters see it, what the encounter is going to be.  See how they react.  Ask them how they are reacting. Test them.  Then, after the encounter is run, find out how they felt about it.  Ask them, was it too hard?  Was it too easy?  Don't take their word literally, as they will skew their responses with a desire for survival, but ask!  You can't learn anything if you don't ask.

Tell your players that you're planning to put a small, deserted keep on the edge of the nearby forest. Don't wait for them to ask a bartender: just tell them, "You happen to know about this deserted keep."  Ask them how big they want it to be.  How much treasure.  How many monsters they'd be willing to fight to get that much treasure.  How many they think they'd have to fight.  Make a joke that it would have to be a lot more and see how they respond.  Tell them that if they can't handle that many monsters, maybe they're not tough enough for the treasure, and see how they respond.  Assure them that there is a keep.  Assure them that there is treasure there.  What the hell.  You think it's some big secret?  You think they don't know you're going to put treasure everywhere they go to fight a monster?

Stop hacking off your left arm to spite your right.  Stop doing this on your own.  Get your players to tell you want they'd like to fight, give them a chance to do it, assess the effect and then start to adjust your plans with the knowledge you've gained.  Obviously, you're always going to be the most creative one in the bunch.  You have the least to lose and you're getting experience watching them.  This isn't rocket science ~ but it is about being forthcoming.  You're not going to make a good game by yourself, not yet.  Someday, but not yet.  You've got to learn first how to design before locking yourself in a room and designing.

3 comments:

James Clark said...

Having spent the last 7 years becoming professionally acquainted with spiral and agile development and more years before that with waterfall design I can say that while you're taking some liberties for the sake of simplicity, they are still very appropriate analogies for what you're trying to express.

Breaking myself of the "recreate modules" mentality and adopting something closer to the approach you advocate in adventure design was an epiphany for me. I'm not sure if its just my experience, or if this is true of many or most of those that came of age with the game, but ditching the module design mentality was actually a return to how I originally played when it happened.

When we were young we were broke and simply couldn't purchase enough modules to keep up with our voracious playing pace. We also couldn't wait for the DM to carefully construct one. We wanted to PLAY. We were doing agile, collaborative development because there was no other option. It wasn't until I got older, had more money and less opportunity for actual play that I fooled myself into believing I needed to either purchase or carefully develop a setting or adventures. It took me years to get over that and finding your blog back in '07 or '08 was a big help in jarring myself out of those bad habits.

JB said...

"Agile design" is a new concept to me ('cause I'm hopelessly out of touch...natch), but what you're talking about certainly applies to the design process of your average "new" RPG...the testing involved at the game table, prior to its release. Applying it to adventure design (unless testing an adventure for publication...which is absurd since what works for one game group doesn't necessarily work for others...*sigh* never mind. There's a reason I don't publish adventures, I suppose...)...

This lifting the fog thing is the real sparkling kernel of this post for me. I know I get stuck in the rut of "here's this mystery for you to explore and illuminate" when you're absolutely right...it's entirely unnecessary. One of the last adventures I penned for a group involved them going after a dragon in its lair. They were presented with everything they needed to know (where it was, the type of creature, its range and habits, etc.) and told "have at it." When they balked ("A dragon?!") I was forced to explain that the scenario would not have been presented if it was beyond their abilities. It felt a little weird (given my history with gaming) to provide so much information up front...but then I remembered it's a damn game! This isn't a gameshow where they're trying to win a thousand bucks guessing in the dark! The game is about rising to the occasion and striving against the challenge presented. It's not about groping around blindly.

[well, only under certain circumstances]

Tim said...

Huh, never expected to see agile design come up here. Lots of software developers bitch about it (especially if you've worked at a big old company like I have where they want to be agile but the organization has grown too complex for most people to know what's going on) but agile design does indeed help with some of what you mention, and the iterative approach is really useful.
The alpha/beta analogy did strike me however as I've always been one to avoid such games until they are stable (although again nowadays the open beta is mostly just to drum up interest) so that I don't spoil the experience for myself because I come across some ridiculous bug in the code. But in a small tabletop setting you can make mistakes all the time and work it out with the players because the game isn't so formal (and hopefully they have not payed for it).

On that note, I really can't get enough of the module bashing! The whole thing kind of shocks me now, because it's so authoritarian: it says that you, the DM, must give us your money for some dull little magazine we've tossed together that you can then subject your players to. It's ludicrously capitalist: no other game outside of video games does this sort of weird hierarchization of the group where the DM becomes elevated over the players by the fact that they made a purchase. The kid playing hockey who buys the fancy equipment is not by any means the superior to the other kids (a poor analogy perhaps). If there's anything that helps perpetuate DM screens, DM fiat and DM arrogance, it's module culture which tells the DM "here's this organizational document we will give you to apply to the players which you may know but they may not".