# What is the probability distribution for CthulhuTech rolls?

I've recently learnt about CthulhuTech, which has a unique dice pool system:

CthulhuTech uses a proprietary game system known as "Framewerk" that focuses on a dice pool system. An unusual feature is the selection of numbers from the d10 rolls – a player can pick a single highest number, all like numbers, or straights of consecutive numbers, and use these to generate the result. The result is then added to a "base" consisting of a related attribute score bought by the player at character creation. The sum of the base and the result is then compared to target numbers or to the results of an opponent's rolls to determine success or failure.

So for instance a roll of 1,2,3,4,5,5,10 the player could pick either 1,2,3,4, 5,5 or 10 to add to their base score for a dice roll, before comparing it to the target number.

As a future game designer, I'd like to understand what sort of probability curve this creates for a given set of dice pool sizes, say 1-10 dice. This will hopefully let me see if I want to incorporate a similar dice pool system into a game I am planning.

• If I recall the CthulhuTech rules correctly, wouldn't the example roll allow taking '1, 2, 3, 4, 5' as a straight? I must confess that I mostly bought CthulhuTech in order to do a write-up of the statistics of the system. It also has a slight paradoxical effect, as half of the "add one more to the pool" actually makes fumbles more probable, and half makes a fumble roughly 10% as likely as the previous level. May 18, 2021 at 15:02
• @Vatine I've never read the rules so I couldn't say. What you said makes sense though, feel free to edit that in if you're confident? May 18, 2021 at 16:20
• I would have to go find the rulebook and double-check. Unfortunately, I am not sure exactly where it is, and there's enough demands on my time that "a comment" works, but "try to locate a rulebook I last saw within 6 months of the game being released" may be out of scope. May 19, 2021 at 8:39
• @Vatine it was probably devoured by a great old one anyway, thanks regardless! May 19, 2021 at 10:46
• I have had a look in the place where I last recall seeing the book, but it was not there. I will, over time, look in more places (and take a more careful look). May 21, 2021 at 18:50

The result of having multiple ways to get choose numbers from the dice pool are quite chaotic.

The creator of anydice tweeted this anydice function for CthulhuTech dice pool rolls.

The graph of these results, seems to follow a fairly regular outline, despite some values being wildly less likely. For instance with a pool of 5d10, a result of 25 is 0.29% likely, but 24 and 27 are 4.47% and 5.85% likely respectively.

It's unclear what the benefit of such a dice pool system is.

The anydice function time out for numbers over 7d10 so a full range of graphs isn't currently possible.

• @HeyICanChan: The writing in CthulhuTech is ... confusing. The dice mechanic seems to have been designed by someone who found oWoD cool, but overly scientific. Mar 30, 2021 at 17:22
• The original tweeted code has a bug in that repeated values break straights. I've submitted an edit to this answer with a corrected version: anydice.com/program/2509e Oct 31, 2021 at 7:29
• That dice mechani is... Chaothic. How fitting for Cthulhutech. Oct 31, 2021 at 10:41
• @nick012000 I don't think so. Follow the anydice link and have a look Oct 31, 2021 at 11:14
• @nick012000: Straights are required to be of at least length 3. Nov 1, 2021 at 1:26

# All pools up to 10 dice

(Technically the results go up to 100, but the chances above 60 are so small as to be practically invisible so I omitted them to give more space to the actually-visible part of the graph.)

## Algorithm notes

With the right algorithm, a pool of 10 dice can be computed in under 100 milliseconds, even running in a web browser. Here's an interactive notebook.

Many dice pool scoring systems can be formulated as:

• Start with an initial state. In this case the state is the score so far and the current run length, which are both zero before any dice are considered.
• For each number on the die, see how many dice rolled that number and update the state. In this case we either end the current run, or increment the run length. Then, we score the current run (if it's of at least length 3) and the current matching set.
• After all numbers are accounted for, output the score corresponding to the final state.

It turns out that, as long as the possible number of states is not large, it's possible to determine the probability distribution of the final score much faster than by enumerating all possible rolls. The keys to the algorithm are:

• Keep the number of states small. In this case the run length is at most 10 and the score goes up to 10 times the number of dice, which is not too bad.
• Don't iterate "horizontally" over one die at a time. Instead, iterate "vertically" over one number at a time. In a dice pool, you usually care a lot about how many dice rolled a particular number, and you usually don't care about (or even know) in what order the dice were rolled.
• Instead of determining which dice rolled a particular number, only determine how many dice rolled that number. This can be computed and cached according to Pascal's triangle.
• Cache intermediate probability distributions over states, indexed by how many numbers on the dice have been processed and how many dice are remaining.

For 10 dice, instead of considering the 10 billion possible rolls individually, the algorithm evaluates next_state() a mere 9809 times---a factor of about a million. Even if each state takes longer to process that's still a huge speedup.

Source code can be found here.