It is great at creating dynamically-changing systems. Flowing liquid is a particularly excellent example. Simulating the spread of lifeforms across a world is another. The spread of fires across a field of fuel is also well suited to CA-driven simulation; both Dwarf Fortress and Minecraft implement interesting (and dangerous) fire spreading behavior.

If designed well, cellular automation takes care of its simulation tasks unobtrusively. You can fairly easily overlay other systems, like a platformer engine, upon the world sim. With a little extra work you could devote the CA process to its own thread, possibly allowing it to be run by its own processor.

Tile-based games are already hosted on a regular, square grid, which naturally suggests a use in cellular automation. In particular, consoles that use hardware tile schemes are well-suited to displaying cellular automation.

Cellular automation is demanding in both processor time and memory. Every "turn" of the simulation performs a calculation on every square of the grid, which must all be kept in memory.

For 3D simulations this can easily add up to big storage requirements. Minecraft handles it by making the "grain" of its grid quite large; each of its blocks is a meter to a side. If you place a block of water so it flows into a long, complicated channel with many forks the control thread is known to stutter while the water flow is calculated (as of ~1.2). Dwarf Fortress requires lengthy loading and saving processes when starting and finishing sessions, and slows down greatly if many fluids are pouring at once.

With careful design and optimization, the amount of processing can often be greatly reduced, but it is an unavoidable fact that CA-driven simulation is interesting because it allows the world to change dynamically, yet the more changes to the world each turn the more processor time it consumes.

CA is great for simulating changes at its grid size and larger. But because of the coarse nature of the grid (if array is going to be small enough to calculate effectively), and the necessary simplicity of the operations performed in each space, true Newtonian physics simulations are not easy to implement.

For example, falling objects are limited in speed to multiples of the world grid size. It may be possible to cheat around this somewhat, but care must be taken. At the moment however, the sight of pouring liquids is novel enough that great fidelity to the letter of real-world physics isn't normally required.

Some care must be taken that the simulation is carried out evenly; that is to say, that the effects earlier portions of a frame-in-progress do not affect the later calculated portions of that frame. The simplest way to iterate through a cellular world is with nested for loops, iterating in sequence through index variables pointing to each cell of the world array in turn.

But if you use the y loop on the outside and have, say, a rock that falls through space, its position lowered by one y value each x loop, the next y loop may find the rock again in its new home, and cause it to fall again unless you take measures to prevent it. The result: a falling rock seems to teleport instantly to the ground! The same problem can occur on each x loop if the contents of some cells move horizontally.

In Life terms, this is akin to the problem of updating the births or deaths in a cell, but placing those changes immediately into the world grid, where they may affect other births or deaths happening that frame. One way to solve it is to keep a separate world grid handy for recording changes, then swap pointers when a world frame is done, but that has the problem of making it difficult to determine, if you have another thread running that could make changes to the world, which frame to modify. It can also be solved by using special placeholder values to represent births and deaths in progress, which are resolved into real population changes as an extra step.

There are other ways to solve the problem too. I am dubbing this the "partial update" problem. In Profundis uses its own, somewhat hacky, solution, which I describe further below.

CA systems can be difficult to design from scratch. If you're intending to implement real-world physics such as fluid simulation it's not so difficult. More complex use, such as in SimCity which uses it for many purposes, can be daunting.

The difficulty of visualizing the large-scale implications of CA rules means that, to find useful or interesting behavior, you are likely going to have to create prototypes to explore the design space. This makes CA design unfriendly to strict product schedules; you may be better off exploring CA rules on your own time and suggesting its use in a project once you already know of a good ruleset.

CA is sometimes unpredictable! That is part of the appeal, but it can also be trying to level designers. This may be why many CA games use procedural or user-generated content.

First, is the space beneath the current cell empty, or part-full of liquid?

If the lower cell contained a wall or other impassible feature, or it now contains a full cell of fluid, check the left or right sides. Do they have room for fluid?

If neither has room, there's nowhere for the fluid to move. We're done.

If only one side is empty, or if the other side has more water than the current one, then we move as much fluid as we can into the emptier side. When we do this, we set a direction flag on that cell, so the next time that cell checks to flow we have a bias direction. This could be considered a flow direction flag. That's important for cases where an odd amount of water wants to flow but must choose between two directions; in the check for direction, the odd unit goes in the bias direction.

This helps water to spread faster, but also gives us a way to have single spaces of water "roam" instead of forming puddles. (There is actually a bug that sometimes prevents this in the current build.) In any case, we find out how much more water is in the current cell than the destination and move half the difference, rounded up.

If both sides have water of lower level than the current one, we attempt to average out the flow so that water levels are the same in all. Ties go to the side in the flow direction, or choose arbitrarily otherwise. We also set each direction's flag.

Unlike the similar "Falling Sand" simulation, In Profundis' system calculates tiles, not pixels. While its systems are much more complex, calculation-wise, than Falling Sand's (mostly because of the possibility of multiple types of fluid being in the same cell), each tile is 24 pixels square, producing a tremendous perceived speed advantage compared to Falling Sand.

In Profundis only simulates the portion of the large, scrolling world that's on-screen at the time, plus a small region just outside its borders. In the testbed it is not often that this aspect of the game world becomes visible.

By running some preliminary cycles over the entire world before the simulation begins, allowing the simulation to find equilibrium as fluids find and fill basins, the illusion can be made more complete. The final game will additionally have limited visibility, which will help to further hide the limited nature of updates of the game world.

The y loop iterates from bottom up. This way, falling objects are only "seen" once per loop, so they don't fall multiple times each world-frame.

There is a "do not calculate" flag on each cell. When the contents of a cell other than the current one changes in a given world-frame, the other cell (the one into which the object is being moved) gets its nocalc flag set. When it turns up in a later iteration, if this flag is seen it is cleared then the loop skipped.

This is not the kludge it may seem at first. If you think about it, when two locations are swapped you are really calculating two locations at once, the object you're moving, and the empty space "object" you're moving into its place. The nocalc flag is effectively a way to prevent the new, now-filled space from getting an extra turn. It's something of a kludge, but it is useful in practice.