I'm thinking of converting to a logarithmic rolling mechanic that's less granular than the one I've been using so far.  I've tried all sorts of dice looking for one.  I was wondering if anyone else knew of a better one?

Right now I'm using |d6 - d6| (Roll 2d6, subtract the low die from the high die), Snake Eyes = Botch/-1, and I use special rules for higher results.

This approximates a nice curve, where if x is the chance of success at difficulty y, then 1-(1-x)^2 is the chance of success at difficulty y-1, and 1-(1-x)^.5 is the chance of success at difficulty y+1.

The math makes it very convenient for use with exponential time scales and unit magnitude, based on exponents of 2.

I was wondering if anyone, however, knew of a convenient mechanic that would work on exponents of either the square root of two, or the cube root of two. 

Basically, I'm trying to make the system less granular.  Going by exponents of 2 means that small levels of difference in capability aren't worth keeping track of.  This is fine for certain settings, in my opinion, but I've considered that in a lot of stories, more minute differences come into play.

Besides this, working on exponents of the cube root of two would mean, conveniently, that logarithms of 10 would also approximate into the same system in steps of 10 exponents. (cube root of 2 to the 10th power is about 10)

Maybe I've just been thinking about it too long, and my mind has burnt out.  I know rolling schemes do exist for such a curve, but I haven't found anything simple enough to throw at a game.  Does anyone know of something that will work?

-Jason T.

Maybe you've thought of this, maybe I'm way off track....just an idea.

You could always switch to using d10's rather than d6's, applying half the level of effect for each die increment.

It'll give you an effective scale of 0.5 to 5 in 0.5 increments, compared to your current scale of 1 to 6 in whole number increments.

Otherwise the mechanics could remain relatively intact.

This will give a half step between each of the current levels that you've got, though it won't quite reach as far. But your mechanics for higher results may be able to take such things into account.

Of course, you may have thought of this, and may be steering clear of non d6 dice. In which case, this will take a bit more thought to delve into.

V

If you want a bell curve, use more dice but ones with smaller sides. Flipping 12 coins seems to be a pretty easy way to do it but I don't like the flipping mechanics behind coin tosses.

I really can't help you beyond that unless you give a more detailed explanation of what it is you want.

The issue here is that it doesn't look like VoidDragon is after a traditional bell curve for his rolling mechanic.

If we read the top row as the first die, and the first column as the second die, these are the results we get.

[table]
[tr][td][/td][td]1[/td][td]2[/td][td]3[/td][td]4[/td][td]5[/td][td]6[/td][/tr]
[tr][td]1[/td][td]X[/td][td]1[/td][td]2[/td][td]3[/td][td]4[/td][td]5[/td][/tr]
[tr][td]2[/td][td]1[/td][td]0[/td][td]1[/td][td]2[/td][td]3[/td][td]4[/td][/tr]
[tr][td]3[/td][td]2[/td][td]1[/td][td]0[/td][td]1[/td][td]2[/td][td]3[/td][/tr]
[tr][td]4[/td][td]3[/td][td]2[/td][td]1[/td][td]0[/td][td]1[/td][td]2[/td][/tr]
[tr][td]5[/td][td]4[/td][td]3[/td][td]2[/td][td]1[/td][td]0[/td][td]1[/td][/tr]
[tr][td]6[/td][td]5[/td][td]4[/td][td]3[/td][td]2[/td][td]1[/td][td]0[/td][/tr][/table]

1 chance in 36 of a botch, 5 chances of rolling a 0, 10 chances of a 1, 8 chances of a 2, 6 chances of a 3, 4 chances of a 4 and 2 chances of a 5.

We don't have the even chances either side of a centre that you wound normally find on a bell curve. Also, bell curves tend to flatten out in the middle, which is something you don't get in this type of progression. It would be interesting to see the mechanic for higher results, and the context for the system before suggesting further options though.

V

Vulpinoid wrote:
You could always switch to using d10's rather than d6's, applying half the level of effect for each die increment.

