Methods of reducing variance

jasonrohrer · 2019-05-04 07:03:28

Hoping that someone familiar with probability theory can chime in here.... it's late... I'm foggy-brained.

The tool breakage currently works with use tiers, and a probability of transitioning between tiers on each use. This allows you to set a particular expected value, but also control the variance.

For example, if you wanted a tool to break after 20 uses, on average, you could simply roll a D20 every time you used it, and break it if you ever rolled a 1.

Your expected value, for number of rolls until breaking, is 20.

However, this is a geometric random variable, so the variance is 380 (standard deviation is 19). That is bad.

If instead we break this up into 4 tiers (four independent random variables added together), we know that the expectation of the sum is the sum of the expectations, so in order to have the same EV of 20 uses, we need each tier to have an EV of 5 uses, or 1/5 chance of going down to the next tier.

Each of these is again a geometric random variable, but now the Variance of each is 20.

For independent variables, we can sum the variance, and we have four of them. So now our overall variance is 80 (standard deviation 9), which is a HUGE improvement over 380 (sd=19).

By adding more tiers, we can get our variance as low as we want (with 20 tiers each with 1/1 chance of going to the next tier, we still have EV=20 uses, but our variance goes to 0).

This is cool, and great. But it depends on multiple tiers, which means it can only be applied in situations where an object will have a fixed number of uses that is being explicitly tracked, like a tool.

There's also a direct probability model available in the engine, where (currently) a weighted distribution is possible between various outcomes (fish, boot, etc. when fishing).

I'm currently using this for well pumps becoming exhausted, given them a 1/20 chance of transitioning to that state (the normal dry state is 0.95, while the exhausted state is 0.05 chance). But again, we're facing huge variance there of 380.

So it seems like there should be a way to modulate the variance directly somehow.... but I just don't think it's possible, given that we're only rolling one die each time we need to decide.

For example, there's no way to guarantee a minimum of 5 positive outcomes in a row.... obviously not. Need sleep, I guess!

Morti · 2019-05-04 07:44:58

Am I missing something?
1d4 *5, you only roll the next d4 if you get a 1.

I must be missing something.
But, this means would mean 6 states.

Let's say the 6 states are New, Slightly Used, Used, Well Used, Breaking, and finally, Broken.

N, roll 1d4, if 1, move down
SU, roll 1d4, if 1, move down
U, roll 1d4, if 1, move down
WU, roll 1d4, if 1, move down
B, roll 1d4, if 1, move down
Broken

You must have been trying to say that, somewhere in there and just lost me.

Side note, I'd love if you added the other end, what is known as 'exploding die' in some games. Where the life of an item is potentially indefinite. Say, the item had ((1d20) * 6 states) uses, but if you rolled 20, you'd get to add another d20 roll to the number of uses at that state. Everytime d20 is rolled, you add 20 to the number of uses in that state, and roll again.

https://1d4chan.org/wiki/Exploding_die

Maybe then someone can forge the mythical "Grandfather's Axe"

Morti · 2019-05-04 07:48:10

On the exploding die, this one is a little more computery
https://anydice.com/articles/exploding-dice/

I'm going to look into standard deviation more and try to understand what you were saying.
It's been awhile.

mrbah · 2019-05-04 07:54:59

I know that a lot of games use pseudorandom numbers to achieve a similar effect.
When a hero in dota has a 15% to crit, the game tracks how many attacks had no crit and eventually increases the actual % if there has been no critical hit for so and so many attacks.
This would require your game engine to memorize the actual % for each object that has a chance to transition, so I am not sure how viable such an approach is with your frankly gigantic map.

Morti · 2019-05-04 08:23:58

Just dawned on me that my first example is already, potentially, exploding die.
The 1d4 roll with each use, 1 moving the object to the next state of 'decay' would mean if 2, 3 or 4 are rolled indefinitely, the object could potentially stay in that state forever, obviously not likely, but there is that 75% chance with each roll, that the item does not decay.

Still reading google searches for "geometric random variable variance standard deviation" but this is a lot of math.

Having taken many calculus courses, I *could* recall all this, but not having used any of this stuff in 20 years, I'm tempted to look away when I see it. Surely someone younger, or with more recent experience, will have all this stuff fresh in mind and your answers will come to you.

I'll keep reading though, it's refreshing.

Dodge · 2019-05-04 09:08:07

jasonrohrer wrote:

For example, there's no way to guarantee a minimum of 5 positive outcomes in a row.... obviously not. Need sleep, I guess!

