RPGs as games vs. RPGs as programming tools

May 9, 2012

I poke my head in at Enworld every so often to read up on D&D5E. So far it seems mostly like they’re keeping their cards close about what’s going on (or, you know, most of it is unformed and therefore nothing solid can be said and they don’t want to have the fanbase assume every possibility is a promise…)

Anyway, it highlighted a specific difference in expectations for RPGs. Traditionally, most RPGs are more like a programming language- it’s a set of tools the group uses to make situations and play, therefore, it has to be very broad, flexible and robust to accommodate the possibilities. (Specifically, it was people EXPECTING rules in D&D5 for “advancing monsters”…)

Vincent Baker’s post on System is very useful here:

Vincent Baker's chart on System

As he points out later in that post, the expectation for traditional rpgs is that the rules provide a lot of support for principled decisions – whether that comes in the form of simple rules and lots of GM decisions on the spot, or lots of rules for lots of situations to cover everything.

I’m comparing this against games that have a single situation that you play out, as the focus of the game – Grey Ranks, The Mountain Witch, Shab al-Hiri Roach etc. and how often games like these also get labeled, “Not a roleplaying game”. It’s that part of the expectation that some folks have is that all roleplaying games are supposed to support near infinite situation generation and continuous play, rather than be something with a beginning and endpoint.

It should also be pretty obvious that building tools to build games (and the advice to make GOOD situations to play with out of that) is much more difficult than to build a simple game that does a single scenario or a few scenarios.

Mostly, though, this is just an observation about both design expectations and communication about the games we play.

%d bloggers like this: