The three options for fixing the variance on pump exhaustion

Dantox · 2019-05-07 23:17:32

2 looks great

Spoonwood · 2019-05-07 23:34:54

Twisted wrote:

I'm not sure if I'm getting your point here - you do realize that OHOL is primarily a multiplayer online game, right? You can't pause those.

Yes, I understand that. However, time pressure with many tasks isn't all that intense. Farming doesn't need to get done super fast, for example, neither does sheep tending. Even people who aren't all that inefficient cooking usually do well enough. Players can do those jobs slower, but perhaps smarter. The game comes as forgiving in that respect, one might say. Smithing has several inefficiencies time wise that I see... for example the person who lights the forge just to make a knife and leaves the iron sitting there without trying to get any of it processed. Smithing though, I think the most unforgiving with respect to inefficiency. What I'm saying is that the game doesn't need more tasks that need done quickly or to the best possible level (it's rare that such happens from what I've observed really, and I'm not excluding myself from that either). It doesn't need the pressure of a rush to maximize water output. And here's the kicker to my point. The system to get as much water from a pump as quickly as possible implies cisterns clustered around the well. Other spots around town might use a cistern bad, so city design ends up worse off with the 'run to unload water from the pump' system. Or people will need to use a mining pick on cisterns once they get empty. And I don't like the sound of that.

Cisterns can be good. But cistern clusters, which idea 2 would lead to, wouldn't be good.

Last edited by Spoonwood (2019-05-07 23:36:37)

wio · 2019-05-07 23:37:34

If I'm the one that triggered the probability explanation, then I apologize. I should have explained that I actually have a pretty decent understanding of probability, and most of the stuff explained was already clear to me. What is unclear was what exactly you want the expected value and variance to be as well as what other restrictions you want. I figure you would be able to find the correct use count (n) and use probability (p) on your own. The only downside I see to negative binomial distribution is that it imposes n-1 minimum uses, when you might prefer more or fewer minimum uses.

Options 1 and 2 have little to do with probability and are more about pump transparency. They let villagers determine how much water is left. These solutions confuse me, because they seem to be addressing another goal entirely.

Your last comment is about how you don't want useage to be conflated with age. In that case, you could have a delay timer transition the pump through various tiers, with later tiers having a higher probability of being exhausted. Usage could also have a probability of changing the tier as well, to create a "wear and tear" effect. I don't mind doing some math for you if I got more specific parameters. Markov chains are helpful for solving problems regarding probabilistic finite automata.

Perhaps what's going on is that you've already solved the probability aspect of it, and now you're just trying to solve the transparency aspect, enabling towns to make informed decisions regarding when to upgrade the pump?

jasonrohrer · 2019-05-07 23:55:28

Yeah wio, I see the confusion.

Each object can only have one set of "tiers" in the current engine.

The existing pumps use "tiers" to track "buckets left after the most recent pumping." In game, you can see the moss on the rocks disappear as each tier is used up. There is a 1/1 chance of going down to the next tier after each bucket is removed. So there's a fixed, known amount of water after each run of the pump.

Tiers, combined with a chance of transitioning between tiers, is currently how variance is reduced on multi-use tools like axes. The axe has four tiers, and there's a 1/25 chance of transitioning to the next tier (each tier has more cracks that show up on the axe). The axe has 100 expected used before breaking, but much lower variance than just rolling a D100 with each chop. And yes, n-1 minimum uses (four, in this case).

Pump exhaustion is handled by a single 1/20 prob roll when the last bucket is removed after a pumping. Thus, it's not tiered, and has very high variance, which is bad.

This is a limitation of the engine, in that it can't track "nested tiers" for a single object. Tiers are used to track buckets left in the basin, so another set of tiers can't be tracked for the overall life of the pump.

We currently have something like this:

dry pump
firing pump
wet pump# 7 buckets
wet pump# 6 buckets
wet pump# 5 buckets
wet pump# 4 buckets
wet pump# 3 buckets
wet pump# 2 buckets
wet pump# 1 buckets
dry pump (19/20) | exhausted pump (1/20)

What we want (not supported by the engine, and really hard to add) is:

Dry Pump# Age 1
Firing Pump# Age 1
wet pump# Age 1 # 7 buckets
wet pump# Age 1  # 6 buckets
wet pump# Age 1  # 5 buckets
wet pump# Age 1  # 4 buckets
wet pump# Age 1  # 3 buckets
wet pump# Age 1  # 2 buckets
wet pump# Age 1  # 1 buckets
dry pump  Age 1 (4/5)  | dry pump Age 2 (1/5)

Dry Pump# Age 2
Firing Pump# Age 2
wet pump# Age 2 # 7 buckets
wet pump# Age 2  # 6 buckets
wet pump# Age 2  # 5 buckets
wet pump# Age 2  # 4 buckets
wet pump# Age 2  # 3 buckets
wet pump# Age 2  # 2 buckets
wet pump# Age 2  # 1 buckets
dry pump  Age 2 (4/5)  | dry pump Age 3 (1/5)