The only way i see that you could get 5 guaranteed positive outcomes for example is if the first 5 outcomes are different objects, for example pump used one time, pump used two times etc... then after 5 times it becomes the regular pump that has the probability just an example but with the current "use" and "probability" system that's the only way i see it. Unless you can track the previous uses for each objects and allow 5 guaranteed uses before the probability kicks in.

Last edited by Dodge (2019-05-04 09:10:30)

Morti · 2019-05-04 09:11:33

I think you should bite the bullet and add states of decay, rather than trying to get that guaranteed 5 uses in one state... I'm not sure what you are talking about specifically, but, let's look at steel axe.

https://onetech.info/334-Steel-Axe

Number of uses: 5
Chance to use: 4% (last use is 100%)
Estimated uses: 101

https://github.com/jasonrohrer/OneLifeD … ts/334.txt

numUses=5,0.040000

--

That was the wrong avenue for me, I don't know what I'm reading here.

--

I'm just going to suggest states of decay and leave it at that... well, honestly, I'd rather you make it like a real axe, with a wooden handle and a steel head, where either, the head gets dull and needs to be sharpened, or the handle breaks and needs to be replaced. I'd like a system more like that, where the state of the handle and the head are tracked/their number of uses are determined independently, and either one is it's own separate problem to be resolved, but barring an overhaul to a system like that, just adding states of wear or decay would be preferable to the "Good... / 1 Use Left / Broken Steel Tool" system that you are currently employing.

Maybe each resharpening of the of any steel tool could run the head through states... I don't know, it's not my game. I don't want this to devolve into throwing suggestions for game changes.

Reducing variance... yeah, states of decay, each with their own variance, seems kind of the opposite direction... or not. It'd probably be more work up front, making little cracks in things, or, adding 4 states for every tool, between the new and broken states.

I'm sure this is a simple problem and you just needed an excuse to sleep.

pein · 2019-05-04 09:59:37

yeah i got it, he talks about it other topic

basically the tiers/states need uses
the water already needs uses, which means he cant use it for the decay states same time
and each item can have only one type of usage
also the client cant directly move containers into containers, like you cant put the pie in a basket in a box with one click
so each use of water in each state of newcommen has to still work

so he basically needs other way to break it down
so my repair suggestion might be ok, like instead of uses, has a repair count which is quite the same but other variable

now the repair can be just a simple touch with a wrench which then allows it to work again
and when it reaches 5 repairs it wont be repairable

not sure how he added 'uses', we didn't had them until tools breaking update (i think first tools lasted forever?)
needs to edit client/editor?
for the newcommen machines he edited the whole left and right click mechanics to work, like right click separates, and left click picks up groups

basically to have states, requires an 1d array where 0-3 is different water levels and 0-5 for wick burner
so to have new and old newcommen needs a 2d array where an old newcommen with 2 water and and a new newcommen with 2 water has to be differentiated
and even for temperature and airspace he used a pseudo 2d array where x=y so diagonals acted as a 2d array but was stored in 1d

so even for 2 different breaking states he needs twice as much sprites and states, not talking about 4 different newcommens

not sure if it's an issue for him, but he needs a new variable which is not the "uses"
it's "uses2" and coexists with "uses1"

same thing for what dodge says, a bit more simple, a new variable tracks the uses(like talking about newcommen and wick burner, can be called burned up states), then changes the rules after was burned up 5 times
or each time you fire up a newcommen, could be like 20% to not burn (gives back the charcoal)
then 80 out of 100 good outcomes which is 16 to 20
then one more try for 50%
then one more try for 50%
that's 95% good and 5% bad outcomes
third bad in a row would break it entirely

Dodge · 2019-05-04 10:26:26

@pein the problem currently is you can only track the number of uses for the same object, for example you can track the number of uses for a hoe because even when you use it it still stays a hoe, but when you use the newcomen pump and fire it it becomes a new object fired pump, pump with water etc, so all the uses reset and you cant keep track of them because it's a different object.

At least that's how i understand it maybe i'm wrong.

Since he wants to make the pump a 1/20 chance to run out of water, it means it has a probability that on the first try it runs out and that could be an issue.

But if he adds a different object or state of the object he can make it so there is a guaranteed number that it will work. Like you run the pump the first time then it turns into "pump first time used with water" then "pump second time used with water" etc

This way he can guarantee to have at least a certain number of times it will work before it has probabilities to run out of water.

He doesn't need an other sprite and i'm pretty sure he doesn't even need a different name for the object as long as the ID of the object is different, so it could be hidden and you dont even know if the probability has started to kick in yet or the number of guaranteed uses.

