Game Development Reference
In-Depth Information
How it works...
The beauty of cellular automata is the simplicity with which they work. Each cell has a
very basic set of rules. In this example, each cell wants to even out the water level with a
neighboring cell. As we go through iteration, the water moves downhill.
It's usually fairly easy to get the automation up and running, but it can take a while to get
everything right. For example, even if each cell's amount is updated correctly, we will get
weird oscillating water effects if the flow's direction doesn't work correctly. The reason is
that there would be a preferred direction the water will take in a new cell. This direction
might be the opposite of where it came from, making it want to move back to the cell it
came from. Picking a random direction might work in that case, but it makes it more diffi-
cult to predict the behavior. This is why we use the direction of the water in the cell it came
from. Naturally, the water will have some momentum and will continue to flow until it is
stopped.
One thing that can be tricky to grasp at first is the reason why we don't update the water
amount directly. The reason is that if water moves from cell x to cell x+1, that water would
instantly become available for x+1 once the
update
method reaches there; also, it could
be moved to x+2 and so on. We can't think of the water as real time, and that's why we first
perform an outgoing operation on all the cells before we apply the incoming water. We also
don't change the amount in the cell we're currently checking for the same reason. Instead,
we move any water left in a cell to the
incomingWater
field.
The main challenge with the method is usually related to performance. Calculating can be
expensive and rendering even more so. With a system like this, it's ever-changing and we
might be forced to recreate the mesh in every frame. Rendering each cell on its own
quickly becomes impossible, and we must use batching to create a single mesh. Even this is
not enough, and in this example, we store the cell's
geometry
field so we don't have to
recreate it unless the water level is 0 in a cell. We also scale the cell's
geometry
field if
the water level changes as this is much quicker than creating a new
Mesh
class for it. The
drawback is the additional memory that is used by storing it.
We also made it optional to update the water in every frame. By lowering it to a set amount
of updates every second (in practice, its own frame rate), we could severely lessen the im-
pact of the performance. This could also be taken further by only updating parts of the wa-
ter field with every update, but efforts must be taken to conserve the amount of the water.