Dry Pump# Age 3
Firing Pump# Age 3
wet pump# Age 3 # 7 buckets
wet pump# Age 3  # 6 buckets
wet pump# Age 3  # 5 buckets
wet pump# Age 3  # 4 buckets
wet pump# Age 3  # 3 buckets
wet pump# Age 3  # 2 buckets
wet pump# Age 3  # 1 buckets
dry pump  Age 3 (4/5)  | dry pump Age 4 (1/5)

Dry Pump# Age 4
Firing Pump# Age 4
wet pump# Age 4 # 7 buckets
wet pump# Age 4  # 6 buckets
wet pump# Age 4  # 5 buckets
wet pump# Age 4  # 4 buckets
wet pump# Age 4  # 3 buckets
wet pump# Age 4  # 2 buckets
wet pump# Age 4  # 1 buckets
dry pump  Age 4 (4/5)  | exhausted pump (1/5)

You can see the combinatoric explosion that results from having nested tiers like this. The way tiers are implemented in the game is with generated "dummy" objects and generated transitions. Thus, these kinds of explosions are bad. We currently have 10 objects representing the various stages of each pump. With nested tiers, there would be 40.

All three solutions are an attempt to get "tiers" somewhere else, other than the pump itself, so that we can track overall pump life in a lower-variance way. The sounding rod keeps the tiers in the rod itself (a separate object).

The barrel and the "milking contest" remove the need to track "how many buckets left" in the pump after a pumping. There's one barrel of water removed, or infinite water available during a limited time. Thus, we could then use tiers to track overall pump lifetime. Imagine four tiers of pump age, with a 1/5 chance of moving down to the next tier after each pumping. Still 20 pumpings expected, but way less variance.

Thus, the discussion is not about tweaking probability, or making the pump easier to understand for players...

But instead about a work-around for an engine that can only handle one set of tiers per object.

AstroTitan · 2019-05-08 01:16:49

Dodge wrote:

In case this ends in a draw, why not both?

wio wrote:

Options 1 and 2 have little to do with probability and are more about pump transparency. They let villagers determine how much water is left. These solutions confuse me, because they seem to be addressing another goal entirely.

I agree. What if a Diesel Pump could fill a Water Cart or Buckets and a Kerosene/Charcoal Pumps could only be emptied with a Bucket. All run for a set duration that increases with tech level and all give unlimited water whilst running, with a chance of breaking on going dry/shutting down. Water Cart could only directly and completely fill an Empty Cistern. I think this would require the fewest new assets and changes to existing transitions, and keeps the learning curve lower. The water cart can absolutely be a part of a later update too if time doesn't allow, the only critical piece at this point is unlimited water for a set duration and a probability based counter to determine exhaustion status.

wio · 2019-05-08 01:48:50

I see. You want to avoid creating too many objects, but the nature of the goal requires many states.

Rather than having k objects representing k states, you can have n+m objects representing n*m states by using two separate objects (pump/barrel + rod). That is definitely clever. Option one and two essentially do this. Option three just simplifies the state space by replacing sub-states with timed free for all.

With all of that being said, option 1 seems to be closest to what you want, where as option 2 is a more convenient version of it.

Have you considered getting rid of fixed bucket counts per firing, and instead making them probabilistic?

dry pump# Age n
firing pump# Age n
wet pump# Age n
wet pump# Age n -> wet pump# Age n (6/7) | dry pump# Age n+1 (1/7)
firing pump# Age n -> wet pump# Age n (4/5) | wet pump# Age n+1 (1/5) (except when n = 5)
dry pump# Age 5 = exhausted pump

Since firing technically has more states than explicitly written, I can see how this still would result in a lot of objects. It's still n * m, but I've made m smaller by 6 objects by getting rid of bucket counting. Another downside is that minimum uses goes down to 4.

Last edited by wio (2019-05-08 01:50:39)

jasonrohrer · 2019-05-08 02:30:23

Well, to do that, what wondible called "flipping it", the pump itself would have tiers representing its lifespan, and then after each pumping, you'd get a random number of buckets out of it.

I.e., Upon firing, it would have a 1/5 chance of growing older (across four tiers of age, until it finally broke). Then after firing, you'd pull buckets from it, with a 1/7 chance of it going dry after each bucket pull. So that shifts the high variance from "How long will this pump last" to "How many buckets will I get out of this particular pumping."

There's still high variance there, though... one out of seven pumpings would only give you one bucket, which would be frustrating.

pein · 2019-05-09 05:02:58

what about the animal movement idea they said? you could actually attach a real animal on it like an ox, then would move each time when the newcommen is fired up
after 2 turns of 9 tiles around the newcommen it could go old and die

One Hour One Life Forums

#26 2019-05-07 23:17:32

Re: The three options for fixing the variance on pump exhaustion

#27 2019-05-07 23:34:54

Re: The three options for fixing the variance on pump exhaustion

#28 2019-05-07 23:37:34

Re: The three options for fixing the variance on pump exhaustion

#29 2019-05-07 23:55:28

Re: The three options for fixing the variance on pump exhaustion

#30 2019-05-08 01:16:49

Re: The three options for fixing the variance on pump exhaustion

#31 2019-05-08 01:48:50

Re: The three options for fixing the variance on pump exhaustion

#32 2019-05-08 02:30:23

Re: The three options for fixing the variance on pump exhaustion

#33 2019-05-09 05:02:58

Re: The three options for fixing the variance on pump exhaustion

Board footer