Print

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

[HatfieldCW]

Reading the cistern designation thread, I got to thinking about a way to improve and streamline the way water is managed.  It kind of makes sense to me, so I'm going to post it and see how long it takes you guys to find problems with it.

How about if contiguous bodies of water are treated as a single tile with a depth of (area*7)?  Say I have a 10x10 cistern, it could be treated as a body of water that can hold 700 units of water.  So if there are 415 units in there, the thing would have an average depth of 4.15 (maybe rounded for purposes of swimming/drowning/running magma smelters) and apply equal pressure at all points, so a pump wouldn't "dig a hole" in the corner of the reservoir and pump 1 unit per cycle while it's 5 deep six tiles away.  If you breach the wall of the ocean, it would assimilate one tile per some amount of time, so you'd get a tile or three of the usual 1/3/6 depth water, but behind that it would be a solid encroaching wall of water, gushing through the tunnel/hallway/baron's bedchamber.

Ideally, it would eliminate the need to track all those dancing numbers on the surface of an incompletely filled body of water, it would allow waterworks to fill quickly without me watching a long wedge of sludge slooooowly shifting through my carefully arranged series of tubes (or helping it along with a pump or two), and turn breaching an aquifer from an exercise in door-building to the apocalyptic rush of watery Fun that it should probably be.

Problems I see with it are obvious, but hopefully not insurmountable:  From a technical standpoint, it would likely be a pain to code, since the game would have to be able to recognize a contiguous body of water and check frequently to see whether it's been breached.  Hopefully that wouldn't be as CPU-heavy as tracking individual tile depth is right now.  Also, it might become tricky to handle depletion and drying, since a 1/490 would technically still have water in it, but I'd expect that to be dodgeable by just reverting to the per-tile system when it drops below 2/7 of the max depth.  It'd also lead to trouble when using floodgates or bridges to manage flow, since they're always either totally open or totally closed, and the switch would only be able to select between "Off" and "Sweet Armok!" intensities.  I'm not sure how best to deal with that one.

Thoughts?

[Slayer1557]

People would just have to use more complex methods to manage flow, like a pump, or perhaps a series of floodgates (waterlocks), so you only let in the water you want let in.

As cool as this would be, implementing it seems difficult.  And from the way you wanted to handle low-depth pools, having it revert to tiles just defeats the purpose of trying to find a better method in the first place.  It would have to handle both the tile version and the 'flow' version.  It just seems impractical.

[Thanshin]

The current system is amazingly good in its simplicity.

Its tiny flaws are more visible because we actively look for and exploit them.

If you make a system that's closer to reality, you'll spend more processor time and we will still eventually find exploitable flaws that show off its imperfections.

That can go on until you reach a flawless real fluid simulation, which won't happen.

[Silverionmox]

If you look how many ponds are now sucking up cpu cycles, just because someone took a bucket of water from them last year, this would really be an improvement. As soon as a body of water has settled (i.e. the quantity of water in it stays the same and only differs 1 between the lowest and the highest height) then we can calculate the average, store it and the usual fluid mechanics only need to be reactivated for that body of water when something drastic happens, e.g. mining out a square nearby or dropping a bronze colossus in it. Drying up just decreases the average until only non-contiguous puddles are left (i.e. average height < 1).

Water height and movement

[Thanshin]

If you look how many ponds are now sucking up cpu cycles, just because someone took a bucket of water from them last year, this would really be an improvement. As soon as a body of water has settled (i.e. the quantity of water in it stays the same and only differs 1 between the lowest and the highest height) then we can calculate the average, store it and the usual fluid mechanics only need to be reactivated for that body of water when something drastic happens

So what you propose is to calculate the heights of each cell as it's being done now, and then calculate the average to all connected cells before applying the effects (a dwarf drowning or not, for example).

I see the idea and it does seem reasonable. Now let's look for possible glitches:

- How does the system calculate connected?
This algorithm (the simple colorfill), is trivial for a human mind and historically costly for a computer.

- How does the system "sees" there's been a change?
The algorithm to check whether the removal of a water cell (by pump, cave in or whatever other means) implies a recalculation of the connected water cells map.

- How often would the system have to run both algorithms?
The "check if there's been a change" every single turn. The "remap connected water cells" everytime the first one returns true.

[qoonpooka]

