Tag: genres

different kinds of writing

Making Up Roleplaying Games

In tabletop roleplaying games, there are traditionally two sets of people around the table: the players and the gamemaster. The players have a character they control, making decisions for that character, determining how they react to the situation and the environment. The gamemaster – or whatever other term is used by the ruleset, but GM is generic – describes the locations where the characters find themselves and the actions of the inhabitants of those locations. These are traditionally structured roleplaying games such as Call of Cthulhu, Savage Worlds, or (if you must) Dungeons and Dragons. Let’s call these tactical roleplaying games, as opposed to storytelling games.

Some groups play these tactical roleplaying games as exaggerated board games or skirmish war games: you have figures on a map which you move to attack or defend. Some groups play solely for the joy of plunder: break into the dragon’s cave and try to make it out of the dungeon with as much as you can carry without becoming a crispy fried snack.

Some people prefer to play as players, dipping into another world the GM weaves for them, enjoying the camaraderie around the table.

I like to GM, and I like to tell stories. And I really like to write the scenarios my players will play.

Writing roleplaying scenarios is different from other kinds of writing. The structure of the game depends on the kind of story you want to tell, and can be seen as lying on a spectrum between sandbox and railroad.

A sandbox is a setting where the players can do anything they want within the constraints of the location. Typically this will be a small town, but the classic dungeon is effectively a kind of sandbox. The challenge here is to describe enough of the setting that as a GM you can make it seem real even if the players want to go somewhere you haven’t written yet. Obviously, with a dungeon the players are constrained by what they can reach, but in more open settings the players can go pretty much anywhere. This approach is good for something analogous to a themed short story collection – telling lots of small, perhaps interlinked, stories.

In a railroad you have a series of linked scenes where each scene follows on from the last. The players can only move on to the next scene if they resolve the one they are in. This is like a linear narrative.

Most games fall in between these two extremes. Roleplaying stories tend to run across multiple sessions – what is called campaign play – and in that case a sandbox which leads to short railroaded episodes is pretty common. The railroading may not be that explicit, either – there are multiple ways to solve a problem, for example, or the order in which a set of tasks are to be completed is not specified. Trying to avoid the appearance of railroading even when that is exactly what is happening can be important: some players don’t like that.

So the challenge in writing roleplaying scenarios is to capture the choices which the players have, without constraining what the players can do too artificially. A supplementary challenge is to have the material needed for the players to play – if you’ve spent hours crafting the Dungeon of Dismemberment but the players decide instead to go to the Forest of Death and Blood, then you’re going to have to do an awful lot of extemporising (or break the fourth wall and tell the players where they can go). You also have to be cogent of the players’ astonishing creativity in avoiding traps and working around barriers.

My great weakness as a GM is that I tend to get too involved in the story I want to tell rather than hearing what the players are saying about the story they want to weave. I might give the players a choice of leads to follow, but the stories they fall into are sometimes even worse than railroaded – they are scripted. The genre I tend to work in doesn’t help this tendency: I usually run Cthulhu Mythos games, where horrible things happen and the characters are witnesses to the horribleness, and sometimes this scripting feels like the only way to ensure that a necessary event actually occurs in player sight.

Still working on that one.

The things I like best about GMing is that it really trains your “making it up as you go along” muscles, and that it is an outlet for my acting – I try to do distinct voices for each character (player or setting character).

Considering the scenario or campaign as a completed narrative, you end up with a splodgy hodgepodge of story elements. Some of them are great, some of them are terrible, and some of them can act as inspiration for linear narrative fiction. But I would counsel strongly against seeking to fictionalise the scenarios you run as they happened. It’s tempting, but the best things about the game session are its spontaneity and unpredictably, and if you are transcribing those sessions as a way to generate fiction then you aren’t going to get either of those. So don’t do that. I’ve known folks who tried and it did not end well.

One Response

Fiction Is Software Is Fiction

I tell stories to computers, as my friend Howard has put it.

This is what programming is: writing down the story of how a piece of information is turned from one thing into another, or how a set of data is to be interpreted, or how to paint a picture which shows the information to the user of the program. Sometimes I write programs that help other people write programs – indeed, there was one tool where I wasn’t just writing a program about programs, it was a program about programs about programs about programs*, which in my experience is about as abstract as it gets in software.

But still – the point here is not the occasional abstruseness of my day job, the point is that programming is story telling, and as such is close kin to writing fiction.

One of the most powerful tools in software is something called the use case. A use case describes something that the system does – a way in which the software can be used to perform some piece of work: open a file, for example; add a case of gin to the shopping cart; make the alien’s head explode. Where the power comes in is that you describe not just the the general feature, but the state of the system before the use case starts, and the ending conditions: the file must be present on the disc; the user must be on the distilled liquor page; the alien’s helmet must have been removed. You do not define how you get from one state to the other. This is all about what the user sees, and maybe what long term state changes. The implementation is not specified.

When I am laying out a novel, I effectively write use cases for my chapters. Each chapter gets a note on who is in it, what the starting conditions are, and where the chapter needs to end. Unless it is important to the plot, I leave the location loose, and I may add a couple of things that need to happen if they are not implied by the end state, but that’s all. Out of that looseness comes the discovery of the setting and the invention of minor characters that I enjoy so much.

Of course, the deeper truth about programming is that although you are telling the computer what to do, you are really writing the story for the next person who touches the code – so we are telling stories to each other using bad spelling and too much punctuation.

[*] for the record, it was a tool for writing descriptions of reusable diagram components which were then used to create diagrams which could then be used to generate application code.

One Response