10 January, 2015

Some more Voidstone thoughts

Let’s look at some Voidstone stats. Here’s the chances of success as they currently stand…

3 (low for a starting character)
23.08% Base Chance of Success
40.83% With Ability or Equipment
54.48% With Both

5 (typical starting character)
38.46% Base Chance of Success
62.13% With Ability or Equipment
76.70% With Both

7 (high for a starting character, typical for a veteran character)
53.85% Base Chance of Success
78.70% With Ability or Equipment
90.17% With Both

9 (high for a veteran character, typical for a legendary hero)
69.23% Base Chance of Success
90.53% With Ability or Equipment
97.09% With Both

11 (high, even for a legendary character)
84.62% Base Chance of Success
97.63% With Ability or Equipment
99.64% With Both

That seems like a good distribution to be playing with, but it really does nothing for tasks with variable difficulty. That’s something I’m not fond of, and it’s one of those things that bugs me about game engines like “Apocalypse-World”. I know, AW aficionados will tell me that AW takes this into account by framing the actions within specific narrative events…you need to be in the right situation to activate the game mechanism and the difficulty is taken into account through the complexity of getting into that “right situation”, a complex task might require several steps before it can be completed. But that’s not what I want from this game. Voidstone Chronicles draws on an 8-bit aesthetic, if you attempt something at a low level, there’s a slim chance of success even if you’ve got the resources to spend in the attempt. At high levels, the resources might be easier to come by, and the backlash from failure might be more easily absorbed.

I think we need some kind of simple test system, and an opposed test system. Simple tests give us a binary decision: yes (I pass), no (I fail). Opposed tests give us four options: Yes, but (I pass, but so do they), Yes, and (I pass, and they don’t), No, but (I fail, but they succeed), and No, and (I fail, and so do they).

Let’s look at this in the form of a treasure chests, one simply locked and one trapped (a standard console RPG trope)…
Locked
Yes (I open the chest)
No (I can’t open the chest)

Trapped
Yes, but (I open the chest, but set off the trap in my attempt)
Yes, and (I open the chest, and avoid setting off the trap)
No, but (I can’t open the chest, but set off the trap in my attempt)
No, and (I can’t open the chest, and yet I avoid setting off the trap)

It would be tempting to add a mechanism that determines whether a locked or trapped chest can be reattempted, but most console games don’t do this. One of the games I can think of that doe take this into account is the PC game “Dungeon Siege”, which turned the whole trap disarming element into its own mini-game. I could generate a bunch of mini games like this, but that also goes against the design philosophy of keeping it simple and open for new players.

Since we’re basing this on 8-bit console games, and the setting is a highly mysterious mystical world, we can probably use a healthy dose of handwavium to discard the whole issue (and a whole lot of similar issues). Maybe locks are simply magical seals attuned to a character’s DNA, a thief character’s ability to “pick locks” is now simply an ability to mask their DNA to allow access to other people’s sealed items. If an “attempted lock pick” is failed, the mystical lock mechanism now has the thief’s DNA on file as a “non-match” and thus prevents any future attempts….but that doesn’t stop other people having a go. Acknowledging problematic elements of a design can always be handed through modifying the mechanisms, or modifying the world to justify those mechanisms.


Post a Comment