Yeah. I know I missed June completely, and almost missed July. I’m a bad person, but look, an unpainted spaceship.
Right. Now that you have been suitably distracted from my complete inability to report on actions in real time, I’d like to talk about beta testing, simulation, and the iterative nature of design, Mmmmmm, Sexy!
First was the word, and the word was Urrrrggghhh! My disdain for several TTRPG staples was enough to get me to try and solve those ‘problems’. I put the single quotes because I’m sure for many people, always having a 5% chance of missing is great, and taking half an hour or more to get through a single round of combat is fine because it let’s you do other things when it isn’t your turn, such as plan your pension. I fixed these things for myself, and then, because I could gather a few captive audiences together (waaaaay back when you could just go hang out with anyone you felt like), I did the initial beta tests of the system with those unlucky individuals. The result: great success!
This is the first point that I do two things. I strip away any parts that did not work, and fill in the gaps if that is needed at all: at this point it wasn’t. Then, I simulate, a lot. Sure, this requires some maths, some code, or a fair bit of head work, but it really helps limit what you need other people for. With simulation you don’t have to give crap to your beta testers that has no chance of working. You can literally save hundreds of hours of testing by elimination design cul-de-sacs. If you have a huge pool of testers you can use them, but I don’t, and I’d feel bad about asking them to waste time testing options that could be eliminated beforehand.
The simulations are done. Now you need Beta testers. No amount of mathematical certainty can tell you how something feels, or if people generally find something easy to understand as written.
so THANK YOU beta testers. In particular, a thank you to those of you that were given small A/B tests as those guys have solved so many little dilemmas for me. Most of these were completed ages ago, but one that came in very late reminded me of their importance.
In this case, it was a question of whether it mattered if the player could roll maximum dice based on the current skill with the highest level that they were using that moment, or, maximum dice based on their highest skill level regardless of which skills were being used.
Initially this may sound like a distinction without a difference. Looking deeper you can analyse it and realise that the later allows for riskier action sets within a moment than the former. The later also incentivizes some specialization in the long term, while the former incentivizes the player use their highest level skill as often as possible to maximize what else they can do. More importantly. Another difference is in player understanding because the former method means that the maximum number of dice that can be rolled is context (skill) sensitive, while the later method means that the maximum number of dice that can be rolled is a constant, although the players may not wish to roll that many dice as they would be performing extra actions and introducing extra risk.
Whether you understand that or not, the important thing is that I could not simulate how these two different variations of the mechanic would make players feel, and that is what Beta testers can do for you. They give you the human factor, which is important, because you are designing for humans.
Enough brain farting for one blog. Time for you lot to go off and do all the social media things, whatever they may be: liking, disliking, creating angry comments, or drawing pictures of giraffes with laser monacles. I don’t pretend to know how social media works. Bye for now.