- How often would the system have to run both algorithms?
The "check if there's been a change" every single turn. The "remap connected water cells" everytime the first one returns true.

Actually, you wouldn't need to check every turn.  "Damp" wall tiles could have associated pointer flags which identified which body of water they were a part of.  When a damp tile was mined out, a specific function could be activated on that body of water, rather than checking every single body of water.  In fact, if you set it up right, you'd only have to 'check if there's been a change' when you perform something that would actually cause a change.   Maybe every ten thousand steps or so you run a quick global sweep to make sure you didn't miss anything (and return a debug message if you did).

This makes bodies of water handled more like entities rather than fluids or terrain, which may introduce its own problems.  Also, to be fair, I like the extra levels of water sliding around on the surface, it gives the appearance of natural waves, to me.

[Silverionmox]

If you look how many ponds are now sucking up cpu cycles, just because someone took a bucket of water from them last year, this would really be an improvement. As soon as a body of water has settled (i.e. the quantity of water in it stays the same and only differs 1 between the lowest and the highest height) then we can calculate the average, store it and the usual fluid mechanics only need to be reactivated for that body of water when something drastic happens

So what you propose is to calculate the heights of each cell as it's being done now, and then calculate the average to all connected cells before applying the effects (a dwarf drowning or not, for example).

I see the idea and it does seem reasonable. Now let's look for possible glitches:

- How does the system calculate connected?
This algorithm (the simple colorfill), is trivial for a human mind and historically costly for a computer.

- How does the system "sees" there's been a change?
The algorithm to check whether the removal of a water cell (by pump, cave in or whatever other means) implies a recalculation of the connected water cells map.

- How often would the system have to run both algorithms?
The "check if there's been a change" every single turn. The "remap connected water cells" everytime the first one returns true.

- calculate connected: That information is already available, because of pathfinding's need for connectivity maps.
- change: a limited number of actions would necessitate a check (digging would; taking out a bucket of water would not).
- how often: almost never for the average pond. All the time for players who build a pool with waterslides.

qoonpooka, it would be possible to delay the settling of the water for a time after it has reached a maximum difference of 1 in height. Although ponds and moats are just too small to have more than ripples anyway, it might be appropriate for lakes.

[alfie275]

Wouldn't this greatly increase the memory requirements? Currently fluids could be done with one byte per tile (I'm just guessing since noone has access to the source apart from toady, but guess from the fact that it only has 8 states would indicate that it is using 3 bits for the fluid level and 1 bit for the fluid type) but this system would require upto maybe 4 bytes for each seperate water body, and if you had single tile water bodies that weren't connected, such as rain, then this would vastly increase the memory costs.

Another idea for increasing performance would be to multicore the water code and split the map into however many cores the computer has and do those parts one per core.

[HatfieldCW]

Using multiple cores would be nice, but I doubt we'll see that in a hurry.  Maybe after toady makes his first few million, he'll hire a team of codemonkeys to shine up the game.

I wasn't thinking that this would become the sole method of tracking water levels, the per-tile system would be better in some cases.  But in an unbreached murky pool, a smoothed and engraved 50-tile cistern, the surface of a subterranean lake, etc. the constant boundaries and volume would lend themselves to this method, and if the volume will be changing without the shape of the reservoir changing, via screw pumps, floodgates or whatever, a unified volume value would be a more elegant and reliable way to handle that.

[Silverionmox]

Wouldn't this greatly increase the memory requirements? Currently fluids could be done with one byte per tile (I'm just guessing since noone has access to the source apart from toady, but guess from the fact that it only has 8 states would indicate that it is using 3 bits for the fluid level and 1 bit for the fluid type) but this system would require upto maybe 4 bytes for each seperate water body, and if you had single tile water bodies that weren't connected, such as rain, then this would vastly increase the memory costs.

Another idea for increasing performance would be to multicore the water code and split the map into however many cores the computer has and do those parts one per core.

Memory is less of a bottleneck than cpu speed. Anyway, the data already exists in the form of connectivity maps that are being tracked for pathfinding.

[eerr]

"This algorithm (the simple colorfill), is trivial for a human mind and historically costly for a computer."

Human's have some multithreading power. The eyeball nerves operate in tandem with the other parts of the brain. Also, I assert that the brain uses a piped algorithm.