# How represent a D6 pool system where a 5 is half success and a 6 is full success using Anydice?

I am creating a YZE custom system using only D6s, where there is the possibility of getting a "half success" when you get a 5. That means you need to get two 5s to get one success.

At the same time, the rule about the 6s being a success remains the same.

Getting just a half success is meaningful because is a "success with a consequence".

But getting 1.5, 2.5, etc is not important you just round up to 1, 2, etc.

I have not figure out what pushing the rolls means yet.

How would you represent this in Anydice?

• Hello there, welcome to RPG.SE! You may take the tour and visit the help center to get some guidance in posting Q&A! It is not clear to me what you would like to represent in anydice: if I roll 6d6 and I get 6 3 4 4 5 5, do I have 2 success? Instead, if I roll 6 1 1 1 5 4 I have 1 success? Sep 10, 2022 at 7:46
• Pushes are tricky. Their outcome depends on types of dice rolled, and the result would basically be one count of successes, one count of base dice 1s and one count of gear dice 1s.
– From
Sep 10, 2022 at 9:49
• What question are you trying to answer? One of specific probability, or are you trying to get a more general feel for your twist on the YZE mechanic? Sep 11, 2022 at 0:23

If I understand you correctly, something like this should do it:

loop N over {1..10} {
output Nd{0:4, 1, 2} / 2 named "[N]d6, 6=success, 5=half success, round down"
}


You can't directly represent non-integer values in AnyDice. But what you can do is count the number of half-successes in your roll (i.e. one for each 5, two for each 6) and then divide by two.

Division in AnyDice rounds down (actually towards zero), which seems to be what you want here based on your examples, so there's no need to adjust that. If you did want to round upwards instead, you could add one before dividing by two (or, more generally, add $$\n-1\$$ before dividing by $$\n\$$).

The code above does not differentiate half a success (which you mentioned you want to treat as "success with complications") from no successes at all. Perhaps the easiest way to get the probability of that happening is simply to calculate it separately:

loop N over {1..10} {
output Nd{0:4, 1, 2} = 1 named "[N]d6, one five, no sixes"
}


This will output 1 if the number of half-successes rolled is exactly one, and 0 otherwise. This kind of "boolean" output is most conveniently viewed in the AnyDice summary view (which the link above takes you to), where the "mean" chart directly shows the probabilities of rolling a single half-success. You can subtract these half-a-success probabilities from the zero success probabilities given by the first script above to get the actual probabilities of rolling not even half a success. (Or just change the = 1 in the code above to = 0 to output them directly.)

If you want to get both the distribution of whole success counts and the probability of getting a single half-success from a single AnyDice script, you're going to have to do a bit more work — in this case, as usual, by writing a helper function to map the half-success counts to the final output.

But first you'll need to decide how to represent the different possible results in the output. One fairly reasonable option would be to use –1 to represent "not even half a success", 0 to represent "only half a success" and positive integers to represent one or more full successes (i.e. 1 = one success, 2 = two successes, etc.). Using that representation, we can write our helper function like this:

function: count HALF_SUCCESSES:n {
if HALF_SUCCESSES = 0 { result: -1 }  \ not even half a success \
if HALF_SUCCESSES = 1 { result:  0 }  \ "success with complications" \
result: HALF_SUCCESSES / 2  \ otherwise just count whole successes \
}

loop N over {1..10} {
output [count Nd{0:4, 1, 2}] named "[N]d6, -1 = fail, 0 = complications, 1+ = success"
}


The (minor) down side to this encoding scheme is that the mean and standard deviation values automatically calculated by AnyDice become rather meaningless (whereas for the first script above they directly give you the average number of full successes and its s.d.) since the output numbers are no longer linearly proportional to the total number of successes. But you can still eyeball the graphs to see how the distribution changes as you increase the number of dice.

As @Ilmari Karonen points out, one has to undergo some contortions to re-frame this mechanic in terms that AnyDice understands while still being useful to human beings. As far as I'm concerned, his is a (the?) correct answer in direct response to the question posed, but I hope this provides additional and useful insight into the modification.

With respect to modeling either the Year Zero Engine mechanic or this modification, things get pretty nuanced, especially—as the OP suggests—when dealing with pushes, which are optional, heavily situational, and at the discretion of players. But we can at least examine the relative difference between the original mechanic and the modification under artificially controlled circumstances, which may give some insight as to whether it's worth play testing (which is really the final arbiter of whether the mechanic is sound).

Because this is hard(er) to do with AnyDice, I took a stab at some enumerations and comparisons using dyce¹. You can see my full attempt and play around with it in your browser: [source]

The burst graphs in the attached screenshot depict the modified mechanic as the inner donut overlaid against the legacy mechanic as the outer one. As expected, the number of anticipated successes is generally higher with the modification, especially as pool size increases. Further, the likelihood of banes on a push generally decreases.

The substantive code is in year_zero_and_a_half.py. The graphs are generated from that notebook using anydyce². The notebook allows some interaction (the pool size and whether to round half successes). It also displays raw data (not depicted here), which agrees with @Ilmari Karonen's results.

All that being said, it's unclear (at least from my position of ignorance) what the design goal is. YZE already has a (perhaps crude) mechanism to introduce costs that accompany attempts to succeed via banes. If the mechanic is meant to address player complaints of the legacy mechanic being too harsh, one could ease difficulty by increasing pool sizes (e.g., increased skills, more or better gear, etc.). Again, play testing is probably the best way to vet any adjustment.

¹ dyce is my Python dice probability library.

² anydyce is my visualization layer for dyce meant as a rough stand-in for AnyDice.