Of course, you may have thought of this, and may be steering clear of non d6 dice. In which case, this will take a bit more thought to delve into.
V

Vulpinoid wrote:
The issue here is that it doesn't look like VoidDragon is after a traditional bell curve for his rolling mechanic.

It would be interesting to see the mechanic for higher results, and the context for the system before suggesting further options though.
V

As for the context of the system, as you've asked, I have mentioned it in other posts.  Rather than put links to them, I think I'd rather try to reword myself here.  Besides, my system has changed due to playtests since my previous posts.

I don't have enough time right now to type out my whole Power 19, or my reasons for doing things this way.  You'll have to think of this as reactionism to systems that make the boring part of a game complicated.  In such games, the interesting part gets lost.  I also wanted a game where rounds could be 1 second or 15 minutes, and the rules work the same.

All actions that occur simultaneously must make their rolls simultaneously.
The action that failed by the smallest margin succeeds.
If more than one character failed by the smallest margin, they all succeed semi-simultaneously.
(semi-simultaneously: simultaneously in gamist terms but not necessarily in descriptive terms)

There are other rules for declaring non-interruption clauses etc; but that's the basic idea.  It allows me to incorporate time in on an exponential scale.  Things can be tracked in all kinds of ways, and different situations, broken down in terms of events, can always be mapped to the system.

-Jason T.

Jason:

From your initial post, you stated you wanted a probability curve that meets the following constraint:

P(Success|Diff=Y-1)=1-(1-X)^Z, where X=P(Success|Diff=Y) and where Z = either 2, square root of 2, or cube root of 2.

This is a family of S shaped probability curves.  Arbitrarily starting at 0.05 as the first probability, the curves would like this for the first 20 difficulty levels:

2 sqrt(2) cubrt(2)
1.000 1.000 0.995
1.000 1.000 0.984
1.000 1.000 0.962
1.000 1.000 0.926
1.000 1.000 0.874
1.000 1.000 0.806
1.000 0.999 0.728
1.000 0.990 0.644
1.000 0.962 0.560
1.000 0.902 0.479
1.000 0.806 0.404
1.000 0.687 0.337
1.000 0.560 0.278
0.999 0.440 0.228
0.962 0.337 0.185
0.806 0.252 0.150
0.560 0.185 0.121
0.337 0.135 0.098
0.185 0.098 0.078
0.098 0.070 0.063
0.050 0.050 0.050

Your current system does match up pretty well with the first column given P(Success|Diff=5) = 0.096 or so.  However, just changing the die size doesn't help, the underlying curve of your mechanic is quite different from an S curve with increasing die size.  This S curve is also different in shape from the standard roll under or over cumulative S shaped curve.  I see your difficulty.

I'm thinking about it.

Hans

Thank you, Hans.  That looks about right for the curve.  What program/language are you using when you say P(Success|Diff=Y-1)?  I've never taken a statistics course, actually, so I don't know a lot of the terminology, just how chances work.

Since .05 would be the chance of getting difficulty 6+ for heroes or 5 for mooks, you have a bunch of extra 100%s for all the difficulties below -1 or so.  A dice mechanic curve that approximates that cube root column would be ideal. 

Looks like the rolled values would fit 95% of the time within 21 values, so the curve we're looking for with a cube root would probably yield values 0 to 20, or -10 to 10.

The mechanic also has to weight toward the low end, so things I've tried were rolling multiple dice and removing the highest, etc.  I still haven't found any other simple way of replicating this curve.

I don't mind sticking with the exponents of 2, it just has big implications for other things I'm going to do in my system.

-Jason T.

The jargon "P(X|Y)" is mathspeak for "the probability of X given Y" and I am probably using it incorrectly anway, just trying to show off.

I am more and more convinced that there is no simple mechanic that gives a skewed S shaped curve similar to what your desired function gives.  Haven't given up hope, but, in the interim, three suggestions:

* TABLES, baby! 

