Tales & Trails of a Traveling Wiseguy

Posted by J.T. Evans

https://gnomestew.com/collaborative-storytelling-loop/

https://gnomestew.com/?p=53011

Most RPGs tell a story of some kind. Some are deeper than others, but there is a story hiding under the cover of the mechanics somewhere. Since most RPGs are played in a group, this makes the storytelling collaborative. At least, it should be collaborative. If it’s not, then the person telling the story to the group may as well be sitting at a campfire and telling the others a ghost story. While that’s perfectly fine for entertainment purposes, that’s not the point of playing a role playing game.

To help everyone make their tales more collaborative, I’ve come up with the concept of a storytelling loop that I’ll explain below. While this loop might sound like hard and fast instructions, please don’t treat them as such. If the loop needs to be adjusted based on circumstances, do so. This is not an instruction manual for assembling a set of shelves or a desk. This is guidance via a framework to help you think more clearly about how things could flow.

Group Effort

Obviously, to collaborate you need a group. This means everyone in the group should be involved in the telling of the tales. Some people will shine at times while others fade to supporting roles. This is perfectly natural, but the GM (and other players) should be aware of when an individual shines too much or too brightly and refocus the attention on another person. This is called “spotlight management” and there are several other articles here on Gnome Stew that delve more deeply into this topic. Just search for that phrase, and you’ll find a wealth of information.

No One Side of the Screen is Responsible

As is implied by the above “group effort” section, the GM is not solely responsible for the storytelling loop. It’s a back-and-forth with handoffs and flowing between GM-provided narrative and information and the PCs responding to that new information.

Flow State

Even though what I’m going to present below implies a smooth handoff between GM and PCs, this is not always the case. The GM may have a PC do something that interrupts the loop or the PCs may latch onto something the GM has presented that breaks the flow. That’s perfectly fine. From my experience, however, what I’m outlining below is the typical flow for the storytelling elements that come into play.

Yes, And

To keep the flow going, don’t just agree with another player’s idea. Tack onto it. Add to it. Build upon what they’ve offered up and keep the story going.

No, But

If someone puts something out there and you (either as GM or player) don’t fully think it’ll fit into the current story that’s being told, don’t just hard stop the idea. Take the concept and redirect it with a “but” clause that gets it back into the flow state of the story.

The Storytelling Loop Framework

1. GM Introduces Scenario
2. Optional: PCs React to Scenario
3. GM Triggers Events
4. PCs React to Events
5. PCs Make Choices
6. PCs Take Actions
7. GM Reacts to PCs’ Actions
8. GM Triggers New Story Events
9. Repeat Steps 4 through 8

1) GM Introduces the Scenario

The start of any decent story introduces a time, place, maybe some NPCs, and a scenario that is unfolding (or has just occurred). This is the initial setup of the adventure where the PCs band together (if they’re not already together) to face a threat, goal, situation, enemy, or to set out toward a destination.

2) Optional: PCs React to Scenario

Once the scenario is established, the PCs might want to do some prep work. This could be divination, research, travel, acquiring provisions and equipment, talking to NPCs, formulating a plan, or coming up with ideas on what might come next. This doesn’t always happen because the “GM Triggers Events” can sometimes happen immediately after the scenario is established. This is common in a “in media res” style of storytelling where the action hits close on the heels of the story’s introduction.

3) GM Triggers Events

The GM then sets up and triggers some events that impact the PCs. These events could be an attack, the start of a heist, a critical discovery, acquisition of a map, gaining new information, or witnessing something happening that the PCs want to aid or prevent. The key here is not what kind of event is triggered, but to ensure at least a few of the PCs have a motivation to interact with the event being presented. If a man is resisting arrest in front of the PCs, there might not be any motivation attached to stop the man or the authorities. However, if the man is a close friend of several of the PCs, they might want to at least interrogate the reason for the arrest, if not stop it. On the flip side, if the man is a dire enemy and appears to be close to escaping his arrest, the PCs will want to step in and ensure he doesn’t get away.

4) PCs React to Events

The event presented by the GM should cause some flavor of reaction in the PCs. It is preferable that this be an emotional reaction combined with a physical one. A mere physical response out of necessity is not as visceral or deep as actions taken because of an emotional attachment.

