Saturday, 21 February 2015

How do I write a playtest scenario?

So, I need to write a playtest scenario for Monitors.

What makes a good playtest scenario, anyway? I don’t think it’s the same things that make for a good scenario (at least, not exactly the same).

In a scenario, it’s assumed that the ruleset is already thoroughly tested and robust. Thus, things I might look for in a scenario are:

If it’s a beginner scenario, it introduces the setting of the RPG.

It establishes the genre and tone of this particular campaign, which should be close to the RPG default, because starting new players off with trope-breaking is not a sensible way to introduce them to a game.

It gives players a chance to try out the mechanics, in broadly ascending order of complexity. Early stages might not involve mechanics at all. While players’ actions are the key, challenges should be set up so that players are likely to use the core mechanics first, and don’t initially need to worry about the more complex rules. Once they are familiar with the core mechanics, it will be easier to understand and remember later mechanics.

For a playtest scenario, things are a bit different. Let’s assume here that we’re concerned primarily with mechanics: deciding whether a game is ‘fun’ in terms of setting, genre and mood is a rather different proposition.

There are some similarities, because playtesters are almost necessarily also beginners. Nobody has much idea of how the game works because nobody’s played it.

Because the focus of playtesting is mechanical, there is less need to worry about fluff elements. However, it’s still sensible to try and establish the genre and tone of the default game. These can heavily influence the kinds of actions players take, and their expectations. An adventure fantasy game may expect PCs to face overwhelming odds, leap chasms, seek lost cities on a rumour, show random heroism, and so on. A gritty fantasy game may expect PCs to avoid fights unless they have a clear advantage of numbers, look for ways around obstacles, shun fools’ errands, keep an eye on the main chance and so on. Knowing what the game is built to support is therefore important.

If you’re aiming for a useful playtest, then you want to try and test the majority of the mechanics. As science tells us, ideally you want to test each one multiple times to increase the usefulness of the test. After all, maybe that one time you tried the healing mechanics was the one in a hundred that it doesn’t break the game.

I think I might also draw a distinction between two playtesting approaches, which I might as well call Amicable and Mischievous. In the first case, you’re trying to see whether the mechanics work smoothly when played normally, fully in the spirit of the game, as a kind of sanity check. The second is a relatively important aspect of RPGs, which is essentially looking for exploits. In the first case, you want the players to try and play with the grain of the game, just using the mechanics to do stuff, while you check whether they basically do what you want or have unexpected results. In the second, you really want to step back and let the players run wild as they attempt to break the game.

Now, I think it’s sensible to distinguish here between mechanics-breaking and playing in bad faith. If there is a mechanic that lets you burn health to gain 10 Mana, and a spell that heals you for 1 Mana, this is probably going to go badly wrong and exponential wizard-gods will reign triumphant over your game universe. Using this exploit is not in bad faith; it’s cheap, sure, but it’s baked into the game. Why wouldn’t wizards use this? It doesn’t go against the genre or tropes, it doesn’t rely on metagaming or logic that falls apart under closer examination. This is a mechanical problem with the game, and needs addressing.

So, what do I need to test?

Mechanicswise, there are several core mechanics at work.

I have a core task resolution mechanic based on dicepools. This calls for challenges of various kinds, at various difficulty levels. Because success is capped by dicepool size, I need to consider carefully whether this will block progress unreasonably, or whether tasks that should be difficult become trivial because of modifiers that can be accessed. It’s important to try to test this mechanic across several spheres. Combat is usually the subsystem that gets most scrutiny, but I don’t want it to be the focus of this game, just one element. I also want to check social interactions, as well as more general tasks like research, physical challenges and stealth.

I included mechanics for collaboration, and need to test whether these work as intended.

The second major feature of Monitors is the body temperate mechanic. Obviously, this means I need a playtest scenario to feature a variety of temperature zones, as well as sources of heat and potentially heat-draining challenges. For Monitors, there are advantages to both cool and warm bodies.

The third big mechanic is the magic system. Now, this isn’t something I can really build a playtest to include, because magic is essentially about what weird abilities each PC takes, and using them creatively. I’ll basically just have to ask players to use magic during the scenario.

At a slightly more subtle level, I need to check whether the mechanical implementation of concepts actually feels right. Do physically-powerful characters feel meaningfully stronger? Do intellectual characters feel brainier? And so on.

Next, let's think about the NPCs. I've divided these into different categories, like mooks, hordes and standalone antagonists. It would be useful to test these out (hordes in particular) to make sure they interact with the PCs in roughly the way I anticipated.

If I had an experience system, this would also be something that needs checking - do things scale correctly? Thankfully, I don't.

No comments:

Post a Comment