You could use *gasp* percentile dice and a table to get exactly what you want.  Downsides: maybe more handling time with a table.  Upsides: Tables can be cool (see old Marvel Super Heroes game) and with color and extra references around the edges, can be quite useful.  They also open the realm of other possible mechanics (column or row shifting, gradation of success as opposed to pass/fail, etc.)

* CARDS, baby!

You can model just about any probability distribution with a deck of cards, simply by adjusting the number and frequency of the cards within.  The following mechanic does an ok job at your sqrroot curve:
* Take the following OUT of a regular playing card deck with 2 jokers:
Card Take OUT
2 3
3 2
4 1
9 1
10 2
J 2
Q 3
K 3
A 3
* For each "roll", draw one card at random.
* Difficulty is 2-A, must draw card equal to or higher than difficulty.  Jokers always fail.
* Shuffle after each roll.

Downsides: Cards are more cumbersome than dice, and shuffling can be a pain.  Upsides: Cards open up whole new realms of mechanical possiblities, including special text on cards, special meanings, holding cards in hand, etc.  A custom deck of cards (one that comes with the game) is especially interesting.

* CUSTOM DICE, baby!
I have no idea how much custom dice cost, but they might be worth it.  A custom d20 could be used to easily replicate the 1-12 difficulty scale of the sqrroot curve, and some thought could give you a pair of d20's that could give you the cuberoot curve.  Downsides: extra cost.  Upsides: custom dice, those are just cool.

Between the three of those, I'd have to say I like custom dice the best.  I had already considered optional custom dice for a previous iteration of the exponents of 2 rolling mechanic, but it turned out my players just liked the "lucky number" idea, so I quickly disposed of that.  But now that you've brought it up again, I just thought of a new idea.

Of course, with custom dice, there's no reason to stick with d6s.  And I like the shape of d12s for some reason, so I just thought up this idea.  2 Custom d12s.  The roll would simply add the numbers together.

The sides of the d12s would be like this:
0
1
2
4
5
6
6
7
8
10
12
15