5) PCs Make Choices

The PCs must decide (sometimes quickly; sometimes methodically) on what their next actions will be in response to the presented event. The timeframe of how quickly the PCs must react will depend on the type of story being told and the urgency of the event put in front of them.

6) PCs Take Actions

Once the PCs have reacted and made some choices, they have to put their plans into action. This could be as straightforward as drawing steel against the orc raiders to save the kidnapped prince. If the prince was just discovered kidnapped and the trail has grown cold, then the PCs’ actions might involve an investigation of the crime scene or tracking the kidnappers or talking with witnesses to gather more information in order to find where the kidnappers took them missing prince.

The number of actions available to the PCs are countless, but should be guided and focused by the event in front of them. I call this a “creative compass.” What I mean by this, is that the GM should provide some hints or choice options to limit the amount of “analysis paralysis” the PCs will go through. If the PCs merely know “the prince is missing” then they don’t really have enough information to formulate an intelligent response. If the event is “the prince is missing and several people saw a squad of orcs carrying a bound child through the darkness at the edge of town to the north,” then the PCs can do a minor amount of investigation before delving into the wilderness to the north.

7) GM Reacts to the PCs’ Actions

Depending on what the PCs actions are, there are numerous effects they’ll have on the story. I’ve grouped these changes into the following buckets:

• Story arc change of direction
• Setting changes
• NPC changes/additions/losses
• Enemy changes/additions/losses
• Ally changes/additions/losses
• Consequences and Adverse Effects for the PCs
• Potential Rewards for the PCs
  • Treasure
  • Experience
  • Allies
  • Favors
  • Social Status

These changes to the story, I hope, are self explanatory. If someone out there wants me to delve deeper into these, I can do so in another article along these lines. Just drop a comment below and let me know.

8) GM Triggers New Story Events

As with step 3 above, the GM will introduce a new event based on what has changed in the story. These changes will be based on the outcome of the PCs’ actions. Instead of moving forward with a pre-written response to the action outcomes, the GM should adjust things as necessary to make sure the new story event aligns with what just happened. Sometimes, your pre-written event will work perfectly. Most of the time, GMs will have to make minor adjustments. There are rare cases, however, where the pre-written prep the GM has done will need to be massively reworked or thrown out.

9) Repeat the Process

Clearly, if the story has not come to a satisfactory conclusion (returning the kidnapped prince from the clutches of the orc raiders and back to the royal castle), the story must continue. Repeating steps four through eight will keep the flow going on the story. Once the story arc, character arc, or campaign arc have come to a conclusion, the GM should wrap things up with the PCs and not introduce a new event. If the GM does introduce a new event, this is an indication of a fresh story/campaign arc that is about to be told.

Addendum: Automated Triggers on a Timer

There are some external factors that can modify GM events or PC actions. Many of these run on a timer, but some may be pseudo-random. Examples of automated triggers are:

• Weather Changes
• NPC actions
• Enemy plans and actions
• Movement of celestial bodies
• Random encounters
• Random treasure

Conclusion

I hope this description of a collaborative storytelling loop helps you identify where you’re getting things right and maybe areas for improvement. If nothing else, I hope this article gave you something to mentally chew on and apply in your role playing games.

https://gnomestew.com/collaborative-storytelling-loop/

https://gnomestew.com/?p=53011

Posted by Matthew J. Neagley

https://gnomestew.com/a-case-study-in-dice-stat-tests-part-1-general-approach/

https://gnomestew.com/?p=52899

Recently the Kickstarter for “Honest Dice | Precision Machined Metal Dice You Can Trust” ended, having successfully funded for over half a million dollars. The Kickstarter was sent to me in the final few hours, so while I initially had some strong opinions about the content and the dice, there wasn’t time to do the proper review, analysis, and commentary that was warranted.

Having had some time since to digest and do a fair amount of math, I approach this as a case study, similar to the ones my business and stat teachers were fond of handing out: What analysis was done? Was it the right analysis? Was it done correctly? The point of a case study is a roleplaying exercise. You are taking the role of a pretend consultant and are handed a situation in progress. What do you do?

There’s a lot to unpack here so this article is part 1 of a 3 part series.

I wanted to write this article for two reasons:

• First, reviewing what was done and suggesting areas for improvement provides a resource for those doing this type of analysis in the future. The internet is full of resources explaining how to do a chi-square Goodness of Fit test. Less common are resources explaining how to do a test of homogeneity. Rarer still are resources that explain why you would do one test or the other, and how to prevent and express the results.
• Second, this is a half million dollar Kickstarter for game accessories, which puts it in a small subset of Kickstarters. Kickstarter’s own stats break their funding categories into 100k to less than a million and million plus. At the time of this writing, there have only ever been 4,268 100k plus gaming Kickstarters, putting Honest Dice in a small and impactful group. It only makes sense to review its claims and analysis carefully.

Before I start the actual statistics case study, there are a few points I’d like to make that fall outside the statistics:

Disclaimer: I have not bought, received, or even ever seen in person or touched any of these dice. I have not collected my own rolls, and cannot truly vouch for them. However, I’m inclined to take the evidence that has been presented at face value. You’ll see later during the review of the statistics why I think their collected data is likely to be legitimate and because of this, I feel pretty comfortable saying that these seem to be high quality, attractive, highly durable dice. They’re also expensive, even more expensive than you might expect for what they are. As such, if you like the look of them, if you like their unique features, and if you’re comfortable dropping the kind of cash the creator is asking for them, I have no reasons to tell you to not buy them. While the Kickstarter is already over, late pledges are still open. Also, the creator has a web store where you can buy many of their existing dice.

There were several non-stat issues I had with claims that were made in the Kickstarter. Most were inconsequential enough to leave out here, but one in particular struck me as disingenuous enough that while I am writing this article I felt I had to address it. At the start of their statistical analysis they make this statement: “I decided not to name the brands of the other dice. While I’m in favor of complete transparency, I’m also not trying to throw shade at other dice companies.” That’s admirable. The part I feel is disingenuous is that they immediately directly quote marketing slogans from the competitor in question, which is effectively exactly the same thing as naming the company outright. One cannot have this both ways. A company can name their competitor during comparison or not, but attempting to frame not naming them as taking a moral position makes an immediate violation of that stance into a moral position as well.

Finally, I’d like to briefly touch on the mathematical balancing of the numbers on the die faces that is a major feature of these dice. I think this is a very interesting topic and a similarly interesting topological problem. The section of the Kickstarter where they discuss how they determined their optimal arrangement is fascinating. In addition, I feel that this is something that could potentially enhance the fairness of some dice and that the particular arrangement of faces they came up with and the process of solving for optimal arrangements is something they should patent immediately if that is indeed a thing that can be patented. However, I do feel I have to point out that if the manufacturing standards to which the dice are held successfully create a die with probabilities very close to the ideal distribution, then rolling the die will result in a random distribution of faces very close to the ideal distribution as well. If the distribution of rolled faces are very close to the ideal distribution, then which number is engraved on which face doesn’t matter. So this ideal arrangement of numbers doesn’t do much to help the accuracy of an already highly accurate die. On the other hand, this arrangement of faces might ironically be highly useful to a company making lower quality lower accuracy dice.

So to start our case study, let’s look at what one ideally would do for a project like this:

