Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Sizik]

I was think about fluid flow, and how a pool of water with a mixture of 3s and 4s would be constantly in motion since the 4s move around a lot. This got me thinking about how to better represent an amount of water not evenly divisible by the space it takes up. I considered "hiding" the extra, by having it all shown as all 3s or all 4s, but that would be complicated to implement. Then I realized, why not have the 4s evaporate to 3s? I then came up with this (not counting for evaporation of pools on a hot day):

Old (current) rule for evaporation:
- 1/7 water has a certain chance each frame to evaporate (I assume)

New rule for evaporation:
- Any tile of water has x(t-n)/t chance to lose 1 unit of water, where x is the chance for 1/7 evaporating above, t is the total number of open tiles surrounding that tile, and n is the number of open tiles containing the same amount of water or greater.

This way, water pools with a mixture of say 3 and 4 units of water will settle down to all 3 water. Also, it would be possible to have a pool filled with 1/7 water, as since all tiles would be surrounded by either more 1/7 water or walls.

[Sizik]

Bump, since I am reusing a post from July.

[penguinofhonor]

Huh, this would cut down on some unnecessary flows.

[Draco18s]

How did I not see this in July?  What an ingenious idea!

[Sizik]

How did I not see this in July?  What an ingenious idea!

It was a (not very) different thread in July.

[RAM]

I like what this might do for framerates!

[MrLobster]

You can get the same desired effect with a rule like:

* When flow occurs, there's a Z% chance that 1 depth of water evaporates.

I imagine that's going to be faster to compute, too. You'd keep the evaporation rules for 1/1 water (personally I don't want irrigated rooms to stabilize at 1/1, anyway).

This also avoids an oddity of the (t-n)/t formula, where a 5x5 reservoir evaporates faster than a 25x1 reservoir. Though you still get the odd effect that enlarging a giant 7/7 reservoir by one square will drop the entire thing to 6/7.

[Silverionmox]

Stabilizing the waves could also be done by calculating the average for a given body of water and storing that for all tiles of that body of water. Whenever the specific depth of a tile is needed and the average doesn't suffice, a random integer could be generated (eg. 6,33 would give 1/3 chance for a 6 and 2/3 chance for seven). Pro: matter conservation. Contra: need to store bodies of water and average depth in memory.

The OP's post is much more elegant of course, though with the disadvantage of making it possible to evaporate a lake that almost fills a map by digging seven tiles along the edges, with the right timing.

[Bricks]

Even better, why not track atmospheric moisture (if the game doesn't already), and then base chance to evaporate on temperature and moisture?  Water should technically be evaporating all the time unless you are in a rainforest (or in a particularly humid cave), so any stack of water should have a chance to evaporate, not just the lone tiles.

It's the most realistic model and shouldn't be too hard to implement, considering the amount of available psychrometric data.  I think the game already does some of this anyway.  The "sloshiness" of the current fluid system is kind of annoying psychologically, but the only non-lossy solution would be to divide water up into smaller and smaller pieces.  Another method would be to actually have a chance to add a bit of water if the current tile is on average lower than its surroundings, which would be even weirder but would eliminate the "catastrophic evaporation" scenario.  A method that doesn't check neighboring tiles would be faster, too.

If the concern is the graphical display of the sloshy tiles, I think it would be better to leave that bear alone.  Other water features have problems that a new evaporation model wouldn't fix.

[RAM]

Or you could declare each connected field of water with a depth of 2 or greater as a unique entity and store excess water as an integer, every time the water level drops it is replaced from the stack until the stack is empty...

[Geb]

I'm not too happy with the idea of losing an entire layer of water from a pool just because you remove one bucketful. It would be nice if there was a balancing effect that condenses some extra water to fill in gaps if a pool is almost-but-not-quite full enough to be uniform depth.

[Bricks]

I'm not too happy with the idea of losing an entire layer of water from a pool just because you remove one bucketful. It would be nice if there was a balancing effect that condenses some extra water to fill in gaps if a pool is almost-but-not-quite full enough to be uniform depth.

My probably too long and confusing post did mention this.  Without writing out an actual equation, imagine the following.  You look at a given tile and count up the number of empty and full tiles, like OP mentioned.  Then, find either 1) the average height of these tiles or 2) count up the number of tiles above and below the target tile's height.  Either works, and since the difference is unlikely to be more than 1/7, method 2 probably makes the most sense.  If the average height of the surrounding tiles is greater than the current tile's height, the game should actually have a chance to condense a bit of water.  In the original case, where the tile was higher than the surroundings, there would instead be a chance to evaporate.  If you did happen to have a body of water that was, say, mostly 4/7 with a few 3/7 bits, the 3/7 should fill up faster than the 4/7 would evaporate, and the pool would eventually all be 4/7 (or close enough, since there would be other things causing the water to leave the pool).