Virtual Playtesting

For some time now I’ve been toying with a little language for randomizers, which might even be a subset of a little language to describe game rules —with role-playing games have the focus. For the most part, the application has always been testing ideas or for a convenience die-roller. I’ve always been frustrated with every die-rolling program I’ve ever used, because there’s invariably a dice mechanic that hasn’t been thought of, and the program isn’t flexible enough to model it.

And, obviously, the kernel of a randomizer representation language exists. 3d6 is the sum¹ of three six sided dice. It’s only when games start to need “the highest of” or “reroll 6s and add” that things get complicated. Which is almost every game. And of course Dogs in the Vineyard² needs dice to be commited in pairs, and whatnot. Although for a die simulator, this is hardly a new problem.3

But a real application just raised it’s head: playtesting. If you playtest with virtual dice, on a MUSH, or IRC, or even in person with a coupla laptops, then not only is it really easy to change rules and whatnot, you get an automatic record of play, plus empirical exercise of your system. So you can see up front what different card distributions do, or run quick simulations of conflict resolution systems that use dice.

Plus, if you’re like me, it makes as much sense to write the intial rules text in a programming language, and you get very abrupt feedback when it’s broken.

The pitfall is that the system warps your thinking about the rules. The same way that System Matters in play, the framework would influence design decisions. “Why not use d12s for this? They’re a pain to code for.”

Certainly worth thinking about.

¹ usually.

² Dogs, why is always Dogs?

³ Consider the method that several games use to generate stats: roll all the dice up front, and then assign the values to stats. Same thing.