Tuesday, November 17, 2009

The Function of Randomization in Simulation

"Why does a presumably trained and qualified surgeon have a 70% chance of success? That's a 30% chance of failure! Any surgeon with a 30% failure rate would be stripped of their license!"

Ever hear stuff like this? I do, all the time. The problem comes from the first assumption made, in which the dice are assumed to be rolled every time. If this first assumption is not true, then the random system is a much closer approximation to reality. If instead the assumption is that the 999 iterations that went without a hitch are not played out because they have no interest for the participants, then when in the 1 in 1000 occasion which is rolled for there is a 70% chance of success, then the actual odds of success are 99.97%.

Now why is that 70% there? Why not just give the surgeon a 99.97% rating? Why mess with randomness at all? At this point isn't it basically 100%?

That randomness represents a slew of external factors, all rolled up into one and abstracted. All things are not equal, and the random factor is there to tip the equation. That doctor with a 99.97% success rate going into surgery may be coming down with a cold, the scrub nurse perhaps is upset, having just broke up with his girlfriend, and the anesthesiologist is possibly worried about an IRS audit coming up. Maybe there's an equipment fault, or an electronic glitch. In practice we can't deal with so many small influences, so we abstract their effect to a single random roll.

If you are going to work solely with modifiers, then you have to itemize every influence. It isn't worth the bother, so we abstract it to a roll. The roll represents unquantifiable factors - unquantifiable either because they are so by nature or because they individually are below the resolution of the simulation. Quantifiable factors are always best expressed as modifiers. By taking out any random component, you are essentially stating that either all factors are quantifiable or that all unquantifiable factors are collectively below the resolution of the simulation.

So that's what the 70% roll represents - It doesn't mean the surgeon fails 30% of the time, it means that surgeon has a 30% chance of allowing these outside factors to interfere in what would normally be a successful operation, if such factors are present and significant. The vast majority of the time, they are insignificant, but for this operation, they are significant.

We normally don't play out the stuff with no chance of failure. For those things every qualified surgeon is at or close to 100%. It's the tricky ones that get played out. If there is no pressure from external factors, there should be no roll - and there isn't, unless you have one of those ass GMs who make PCs do a dex check every time they walk.

Here is what I am saying, in a nutshell: If the GM calls for a roll, it means unquantifiable external factors are potentially interfering with the usual, expected result. The factors are balled up and abstracted into the surgeon's roll. The roll is not "Is something going to go wrong" but "When the thing which is going to go wrong goes wrong, how well does the surgeon handle it?" If there are known factors which are easily quantified, the GM is free to apply situational modifiers as required.

Now whether anyone designs games as pure simulation is another point entirely. I certainly don't.



  1. Good post clash. I think it will make a nice clear example for explaining things to players, especially new ones who aren't used to the topography of risk in a session.

  2. Agrred Clash. I used this very principle with the Chevalier play test last weekend. Basically, some things I just gave to the players based on them having a skill in it. Other tasks that they did not have a skill in, I also gave tot hem if it was easy enough. However, the skill of a GM, IMO, is in knowing when to roll the dice and when to us them to create tension and suspense. I often wonder if people realize how much a tool of the story dice are and can be.

    Also, I very much use modifiers such as the operating theater and staff in your example. Essentially, if you are working under optimal conditions, optimal staffing and support, I might make you roll but state a "Just do not roll a 100%".

  3. Hi Vincent!

    It always surprises me how many people just don't grasp this concept. I know it shouldn't, but it always does. I blame global warming!


  4. Hi Bill!

    Why am I not surprised? :D


  5. I love the explanationn here. One thing games need to do is to present failed rolls more often as complication building, not event ending.

    You see if said brain surgeon let's those outside factors get to him, then something may go wrong in the surgery, but it doesn't mean he failed. It just means "something went wrong, now you must cope with the fallout..."

    Games would be better served in some respects to build such fallout, and let those be coped with as their own skill rolls.

    After all you see it in fiction all the time. "Oh my we've got bleeding on the brain, give me X, Y and Z, and do Q..."

    The surgeon compensates for the fallout, and a factor that caused the fallout, and then likely continues on the surgery, too many things go wrong and of course its a horrible event.

    Of course games try and keep the rolling to a minimum. One of the interesting mechanics I saw that didn't catch on, I the Immortal (1E) rpg.
    I found its dice mechanic nifty. You (iirc) rolled for all factors involved in a given situation. So fighting with a sword on ice slicked rooftop in a cold rain, at night. You'd test for fighting, ice, night elements. You could succeed but still suffer a minor setback caused by failing 9on individual parts of the situation. The dice roll told you at what part of the event you failed at--and did so swiftly.

    It wasn't the best mechanic, it was a bit clumsy in its implementation, but at its heart it had a good idea.

  6. As a GM, I use this, so that a failure in some circumstances means a complication. Other circumstances, a failure means an end case. it depends greatly on the activity being performed. I have never codified this into any of my games because I see it as a playstyle preference, not a rule. Generally I ask games not to try to tell me how to GM, and I extend the same courtesy when I design them. If I ever extend it into a mechanic, then that might be a different story. :D