Interview: The Making Of Dwarf Fortress

Fluid dynamics is one of those features that, to look at it, one can't help but wonder, how on earth did he do that? I think the answer to that question would be of great interest to the authors of falling sand game clones.

(Ed's note: We're talking about the most recent versions of Dwarf Fortress, that use a three-dimensioned cellular automation system to manipulate water, much like a multi-plane version of falling sand. In it, each space is a cube that can contain from 0 to 7 levels of water. A "1" is the smallest amount of water possible in the game, and a "7" space is full of water.)

TA: I think the falling sand games are more impressive than my stuff. I've got kind of a bare-bones system. The only thing impressive about it is probably that it runs at all while everything else is going on.

It's really not that complicated, just a specialized cellular automata.

TA: Neither is mine, he he. Mine isn't much more than that. Water falls down if it can, over if it can. The pressure is a bit interesting, I guess, since that isn't a local operation. There's probably a local model for pressure, but the ones I've seen wouldn't work for me, I think.

Pressure is the thing I'm personally interested in seeing explained.

TA: The main problem was at waterfalls. The water would fall on to the river below, and just start clumping, forming a pyramid. This is because of the local behavior. It can't go down, so it goes over.

Ah, I see. So the water is flowing out, but too slowly.

TA: You get a slope that naturally forms. And the hard part is that you really can't have any artifacts at all, it really has to just look like a river. Anything unusual is bad, it can't do any pre-calcs based on the map, because the fluid system has to work with water the player throws at it.

The water in the falling sand games I've played with does something similar when a great amount of water lands in an area, it tends to sort of pile up and takes quite a while to settle down to an even level.

TA: This example was in a canyon or a cave river. If you are out in the open, it'll overflow the banks, which is also terrible. The cave river is the case where I started, the water is completely contained, but it still has to look normal. I did solve the problem, it doesn't do this anymore, but there are probably a ton of solutions. The way I did it, I can also model pressure, but it's a bit expensive.

What'd you end up doing?

TA: Let's say you have a U shaped tube, and the left half and bottom are full. This should not be a static situation.

Yes, in the falling sand model, water won't rise up the right-hand side.

TA: The nice thing about this is that I'm not dealing with a ton of small particles, but large tiles, so I can afford some pretty cludgy operations. From the local perspective, let's say it is the turn of the water at the top left to move. It can't flow anywhere, and it can't flow down, so it checks the square below. If it is marked "static," it stops. If it isn't marked "static", it'll start doing a flood-fill check downward, through full water spaces, never rising higher than its own level until it finds an open slot.

If it finds one, it teleports there. Otherwise it marks the square below as "static" to avoid a recalc. If the situation ever changes (like water is removed) it can just remove the static flags. It seems like it would be pricey but it's really pretty fast, and doesn't account for very much of the lag on computers having problems. This also happens at waterfalls.

The recalc elimination aspect helps keep it fast.

TA: Yeah, without the recalc elimination it would be impossible at the waterfall. Incidentally, I turned this off for magma on purpose, so it's all clumpy.