(If I've done the math right) It looks like that would get a decent curve.  The gaps I can deal with.  What do you think?

I'm thinking right now that if I can get my system to work in exponents of 2, that I can always save the less granular methods for later editions.  The core mechanics and ideas will always be portable between the two because each scale would just be a multiple of the other, x2, x3, or divide by 2 or 3.  So before I invest in something like custom dice perhaps I'll just work on getting the system working as-is. 

-Jason T.

Ugh.  Looks like my math was wrong.  Try this one for the sides of each d12:

0,1,2,3,4,5,5,6,6,7,10,15

The nice thing about this one is that the only two-digit numbers are 10 and 15, which are easy to add.

This one is meant to make a good curve for cuberoot of 2.

-Jason T.

And this should work for the square root of two (again, 2d12, with sides as follows:)

0,1,1,2,2,3,3,4,4,5,6,10

Again, the math should be easy here, since 10 and 1-digit numbers are easy to add.

-Jason T.

The cube root one is a nice match, no more than 3% off at any one difficulty level, and the sum of absolute differences across all meaningful difficulty levels (i.e. 0 to 21) is only 26%.  You do get the weirdness of the possiblity of the discontinous 25 and 30 results, but those are rare, and could be integrated in the mechanics as some kind of critical result (success/failure/weirdness).

Of course, TWO DIFFERENT custom dice make it even easier to get exactly what you want.  For example:
Add your die and this one:
1, 2, 3, 4, 4, 5, 5, 6, 7, 7, 10, 15
And the sum of absolute differences is cut to 16%, no more than 2% off anywhere along the way.  I think it could go lower.

If you were REALLY serious about this you could write a computer program that iterated through all the reasonable sections of possible 2d12 space and found the exact combination of values that minimized the sum of absolute differences between and the die probability distribution and your function fitted to the die probability curve.  I'd estimate that at 10 combinations per second, with some realistic limits on the space to search, it would take about 3 weeks of computing time.  :)

The discontinuity is due to the fact that there are only 128 possibilities.

My view on this is that 30 is a reasonable approximation of anything within the general region of 30, and 25 is a reasonable approximation of anything around 25.  To see this, try calculating the integral of the target curve for all values 23+, then compare that to the area under the distribution curve.  It is off a bit (shortchanging slightly the rolling character on the high end), but close enough for my purposes.

Besides this, remember my earlier rule to extend the curve out to infinity?  To smooth out the curve here, I could simply institute an adding rule for rolls of 22+.  Instead of rolling an even number to get +1 (which would convert to +3 in the cube root curve), it would probably be more complex than necessary.

I'm not really concerned about it.  My philosophy has always been, if there's ever a chance a player could succeed, even if it's one in a googleplex, and the player still wants to roll it, you should at least let the player roll.  However, I think, in the extremely rare circumstances where rolling above a 30 is actually meaningful, and the character does actually roll a 30, rolling even to add +3 is more than sufficient to accomodate this.  Doing this for any roll of 20, 25, or 30 (but not 21 or 22) seems to smooth it out quite nicely, actually.  The reason that it works, of course, is that the curve approaches something like reducing chances by half for every +3 difficulty at high levels.

Another way of doing the same thing would be rolling a d4, adding 3 on a 3, adding 6 and rerolling on a 4.  On a d8, this could be adding 3 on a 5 or 6, adding 6 on a 7, and adding 9 and rerolling on 8.  Honestly, it's probably not worth dealing with, though.

Thanks for all your suggestions, Hans.  I'm definitely taking some of these ideas to heart.  Your idea to make the dice different in order to make the curve more precise jives, but I imagine it would not only raise costs, but confusion at the table at making sure the player has one of each die.

Besides that, the die you presented eliminates the zero.  The reason I like the zero is that it's slightly easier to calculate (and makes more sense) when and when not a character should even have to make a roll.  With a zero, if the difficulty is less than or equal to the character's base statistic, no roll is necessary.  Without a zero, you have to add a one in there.

As for using a computer to find the best one, I might end up doing just that.  Looks like we probably have different methods of computing what you call "absolute difference".  I take account of the extra (or lacking) chances of getting "this value or greater" for each value, then take the absolute value, and sum them up.  My rounding is to the .1 in 144, not to percentiles, so that's probably why I came up with something more like 41/144 instead, if I recall.

The reason I base it off of "this value or greater" is that it distributes the curve more evenly, and like I said, accounts for spreading out values of higher difficulty, so you can have these spikes at 25 and 30, and they work to account for surrounding values.

However, if I do end up doing it on a computer, I may require it to keep the 0, the 1, the 10 and the 15 in there, and just figure out the other 8 values on its own.  I like having the 0, 10, and 15 because they speed up math.  I really don't want to clunk this system down with stuff the players can't easily do in their heads. And the 1 keeps the curve smooth on the low end.  Considering these restrictions, it looks like I've come about as close as I'll get.

Part of the goal of having these dice in the first place is to reduce the clunkiness of the mechanic.  Adding double-digit numbers should try to be as simple as possible.  I've got it bad enough with my current |d6-d6| mechanic.  Subtraction seems to take extra brain energy, for some reason, even with single digits.

I tried the same thing with d20s later yesterday, but didn't come any closer to a nice aesthetic result, though as I recall there was a little more precision.  D30s are ugly and hard to read, and would probably be hell to custom-order.  I think I'll stick with the prettier d12s.

From what I've seen on custom die pricing, it doesn't seem unreasonable.  It might become a bigger issue if I ever saw publishing on the horizon, but right now, my game is too embryonic to worry about that.  I do think I'm hopeful enough that I'd order more dice than necessary when it came down to it, if only to give out at cons when I run it.

-Jason T.

When I said "only 128 possibilities", I meant 144, sorry.

I'm running into some snags when converting the system to exponents of the cube root of 3, as well.  The issue is that the math (i.e., addition and subtraction of values) was pretty simple when you get to the granularity of exponents of 2.  In cbrt(2), the shorthand math for things one might have to figure out is just too.. dirty looking, if you know what I mean.

For instance, in exponents of 2, two magnitude 5 groups of soldiers, combined, would make a magnitude 6.  In cbrt(2), these same groups of soldiers, now magnitude 15 each, combine to make a magnitude 18 group.  And then we have to deal with the issues of which way to round when we add a magnitude 13 or 14 to a magnitude 15, etc.  It would amount to a calculation where, if the two added numbers are 1 to 3 off of each other, add 2 to the higher; if 4 to 6 off, add 1 to the higher, or something like that.  And there would likely in the end an optimal way to add up multiple sets to achieve maximum (or minimum) values.

And you start questioning yourself on what the point is of reducing granularity if you're either going to leave the math granular or make the math complex.  It's not as simple as multiplying all the exponents by 3 as I thought.  If I can get it to work, I'll consider it, but maybe this was a bad idea.

What I found convenient is below, but perhaps it's not sufficiently simple:

2^(1/3) is about 1.259, and 2^(-1/3) is about .793

So, rounding these to 1.25 and .8, you could say that adding one to the value adds roughly 1/4 again the substance (time/distance/soldiers etc.), and subtracting one subtracts about 1/5.  This makes sense, since (5/4)^3 = 125/64, which is about 2.  And (5/4)^10 is about 9.8x10^6/1x10^6 which is close to 10.

Also, 2^(-7/3) is about .2

So that if you remove an amount which is magnitude 7 less (.2 of) than the original amount, you are effectively subtracting 1 from the magnitude.  Likewise, if you add an amount that is magnitude 6 less than the amount added to, you are increasing its magnitude by 1 (because, of course, 2^(-6/3)=1/4).

-Jason T.

Don't get me wrong, mate, I'm loving the math here, but I think I've gone as far as I can go.  It sounds to me that you understand exactly what your design goal is, and you understand the math behind what you want to see where you might take it.  Now its all a matter of making the aesthetic judgement as to what tradeoffs (complexity vs. simplicity, exactness vs. fudging) best achieve what you want.  I might push one way (I'll almost always push towards fudging/simplicity, for preference) but you might push another way, and its your game. 

I'd be happy to help out with any other directly math-related questions you come up with, because, hey, I'm loving the math.

Okay.  Again, thank you so much for everything so far!  I'm still thinking about the sqrt(2) case, but I won't bug you with that.

A while back, I posted an idea on simplifying my rules for movement.  I haven't really had any comments, whether criticism or suggestions.  Basically, I'm thinking of simplifying space by abstracting distances down to an integer DE, where the distance between two objects rounds to 2^(DE) m.  I'd appreciate any feedback you might have, if you're interested in looking at that.  Here's the URL:

http://www.indie-rpgs.com/forum/index.php?topic=24418.0

-Jason T.

Ok, couldn't resist. 

According to the little Excel VB thing I wrote (code available on request), assuming:

* 0, 1, 10, and 15 are all on the die
* the two dice are identical.

then 0, 1, 2, 3, 4, 4, 5, 5, 6, 7, 10, 15 is the die that is the best fit with the cube root curve.  Specifically, it matches to a curve that has Difficulty 30 = 0.00654 probability of success.

Thanks for all your help, Hans!

Yes, I would be interested in seeing the code for that.  If it's small enough that Hotmail won't block it, you can get it to me at:

voiddragon@hotmail.com

My search, of course, always continues for an ideal rolling mechanic, and there is one other thing I'm trying out on my own right now, with little success.  It's basically the square root of 2 thing, on a one-half scale, dice are not identical, with one die consisting of only integers to reduce the adding of halves. 

We could end the conversation here, though.  Adding more precision to my rolling mechanic is actually a fairly minor issue compared to some of the other things I'm working on with this system.  I do, however, find it fun to experiment with, and hope eventually for something better than what I have now.

Thanks again.

-Jason T.