Post by Peter Watson-Wailes

I spent much of the last year or so mulling on an idea for the setting for an RPG. Towards the end, while taking a break before editing my book, I decided to sit down and created a system around it. Here's my collected thoughts on what I've learned from that process so far. This will be an evolving document as the process continues.

Notes and Progress

The Story is Everything

The rulebook might be what people get, but stories are what people come and stay for. That's the aim. If your system isn't enabling great storytelling, then it's not doing its job. That's where I started with Beasts of Xasine. The stories.

When we were play-testing, we came across issues with the rules as they were at the time. However, as the story and characters were interesting enough to keep the players hooked, it kept the game going even in the face of those issues.

To create that story though meant fleshing out the world far more than I'd had to for book planning. To do that, I started by writing a short story in the world, and then the framework for how the things that appear there would work. Once I had that, I spent a few days working through possible options for the bestiary. More information on that later.

Having worked out how the stories being told should work, and how the GM will guide the gameplay, the next step was to create the system to enable that. Which brings me to

Building the Base Mechanics

To my mind, whenever you're doing something like this, there's two options you can use which I refer to as dynamic and static. Static is a system like D&D or Dark Heresy, where there's great lists of things with all the numbers worked out. It makes it easy to work out exactly what anything does, as it's codified, but it can become constricting if you can only do what's in the codex. Dynamic systems are those like Numenera, where there's little that's written down, and much is left to the interpretation of the GM and the imagination of the players.

Neither version is right; both offer advantages and challenges, but both have their benefits too. For Xasine, I chose a more dynamic approach, to free up greater creativity at the cost of a slightly more challenging experience for the GM. However, after the first play-test we realised this dynamism meant that it also required guidance, which became the Tales of the University of Catsborough guide book to the manipulation mechanic.

The Imperial System

Initially the system was built around a d10. That worked well enough, but given as about half the roles were a d6, and I'd worked out the distances in multiples of 12, it seemed right for the sake of consistency to make the core rolls a d12 instead. This required a minor rework of the numbers, but has resulted in something that fits together far better, and with the 12 based system, gave rise to the name for it: the Imperial system.

Creating the Bestiary

For each critter, I started off with an interesting mechanic, then built out a creature around that. For example, for the disapperatures, the mechanic was "something that can move through space in two realms, ours and another". That became the Realmshift mechanic, and how it would work created the idea of their home realm as a beautific land, which while moving through moves them also through the player's world. The idea of the other realm as a beautific, peaceful land then inspired their character, being childlike and innocent.

Another example would be the squank, which started out as an idea for the Library of Memory, the place where their race stores their memories in some physical form. That inspired the idea that they have no personal memory, but instead weep tears that store memory, which was partly inspired by the legends of the squonk from Pennsylvania, the squonk being a creature that weeps due to being inconsolably sad over its own appearance, combined with the "Tears in Rain" speech from Blade Runner.

Sweat the Details

Before any play-testing, you need to start editing. With the first draft of the core rulebook done, I gave copies to a few trusted friends and acquaintances to get feedback. Immediately they were able to spot issues I'd overlooked. In turn, that meant that a lot of the bugs could be ironed out before the first game was played.

With the major bugs out of the way before play-testing, we then got on with the business of actually running a full adventure. That found us the rest of the issues with regards to numbers, what dice were being rolled when, the stats available, wording and so on.

Note Issues, Fix Later

While we played, when we came across bugs, I made a note of them. We could then note how to fix them on the fly and test different options as to how they should be resolved.

Once we'd gotten a handle on how a mechanic should work, I could then go back later and re-jig the core rulebook to fix the issue.

If you've enjoyed this post, you might want to follow me on Twitter