• Consider Purpose: The first thing you would do is decide what you want to accomplish with your testing. Do you want to test your own dice for table fairness? Do you want to make an aggressive test of your dice to really assess their accuracy? Do you want to be really certain about your results or are you okay with some wiggle room? Do you want to test your dice against a competitor’s dice? How much time and effort do you want to put into this? All these things are going to impact decisions you make later.
• Design/Choose Tests: Once you have a good idea of what you want to do, it’s time to start designing your analysis. You’ll need to decide on how you’re collecting data, how much data you’re collecting and what tests you’re going to perform. Typically at this point you’re also choosing your threshold for statistical significance. It’s probably easiest to choose these elements in this order:
  • Tests/Questions: Every test is based on a pair of Hypotheses. One of these, called H0 or null hypothesis is a default assumption and always includes an equal sign. The math of the test assumes this hypothesis is true and the results of the test are the likelihood that one would observe a sample as unusual as the data that was collected, if that hypothesis were true. If we see a really rare event, then we have evidence our assumption was wrong and we reject H0. The typical tests for dice are:
    • Chi-Square Goodness of Fit Test: This is a test of the hypothesis that the distribution of the die you are testing is equal to the ideal distribution for a die of that type. So, for example, for a D20, H0 is “The probability of rolling each face of the die is 1/20” and observing a rare event rejects that hypothesis.
    • Chi-Square Test of Homogeneity: This is a test that the distribution of two or more dice (or other phenomenon) are the same. So for a relevant example, you would use this test to check if the distribution of a precision machined metal D4 is the same as the distribution of a low impact plastic cast tumble painted D4. Your H0 would be “The probability distribution for all of the dice in this test are the same.” and observing a rare event rejects that hypothesis.
      Why don’t we just test each die with the Goodness of Fit test and see which one tests better? Well, imagine a situation where your high quality expensive precision D4 has a random string of unusual rolls. Maybe you roll a bunch more 4s than you would expect. At the same time your low quality cheap inaccurate D4 has a string of really good rolls. If you look at those samples together it might look like your low quality die was better than your high quality die. But really, all you did was observe two rare samples back to back. That happens from time to time, but two separate goodness of fit tests have no way of determining if that might be the case. The test of homogeneity on the other hand takes into account the variance of the dice to help prevent these incorrect assessments. Remember that when you perform a test of your dice you’re only selecting one possible set of rolls of that size and set of results all range from very likely to very unlikely. The only way you know which set you have observed is to observe multiple samples or observe large enough samples. A single small to medium sized sample is an indication of what your true value may look like but isn’t always consistent.
      Note that the test of homogeneity only tests “H0: All of these dice are distributed exactly the same.” and rejecting that hypothesis only concludes that there is evidence that at least one of them is different than the others. Unless you are only testing two dice against one another, the test makes no claim about which ones are different from each other and the magnitude of those differences. Those follow up questions will require additional tests of their own and you should have those tests planned and accounted for before you run the first test. If the original test that tests all dice against each other finds no significance, there’s no need to actually run any of the planned follow up tests since there’s no evidence of individual differences to find if the first test isn’t significant. We’ll see an example of this later.
    • Chi-Square Test of Independence: Sometimes you’ll find explanation of this test alongside the Test of Homogeneity. If you’re saying to yourself “Huh. The statement ‘These dice all have homogenous distributions’ and the statement ‘the distribution of these die rolls is independent of which die they came from’ sure sound exactly the same.” congrats. That’s an astute observation. These tests are really poorly named. In general you almost never use the test of independence for die testing, but here are a few facts that will help make up your mind:
      • Mathematically, the tests of Homogeneity and Independence are identical, so if you’ve accidentally done the wrong test, no big deal. You’ve also done the right one.
      • The Test of Homogeneity tests if two different samples have the same distribution. Since they’re two different samples, they don’t have to have the same sample size. You can roll your first die 500 times and your second die 5000 times. It’ll make any attempt to do power calculations (the math to see how often you detect differences if they exist) weird but you can do it. Which means you can in theory trawl the internet picking up random D20 data sets from various manufacturers and mush them into one giant test of homogeneity.
      • The Test of Independence on the other hand tests multiple factors collected from a single sample. For example you might want to test if suit and number in a deck of cards are independent or if the temperature at which dice are rolled impact distribution, or some other combination of factors. Unlike Homogeneity, with this test every time you do a test it generates a set of data with a measurement of each factor of interest. Thus it would be really hard to have different sample sizes for different factors.
    • Other Tests: Those are the most common tests that are performed in dice evaluation but others might be used if you’re trying to answer questions other than “How well does my die match the ideal distribution?” or “Is one of these dice better than another?” In fact, you can make up your own tests as long as you can define a hypothesis and then are able to figure out the math for: Assuming the hypothesis is true, what is the probability we observe a sample as or more rare than the sample we actually observed?
  • Threshold for Significance: A test is said to be “Significant” if we assume that H0 is true and, if that is the case our collected data is too rare. What is “too rare”? Well, that’s up to you. You can set this threshold wherever you want, but there are some factors to consider:
    • Pick Before You Test: You should run no risk of your collected data influencing where you place your threshold for significance. If your test results show an observed rarity of 2%, do you want to wait till that moment to decide if 5% or 1% is your threshold for too rare?
    • Use One Threshold: Once you’ve chosen a threshold, that should be the threshold for your entire set of tests unless there’s a good reason to change from test to test (we’ll discuss that shortly). Without excellent justification, changing thresholds, especially if your data is borderline and you change in such a way to find results that are favorable to you, smacks of dishonesty and an attempt to manipulate results in your favor.
    • Use Common Standards: The standard thresholds are .1 (10%), .05 (5%), or .01 (1%). It’s possible to use other thresholds, nothing’s stopping you. However, larger thresholds come with larger chances of making an error (we’ll discuss that in a moment) and start detecting common results as “too rare”. Remember that rolling a 1 on a d10 for example has a 10% chance of occurring. Does it really make sense to say that an event more common than a standard d10 roll is so rare that observing them must mean your assumptions are wrong? On the other end of the spectrum, there are applications where thresholds smaller than .01 are appropriate. These are commonly seen in applications where lives or large sums of money may be on the line such as medical research or insurance calculations. In general, die testing doesn’t warrant this level of accuracy unless you have extraordinary amounts of money riding on them. I haven’t even heard of casinos testing their dice to levels of accuracy tighter than .01 but it wouldn’t surprise me if they did.
    • Consider Family-Wise Error Rate: Let’s say you decide your threshold for significance in a test of goodness of fit is .05 which is the same as 1 in 20. That means that if you assume your die has the ideal distribution and your set of rolls are as or rarer than 1 in 20, you’ll say the results are significant and reject that the die is fair. Now let’s say you have 100 identical ideally distributed dice and you test each of them, rejecting each die for which you see a sample with 1 in 20 rarity. How many of those 100 tests are you going to reject, on average? You’d expect to see an event of 1 in 20 rarity about 1 20th of the time, so in our theoretical 100 tests of fair dice, you would expect to reject 5 of them specifically because they follow the expected distribution. These are called Type 1 errors. When you choose your threshold of significance, another way of thinking about it is that your threshold is the proportion of time you’re willing to make these Type 1 errors. But if you’re performing more than one test at a given threshold then as in our example above, your chance of making at least one Type 1 error increases over your desired threshold as the number of tests increases. This increased chance of error is called your Family-Wise Error Rate and you can control for it in a number of ways. One such way is mathematically calculating a new threshold for individual tests that result in your overall Family-Wise Error Rate being equal to your original desired threshold. Another is using step by step procedures to reject individual tests and fail to reject others based on p-values and other factors. Discussion of individual methods is beyond our scope here other than to say: be careful when deciding if you can assume individual tests are independent or not. Explanation of a handful of procedures can be found here.
      To determine if you need to worry about Family-Wise Error Rate, ask yourself if any of your tests are related groups of tests and if increasing the number of tests will increase the chance of accidental error.
  • Sample Size: Now that you know what kind of tests you’ll be performing and at what level of significance, you can finally determine the size of the sample you’ll need to generate in order to properly run your tests. Remember that the more data you have, the smaller a difference you can detect with greater accuracy. Unfortunately, most of the tests you’ll use in die testing are chi-square tests and determining necessary sample sizes for chi-square tests can’t reasonably be done without software. If you’re confident in your R or Python abilities, several packages exist for those. However, a stand-alone product exists for those who don’t want to bother installing a programming language and code editor and figuring out how to code a solution themselves. G*Power has good reviews online, is a simple stand-alone product and will handle what we need. If you choose to use G*Power, once you download it and start it up, you’ll need to choose Test Family=X2, Statistical Test=Goodness of Fit Tests: Contingency Tables, and Type of Power Analysis=A Priori: Compute Required Sample Size – Given alpha, power, and effect size. Then simply enter the requested information and click calculate.
    • Effect Size: For Chi-Square tests standard effect sizes are .1=small, .3=medium, and .5=large. A smaller effect size means that you’ll be able to detect smaller differences between the distributions you’re comparing to one another.
    • Alpha Err Prob: This is your threshold for significance discussed above. Remember that if you’re dealing with Family-Wise-Error, even if you’re planning on using step procedures to deal with determining significance, you’ll still need an actual alpha here. Depending on if your tests can be said to be independent or not, the easiest option are the Bonferroni or Sidak procedure.
    • Power (1-Beta err prob): Power is the probability that you’ll be able to detect the difference of interest if it actually exists. Sampling involves a lot of random noise so even if the difference you’re looking for exists some samples you generate will make it look like it doesn’t. The higher your Power, the more samples will detect differences correctly, but also the bigger those samples will have to be. Standards include .8 (detects differences 80% of the time if they exist) and .95 (detects them 95% of the time if they exist.)
    • Df: This is the degrees of freedom of your test. For Goodness of fit tests it’s the number of faces your die has -1. For tests of homogeneity it’s (number of faces-1)(number of dice you’re comparing-1). So for example a goodness of fit test on a d20 has 19 degrees of freedom, while comparing a set of 4 different d20s together has 19*3=57 degrees of freedom.
