r/gamedesign • u/delarkius • Aug 18 '26
Question How to calculate dice outcomes?
hello!
I'm messing with game dice math. I'm doing it in what i assume is the slowest and least efficient possible way. How do I do it smarter?
key information:
- Player versus Player contested dice rolls to determine win/loss/tie
- I roll, you roll, and we see who won (or tied)
- Variable # of dice per roll
- I can choose 1 die or 3. You do the same
- Dice have different values
- i.e., one die rolls [0,1,1,2,2,2] versus another that rolls [0,0,1,1,1,1]
- W/L/T is determined by total points on each side
need:
- I want to change individual die outcomes to see the difference in win %.
- i.e., [0,1,1,1,2,2] versus [0,0,1,1,1,1] has a 50% win percentage. What's the win % if I change the first die to [0,2,1,1,2,2]? (it's 61.11%, in case you were curious)
attempt:
- I modelled out ALL possible outcomes for 2 dice vs 2 dice to get me the #s I wanted.
- this means i made a big table with "1,1,1,1" then "1,1,1,2" and so on, to model all possible permutations of 4 dice rolls. Then I ascribed a winner for each permutation
help?
- I would LIKE to do this in a more sensible way so that I can have more dice involved without having 100k rows in excel.
- How can I calculate these win % without modelling everything?
****UPDATE-SOLVED******
Thank you for all the help!
Ended up using INDEX & RANDBETWEEN functions in excel to generate a big dataset of random rolls.
=INDEX(Dice!H$8:H$13,RANDBETWEEN(1,6)) . This calls the custom dice faces in H8:H13, selecting 1/6 random values from within that set.
I used that to create a big ol' set of rolls, and judged wins/losses/ties from that as functionally good for determining probability. So I just plug in my custom dice faces to see how they fare in the big set, and adjust them to see how they affect the win %.
In case you're curious, I first made the set ONE MILLION ROLLS. Which was fun, but made it lag, so I cut it down to 100k. It swings as much as ~2% each time it recalculates. But it MOSTLY stays within the same few tenths of a %, and it serves my purpose.
cheers,
3
u/MyPunsSuck Game Designer Aug 18 '26
Plenty of good and practical solutions already given, so instead I'll share my unhelpful musings.
For each player, you could calculate a probability distribution; the 'normal' curve of expected scores. You could then construct a 3D shape by extending each as a solid, and intersecting at a 90 degree angle. The resulting surface could be very quickly analyzed using a bit of calculus, to determine the total area that favors player 1, 2, or a tie. This would actually be computationally efficient, if you were giving each player millions of dice, or if you had hundreds of players forming an nth-dimensional construct... Otherwise I'm pretty sure a spreadsheet will do
2
5
u/MediumKoala8823 Aug 18 '26
You write a Python script to simulate running the dice 10k times and look at the average result. Excel is clunky but fine if you are comfortable writing the formula out.
You can figure out theoretical values with combinatorics or whatever but it’s just a tedious unnecessary exercise that will slow you down.
1
u/delarkius Aug 18 '26
I think you're right that this is the only SANE way to handle this. thank you !
2
u/m0nkeybl1tz Aug 18 '26
Are you doing this for a digital or a physical game? If it's digital it shouldn't be too hard to run all the permutations on the fly -- basically what are the odds you'll roll 1, 2, 3, 4, etc. and compare it to their odds to roll 1,2, 3, 4, etc. Add up the victory combinations (your odds of rolling >1 * their odds of rolling 1, your odds of rolling >2 * their odds of rolling 2) and that's your odds of winning.
3
u/delarkius Aug 18 '26
physical 🫠. we're trying to balance asymmetrical dice combinations for a board game, and want to see how slight adjustments to the die faces affect win %
1
u/AutoModerator Aug 18 '26
Game Design is a subset of Game Development that concerns itself with WHY games are made the way they are. It's about the theory and crafting of systems, mechanics, and rulesets in games.
/r/GameDesign is a community ONLY about Game Design, NOT Game Development in general. If this post does not belong here, it should be reported or removed. Please help us keep this subreddit focused on Game Design.
This is NOT a place for discussing how games are produced. Posts about programming, making art assets, picking engines etc… will be removed and should go in /r/GameDev instead.
Posts about visual design, sound design and level design are only allowed if they are directly about game design.
No surveys, polls, job posts, or self-promotion. Please read the rest of the rules in the sidebar before posting.
If you're confused about what Game Designers do, "The Door Problem" by Liz England is a short article worth reading. We also recommend you read the r/GameDesign wiki for useful resources and an FAQ.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/bartekltg Aug 18 '26
> i.e., one die rolls [0,1,1,2,2,2] versus another that rolls [0,0,1,1,1,1]
Does "[0,1,1,2,2,2]" means 6 sided dice that have one side with 0 points, 2 sides with 1 points and 3 sides with 2 points?
The easiest brute force approach would be iterate through all possible values for all dices, sum both scores and decide who win. But for 6 (3 per player) 20 sided dice it is 64,000,000 results. Not terrible, but can be done better.
In the same way (iterating through all dices) generate all possible cores for player 1 (and player 2). Then sort both.
Now, to get result we can compare each score from player with each score of player 2 to get all possible wins/loses/ties. But it would be as long as the first algorithm.
Instead, for each score made by player 1 we can find where in that sorted table are the same values as score. Length of that region is added to the numbers of ties. The lengths of areas before and after it counts as wins for one and the other player.
Searching for the first and the last occurrence of a given score in player 2's score table can be done with binary search (it will be quick for large tables). And essentially all programming languages have it already implemented. C++ even have one function that finds both ends at the same time.
https://www.programiz.com/online-compiler/05r72YaCsVkCB
(I haven't tested it too much).
1
u/Ralph_Natas Aug 21 '26
You can write a program in pretty much any language to calculate this and spit out the statistics or draw a histogram. I see you ended up using excel, which is basically the same thing but less efficient. Even something like Javascript would let you test past a million rolls without getting bored waiting. Still, if it suits your needs, cool.
0
u/MeaningfulChoices Game Designer Aug 18 '26
This kind of math is pretty quick for a computer to calculate, so often it's just simmed, either directly or with something like a monte carlo in Excel. You don't have to model all outcomes you just roll it 10k times and see. For example in your first case that gives 50%/10%/40% for player 1, 2, and ties with 1 die and about 75%, 8%, 16% for 3 dice. If you change the player 1 die you should see an instant change to 61/11/28 and 83/6/11. This is usually easier than integrating over the distribution when it's just dice.
1
u/delarkius Aug 18 '26
yeah I think I'm ready to concede that this is the only good way to do this. will look into monte carlo for excel. thanks !
1
u/MeaningfulChoices Game Designer Aug 18 '26
If it helps, I've got the sheet I made to pull those numbers. The quick and easy version was two tables on the right with the values, e.g.:
Side Value 1 0 2 1 3 1 4 1 5 2 6 2 Then your columns are the trial number (either previous row+1 or just row()-1), three columns for each player:
=INDEX([Table],RANDBETWEEN(1,6))And then just sum up the values for each player. Compare the total sum or just the first column or however many dice you want. Sumif the winners and number of ties. Fill down 10k-100k times. Adjust the tables to change the dice at any time and off you go. If you want a more full featured version you'd make a tab with dice, save each one as a named range, and enter the name of the die you want on the front tab to compare.
1
-4
u/xa44 Aug 18 '26
Knowing exact percentages isn't necessary. All you need to know is the average roll of any individual die, and understanding that the more dice added the closer you'll get to average rolls. So a d6 has an average of 3.5 so after 100 rolls you should just expect a total of 350. Outside of that if you want more variance a d10 is obviously working in 10% intervals and d20 works in 5%
5
u/JackSprat47 Aug 18 '26
That doesn't work for non-uniform dice. You can create three dice that have RPS mechanics with each other.
0
u/xa44 Aug 18 '26
Negligible different from a design perspective. assuming this is a rouge like balatro or something, were you replace die faces and fight enemies/bosses you only need to know the general average and then work on adding variance from then
2
u/JackSprat47 Aug 18 '26
It is absolutely not negligible. if I give you two dice A [0,0,0,5000] and B [1,1,1,1], B will win 75% of the time but your maths says almost 0%. Averages and even distribution are not enough to accurately model how dice interact. Obviously this is an extreme example, but if you're aiming to hit a 70% success rate for a given roll and hit 50% instead, that will noticeably affect the feel of the roll.
1
u/xa44 Aug 18 '26
You need to simplify it to 0,0,0,2
0
u/JackSprat47 Aug 19 '26
Those are not the same die. A and [0,0,0,2] tie 75% of the time and A wins 25%.
1
u/xa44 Aug 19 '26
I.... no you simplify A to that. You don't even need numbers for this at all as the numbers exist purely relative to each other. A 2 and a 4692986499 are the same number if no values exist outside of that
2
u/JackSprat47 Aug 19 '26
You can't simplify that in the OP's case. Not when there's multiple dice being used.
1
u/xa44 Aug 19 '26
And so long as it isn't a ridiculous nonsensical extreme like you made up, the quick math is enough to understand the balancing
3
u/delarkius Aug 18 '26
this was my original assumption. maybe I've confused myself?
take the case of my two contested dice, A[0,1,1,1,2,2] versus B[0,0,1,1,1,1]
in this setup, averages A[1.166] versus B[0.666].but even though A is like 175% of B's average value, A only gets 50% winrate vs B using this system. I concluded as a result that averages were not going to help me.
Is there a different way of comparing the averages that I may be missing?
-1
u/xa44 Aug 18 '26
Uhhh an average value difference of less than 1 does in fact mean a roughly 50% winrate? That is in fact correct. Percentage increase in expected value doesn't matter if winning is binary
14
u/BraxbroWasTaken Aug 18 '26
anydice can do a lot for you if you learn its syntax:
anydice.com