Last edited by Dodge (2019-05-04 10:27:05)

Sukallinen · 2019-05-04 13:04:38

Morti wrote:

I'm just going to suggest states of decay and leave it at that... well, honestly, I'd rather you make it like a real axe, with a wooden handle and a steel head, where either, the head gets dull and needs to be sharpened, or the handle breaks and needs to be replaced.

Two items within same sprite. If this is installed, my pet idea of just tinting color of brown part of wood-containing object a bit with dying it could be a thing (though haven't checked if all woods has same brown). The tint would stay whatever happens afterwards.

wondible · 2019-05-04 13:08:01

I was reminded of an old discussion, I think Uncle Gus had a system, back before "uses", where tools had a chance to become dull and then during sharpening had a chance to break. You could still break on the first try though.

Might be able to extend this with multiple states. Say, broken, more broken, and totally broken. At each stage, 2/3 chance to fix and 1/3 chance to get more broken (totally broken couldn't be fixed) This gets "more small rolls" to reduce variance, but could still go bad first time.

Could move the uses to a tool. So each time you fix the pump, takes one of five uses from the repair tool. But you could always make more tools, so it doesn't really limit water in the desired way.

Separate thought: This gets a bit hacky, but could the pump be a "container" without ordinary container access, using the container slots to store either water or chances?

Another version of this: load the pump with empty buckets. Running it turns them into full buckets. Now you can use "uses" for the lifetime instead of the water. I guess this also gets hacky because you'd have to have containers that restrict the types of items you can put in, and be able to act on their contents. I think things like this end are currently "with X buckets", which is just cosmetically different than the moss levels.

futurebird · 2019-05-04 13:50:21

You have one variable to store information about the state of the object. If it's a real number you could divide (constant*random multiplier) and if the result is less than the threshold it breaks. By making the initial number large enough you get as may fixed uses as you want.

So, if there is no random multiplier you get predictable results. Start with 16 divide by 2 each time, if the result is <= 2 it breaks.

16
8
4
2 breaks

(4 uses every time)

Add a noise multiplier random number on (.95-1.05) Make that interval larger to make it more random...then divide on each use by the multiplier*2 instead of just 2.

Sukallinen · 2019-05-04 14:22:59

Or make the (pseudo-)random calculation of breakage every (used_times modulo 5 i.e. used%5 i.e. returns true every 5th use) - guarantees those first uses since probability is not calculated every use.

Usually you also don't know how many times item's been used so player wouldn't notice that it can only break every five uses. Also reduces server load since only every fifth use calculates the rng (slow operation).

jasonrohrer · 2019-05-04 15:17:41

Unfortunately, all of these solutions involve some kind of extra counter that will ride with the object.

In the application at hand, that counter is already "occupied" by "7 buckets" or however much water you can remove from the pump well.

Here's a summary of how it works, currently:

1. Build the pump well.

2. Fire the pump well. The result has 5 uses.

3. Hit the pump well with the bucket 5 times, taking one water out each time, decrementing the use counter.

4. On the last use, it becomes a Dry Pump Well 95% of the time, or an Exhausted Well 5% of the time (using a separate system, probability patterns)

5. If Dry, you can return to (2) by loading more water and charcoal coal to fire again.

Here you can see how we'd want a separate "meta" use counter to get tracked in the background, separately from the 5 buckets of water.

It is possible for a use counter to "ride" with an object as it changes over time (like with the shovel and dung shovel). If the new object has the same number of uses, the uses of the old object is preserved.

But here, the number of uses is NOT preserved, because we need to leverage that for emptying the well with some number of buckets.

One way that I can think to get around this is if there's a "mobile tank" object that can hold lots of buckets.... like a washtub on wheels or something. And you have to load this into the pump, and it fills up when you run the pump, and then you remove it and empty buckets out of it as a separate object.

So then the pump itself could track it's overall uses, and not be responsible for tracking the number of buckets removed.

The only other thing that I can think of is a "well sounding rod" or something that you get as soon as you build a pump well. And that sounding rod tracks the meta uses, and you have to use the sounding rod before each firing (with some chance that the sounding rod "tells" you that the well is exhausted). Then the sounding rod could have tiers, and controlled variance.

The problem: where does the sounding rod come from? And how do we prevent people from making multiple sounding rods to "cheat" the well? If the sounding rod is the thing that runs out over time, under the hood, having multiple sounding rods would allow you to get more water out of one well.

(You could also imagine villages stealing each other's sounding rods.... or building wells in the hinterlands and bringing the sounding rods home from those.)

I was thinking that the sounding rod could be magically produced as soon as you finish building the well---it just ends up in your hand as the final step. Almost like the "key" to the well, or something like that. There's huge griefing potential there, obviously.

Also, any of this meta-use-counter stuff for wells (either sounding rod, or engine support for a second counter) prevents us from letting players disassemble wells. If they could do that, and then rebuild the well, they could cheat the use counter by resetting it. I.e., rebuild to reset. And there's no way the use counter is going to be tracked all the way through the rebuilding process....

The_Anabaptist · 2019-05-04 15:18:45

Don't many RPGs purposely use 3D6 to get a bell curve effect? If you roll a 3, then it breaks. If you roll an 18, then you find something awesome in that pile of dung you were scooping!

This tier thing seems rather complicated in comparison.

The_Anabaptist

Sukallinen · 2019-05-04 15:52:43

jasonrohrer wrote:

One way that I can think to get around this is if there's a "mobile tank" object that can hold lots of buckets....

Why have it mobile, can't it be the well-part of apparatus ? It can contain those five, and if you dismantle apparatus, as a result the well-part will be reverted to earlier status, destroy the container and create new (old well) part.

Dodge · 2019-05-04 15:55:23

What was the goal again?

To be sure to have at least a fixed number of times it can be fired without becoming exhausted?

It would work with the system i mentionned in my previous posts

First time you build pump it is a "pump never used" then first time you use it it becomes a "pump used one time" with all the variants like "full water pump used one time" etc then fire a second time it become "pump used two times" with all the variants"

Until you get to the number of times where you want to make it start probability to get exhausted

For example using the bucket on "last water pump used five times" has the 95% and 5% probabilities.

With this system you can control how many times you are sure to get the pump running or any other object used without breaking/exhausting

The name of for example "last water pump used five timed" doesn't have to be visible since it's the ID of the object that counts if i'm not mistaken, so it could be hidden how much times you used the pump or not if you decide otherwise, it could be for example "partially exhausted pump" with the variants

It's like a system of different tiers of the object, it changes the actual object and not the uses of the object each time until the tier that has the actual probabilities to break

Was that not the issue?

Last edited by Dodge (2019-05-04 15:56:25)

Twisted · 2019-05-04 15:59:24

Correct me if I'm wrong but doesn't the newcomen occupy two tiles? I.e. it makes the tile on the right unwalkable. Could the tile on the right be used to count the durability somehow?

Even if they don't occupy two tiles, now that they can only be built on a grid you could make the tile to the right of the natural spring be unwalkable as well, and use that as the durability counter.

jasonrohrer · 2019-05-04 16:10:43

Yes, so what's going on with the 3 D6s?

The EV of each is 3.5. The EV of the sum is the sum of the EVs, or 10.5.

The variance of one D6 is, according to my prob book here,

( (6 - 1) * ( 6 - 1 + 2 ) ) / 12

Or Var = 2.916 (sd=1.71)

The variance of the sum three independent D6s is the sum of the variances, so:

Var( 3 D6 ) = 8.75

In other words, I don't think you're buying yourself anything here. If you want something to happen with a 1/6 chance, you can roll one D6 and look for an outcome of (1). You can also roll three D6s and look for an outcome of one of (3,4,5,6,7,18).

In either case, I think you've actually created a identical random variable with exactly the same properties. You'd expect to repeat the experiment 6 times before hitting your trigger outcome, and the variance would be the same (30).

The bell curve when rolling 3 D6s certainly makes the distribution non-uniform, and is very different from rolling one D18.

The D18 has EV = 9.5

To get a fair compare, let's consider a D16* marked 3 to 18. Then the EV is 10.5, same as the sum of three D6.

Var( D16* ) = 21.25

Which is way higher than the 8.75 we got for three D6.

And the more dice you roll together, the tighter the variance will become, compared to the flat single-die roll with the same range.

But I don't think this variance reduction can be applied in this case, for a single roll to determine whether the pump is exhausted.

The tiered probability system that I described above IS in fact the equivalent to rolling multiple D6s summed (because we're summing how many rolls each tier takes to go on to the next tier, thus reducing the variance).

jasonrohrer · 2019-05-04 16:12:46

Yes, they do occupy two tiles, kinda.... but something else can be to the right there (you just can't walk there).

Currently, the engine treats all tiles independently for transitions, etc... it would be non-trivial to change that.

futurebird · 2019-05-04 16:25:24

Wait, Jason, so the objects don't have a number that stored their current level of damage? If there is no way for the game (when calculating the impact of using a pump) to know if the pump in question is old or new then it is impossible to *guarantee* that it won't break on the first use. No system can do that. You don't have enough information.

So, you need tiers, or a damage variable or something. You can, however, do it with just *one* stored numerical value over 2^n where n is your desired number of guaranteed uses without breaking.

Whatever · 2019-05-04 16:30:24

I think no one here knows exactly how your engine works.

If you want better answers, you need to explain how it works
One tile can store how many different variables? what kind of variables?
Give us examples, how does a basket work? how does the current well work?

Last edited by Whatever (2019-05-04 16:39:51)

Dodge · 2019-05-04 16:35:54

Also can you not just create another counter, one for the bucket uses and one for the probability thing that work separatly?

jasonrohrer · 2019-05-04 16:52:40

Hah... well, there aren't actually any counters in the engine itself. Each map tile stores an object ID, plus some contained item ids. An axe is an axe is an axe. The engine doesn't know about counters of any kind.

So the way "use counts" are built on top of this is that there are auto-generated "used up" axe objects, and auto-generated transitions between them. The actual count numbers aren't stored in the map, or tracked when you pick up an object, or put it in a cart, or any of that.

Instead, what you're actually holding is a unique object ID.... think of it as "Axe Number Five" and "Axe Number Four" and "Axe Number Three" and so on, each with it's own object ID (300, and 2920, 2921, 2922, etc). As far as the engine/map/databas/etc are concerned, these are distinct objects, as distinct as a berry and a hammer.

As you can imagine, "tracking real counters" per object is no small change, because these object IDs move all over the place. Into the player's hand, onto the ground, into containers, into sub-containers, into pockets in the player's clothing, etc. There's a ton of code written that tracks ID movement. It also tracks decay time along with each object. So if a leaf has 45 seconds left until it rots away, that is tracked as you pick it up, pocket it, put it in a basket, put the basket in a cart, etc.

But decay timers were written in from the beginning, to be tracked at all levels (because I knew, of course, that fires would go out).

The "hack" here, which lets me define use counts in the editor, but have "dummy objects" generated automatically at start up, allows "used objects" to work seamlessly with all this existing code, without trying to track a separate counter-per-object everywhere in the code.

So it is not at all simple to just "add another variable per object." There are no variables per object.

And adding a second-layer hack of the same kind, to give us a second use counter, would result in a combinatoric explosion of dummy objects, and also an explosion in code complexity for generating all of these at start-up and handling all the possible cases (that code is already extremely complicated).

Whatever · 2019-05-04 17:01:19

You say "There are no variables per object."
But there is a decay timer for each object? How can containers store items?

Can you not use the decay counter to store the well information?
Can you make it so the object doesnt decay but has a decay counter?

One Hour One Life Forums

#1 2019-05-04 07:03:28

Methods of reducing variance

#2 2019-05-04 07:44:58

Re: Methods of reducing variance

#3 2019-05-04 07:48:10

Re: Methods of reducing variance

#4 2019-05-04 07:54:59

Re: Methods of reducing variance

#5 2019-05-04 08:23:58

Re: Methods of reducing variance

#6 2019-05-04 09:08:07

Re: Methods of reducing variance

#7 2019-05-04 09:11:33

Re: Methods of reducing variance

#8 2019-05-04 09:59:37

Re: Methods of reducing variance

#9 2019-05-04 10:26:26

Re: Methods of reducing variance

#10 2019-05-04 13:04:38

Re: Methods of reducing variance

#11 2019-05-04 13:08:01

Re: Methods of reducing variance

#12 2019-05-04 13:50:21

Re: Methods of reducing variance

#13 2019-05-04 14:22:59

Re: Methods of reducing variance

#14 2019-05-04 15:17:41

Re: Methods of reducing variance

#15 2019-05-04 15:18:45

Re: Methods of reducing variance

#16 2019-05-04 15:52:43

Re: Methods of reducing variance

#17 2019-05-04 15:55:23

Re: Methods of reducing variance

#18 2019-05-04 15:59:24

Re: Methods of reducing variance

#19 2019-05-04 16:10:43

Re: Methods of reducing variance

#20 2019-05-04 16:12:46

Re: Methods of reducing variance

#21 2019-05-04 16:25:24

Re: Methods of reducing variance

#22 2019-05-04 16:30:24

Re: Methods of reducing variance

#23 2019-05-04 16:35:54

Re: Methods of reducing variance

#24 2019-05-04 16:52:40

Re: Methods of reducing variance

#25 2019-05-04 17:01:19

Re: Methods of reducing variance

Board footer