I’ve been reading Brad Murray’s blog since he restarted it back in October, and frankly, if you’re into game design you should be reading it as well. He’s been talking about the design of his latest game, Sand Dogs, as well as of the series to which it belongs, called Soft Horizon. Brad’s design goals align greatly with my own, so it’s been quite informative to read through his development, and to see the ideas that shaped the games. Even though my mind isn’t quite in the game design space at the moment, reading through Brad’s posts makes it impossible to not consider and file things away for whenever that time comes.

Reading through Brad’s posts made me realize two important things about my own design, and why I was having problems with it (which is one of the reasons why I put it aside to focus on other projects). The first is that players aren’t improv actors*, and the second is that roleplaying games aren’t a story.

One of the biggest issues I had been facing with my own game design was figuring out how complex I wanted to make it. Ideally, I want a simple system that I can drop in the hands on a non-gamer and they can play fairly easily. I thought that the way to do this was to have a very basic framework with a dice-based conflict-resolution system, and a free-form consequences system, then letting their imagination determine how these best fit their own narrative. To define the system beyond this, I thought, would be to introduce unnecessary complexity; it’d be a legacy of roleplaying games in general, where bloated, complex system reign supreme, simply because that’s the way things have always been done.

I don’t think I’m wrong in my design goal, or in my reasoning for wanting to keep things simple, but the framework I was going for, I’ve realized, is a game design that takes the responsibility away from me, the designer, and places it, unfairly, on the player. This is lazy game design. I couldn’t figure out how to solve the problem, so I shifted the problem onto someone else and called it a design choice. I’m not saying that there is no room for letting the players’ creativity come into play in interpreting the mechanical aspects of the design, but it has to be done purposefully. I very much like how Brad’s Soft Horizon system uses methods and risks as cues to determine how the players act and what the consequences of a conflict could be. Fate Accelerated does something similar with the Approaches, which tell the player how a task is accomplished (Quick, Clever, Flashy) but leaves what exactly is the action done for interpretation.

Whenever I sit down to work on this, I need to have this front and center on my mind: my players are not improve actors, and my job as designer is to give them enough guidance through the system so they have choices for both actions and resolutions, thus giving them scaffolds onto which to hang their creativity.

The other issue that’s been stirred up is that, in trying to avoid bloating my system with complexity so as to not create a game that tries to be a simulation of the world, I failed to realize that games are not movies and work under very different rules of storytelling in order to achieve a final cohesive narration.

Brad writes,

There is a lot of work on the table that tries to understand role-playing games in terms that we already know from trying to understand story. We’ve been trying to understand story (and story has been changing over this time, but also not, if you get my meaning here) for a really long time and so it seems natural to apply this knowledge to role-playing games. They do look like stories, after all. Well, at least after we finish playing and think about what happened, we hear a story in our heads. When we type up an actual play report, we present a story.

When I listen to the audio of an evening’s play, however, I mostly hear a social event in which a game is being played and some great scenes are being described. In a way it’s rather more like geeks talking about a film they loved and re-hashing their favourite parts than it is like an actual story.

So when people use theory to try and make role-playing games better at delivering story, I have to wonder if that’s really on the right track. Maybe role-playing games shouldn’t be stories.

I love the idea of focusing on narration during gameplay in order to determine actions, conflicts, and consequences, rather than resolving task after task after task, but this doesn’t mean that the gameplay is a story. My goal is for the game to create a story as an end product, but I need to remember that the gears that power the creation of that end product are not a story in and of themselves, even if they may look like one. Making a rule that narration determines how a conflict is to be resolved (“please don’t search your character sheet and tell me “I use Socialize” — tell me what you do and we’ll work out the method together“) doesn’t make that narration a story per se, it’s a gear in the machine that will eventually produce a story as a final product, and as such, my attention as game designer should be in how to best use that gear in order to create the best possible end product, rather than trying to make the gear be the same as the end product.

Basically, a mechanic is a method through which to achieve an end result. In game design the end result is a story, and even if the mechanic takes the form of an element of the end result (narration in my case), it is still a mechanic and must be treated as such.

I know I’m bungling the explanation, but the core idea is there; I’ll continue to refine it and better express it once I do.

So as I said, not really thinking about game design at the moment, but I have certainly added a couple more pots to simmer on the backburner of my mind.


* I am pretty sure that I read this statement, or something that led me to this statement, in something Brad wrote, but I can’t seem to locate the source. If it turns out it was someone else, I’ll fix the attribution.

Advertisements