• Collect Data: Now that you know how much data you need and what you’re going to do with it, it’s finally time to start collecting data. This order is important because you neither want too little nor too much data. Too little and you have insufficient power to detect deviations. Too much data and you’re going to detect really tiny differences. That sounds great until all your dice test as not fair because you collected 15,000 rolls each. When you collect data, in general it’s easiest to simply keep a running tally of the count of each face rolled. Some people like to keep an actual record of every roll that was made. That’s fine too, although the first thing you will do with a list of rolls is tabulate it into a count of each face. Here are two potential approaches you could take with data collection. Either way is fine. You’re just measuring slightly different things:
  • In one approach you could attempt to gather data in the environment that best describes your use case. Sit at your dining room table, maybe scatter some books, papers, and soda cans around as obstacles and get rolling. The idea here is that your data will do a good job representing the performance that the average home user sees.
  • In the other, you can attempt to gather data in an ideal environment: attempting to optimize for bouncing, well lit for accurate reading of results, and using as close to the same force and angle for each throw as possible for consistency. This approach is an attempt to capture as close to the true distribution of faces of the die as possible. The fact that the end user will never experience these idealized results is irrelevant.
• Analysis: Surprisingly there’s not much to say here. You have your planned tests. You have your parameters. You have your collected data. The analysis is just math. The math is simple enough for most Chi-Square tests that you can literally do it with pencil and paper (and if you’re like me you’d find that fun but would also make dozens of simple errors and then have to hunt them down.) In practice, this is almost exclusively done via one form of software or another. The end result of analysis is almost always a p-value and a statement about the original claim for each test, something like: “p-value=.003 Evidence exists to reject the claim that all the dice tested share the same distribution.” We use p-value for most test results because they are familiar to many people, they are fairly simple to understand, and they are standardized such that completely different tests, even different types of test can be compared easily. P-values by the way literally mean “If our H0 hypothesis is true, this is the probability of observing data as or more rare than we did.” For the final statement, keep in mind that actually proving something with statistics is almost impossible. Disproving things is sometimes just as hard. Instead most statistical results make use of phrases like “Evidence exists in support of the claim that…” or “Data suggest that…”
• Presentation: Sharing your results is a straightforward process. You simply walk through this same process and explain what you did.
  • Discuss what you were attempting to test. This part can be in plain language. Explaining the problem or question.
  • Explain your analysis plan including tests, threshold for significance, and sample size. You may want to discuss why you designed your plan the way you did. This is also a good place to discuss common statistics concepts and definitions if you feel your audience may not be familiar with them.
  • If you did anything fancy for data collection, you will probably want to share it. You may want to share graphs of simple descriptive statistics of your data. It’s also a good practice to provide your actual data set if there’s no good reason not to.
  • Go over each test you performed and their results. As mentioned earlier, if possible, these should mostly be just p-values and statements of what those p-values say about your initial claims.
  • At the end you may wish to close with an overview especially if your results show an important trend or pattern. Even if your results aren’t particularly impressive, a conclusion like “Results are inconclusive, further testing with larger sample sizes is needed.” can be useful as well as suggestions for follow up tests that could be performed.

So that’s the general approach for testing dice. This isn’t comprehensive. There are quite a few bits I glossed over but for our case study it’s a sufficient framework to work with.

Next week is part 2: Review of the Honest Dice Analysis.

The week after that is part 3: Suggested Analysis.

https://gnomestew.com/a-case-study-in-dice-stat-tests-part-1-general-approach/

https://gnomestew.com/?p=52899