In Profundis design (12/30)

So, here is how tools that have a visible extent in the game world should work. Maybe someone can suggest something if they spot a potential pitfall. This is the system used for ropes and spanners, and will probably be extended for other things.

The tool itself exists in one cell of the world. That cell "is" the tool for purposes of recollecting and destroying. A rope hanging from a piton "is" the cell containing the combined object. Spannners, portable, extendable platforms (not what are sometimes called wrenches -- maybe I should find a better name) have a central point from which they extend, and that point "is" the spanner. Make sense?

Once placed, "shadow" objects get placed through the CA system. I call them shadows because they are "cast" by the primary objects, but to the CA they can still have interactions.

On the primary object's turn, it checks in the spread directions (down for rope, left and right for spannners) and sees if it's empty and suitable for spreading. If so, it places the appropriate object (rope tile, extended platform for spannners) in the place. It also sets a "strength" value on the tool.

When a shadow object's turn comes up, it first checks in the direction to grew from, to see if a matching source object or stronger matching shadow object is there. If it is, and has a strength greater than 1, it tries to spread itself, and if it can produces a clone of itself at one point less strength. If for some reason it doesn't have a matching object, it removes itself from the game world, the "source of the shadow" has gone away, it isn't casting anymore.

Advantages to this system:
- Quick. The processing required for each cell remains light. While tools will probably not become very common objects in the game world, it's important that, if the player were for some reason to buy lots of them and string rope everywhere, the game engine could handle it. This avoids a particular Minecraft problem; there, liquid is handled in a similar source-and-shadow manner, but when a source tile is removed, on slower systems the computer becomes very laggy for a while, while dependent fluids are recalculated. (When I shut off or on the water flow in my multi-story mob grinder, which has many forks, long cascades of liquid, and collecting streams at the bottom leading to the output trough, it's several seconds before I can do anything else.)
- Self-correcting. Every shadow object checks for a source every turn; if the source disappears for some unexpected reason, it does to, and so thus do objects that depend on it.
- Fun to watch. Multi-tile objects don't appear instantly, but over a short period of time as the shadows propagate through he world.
- Has a certain elegance.
- Respects 'c', which is important for avoiding subtle CA calculation problems. 'c', or the "speed of light," is a bit of cellular automation jargon -- it refers to the maximum rate at which changes may propagate through the system. In Profundis' speed of light is one tile/frame. At the moment, no tile can affect the game world more than one immediate space in each direction. If placing a rope instantly placed all the rope tiles into the world, it would break the speed of light. Currently, In Profundis calculates its world in a square spiral pattern emitting from the player's location, skipping every other square, but starting on an even or odd square in successive turns. The result is that a checkerboard-like layout of tiles is calculated every turn. Since no tile can produce and effect that extends out further than one tile orthogonality, we can be sure that changes aren't propagated too fast, producing results like instantly-falling water. This doesn't matter so much for example tools, but might be important for other tools later.

Disadvantages:
- Inherently tile-based. I was worried before about the game's strict grid-based presentation; I've brainstormed ways to effectively implement sloped rock tiles that still handle water effectively for instance. I've spent too long trying to figure that one out however. The project has gone on long enough, and I think now I'm not going to worry about the limitations of the grid-based CA. It certainly hasn't hurt Minecraft any.
- May result in circular, self-dependent shadow objects if those objects aren't designed well. Could a situation arises where multiple-placed primary objects interact in a way that a self-reinforcing system of shadows could set up? Not in the simple situations I have described, I think, but more complex objects might have branching shadows, and if somehow a shadow object can produce another shadow of greater strength than itself this situation could arise, where all sourcing primary objects could be removed but surviving shadows keep each other refreshed.
- Has a certain lack of realism. Imagine a case where a spanner platform extends several cells out into the air, and a boulder falls through the middle of it. When it falls through the platform (spanners aren't strong enough to support such weight) the next platform over will no longer have a source, and will vanish the next frame. But the boulder will then continue to fall, and so the spanner it destroyed will be recast the next frame. The result is a one-tile gap that moves down the spanner like a wave, a behavior that isn't mirrored in real life. Similarly, what if gravity affects spanner sources? If the source is unsupported, it will effectively create a V-shaped platform shadow through the world as it falls, as it created new platforms around it as it descends, while those left behind it by its fall both spread and disappear outward through the route from where the spanner passed.

Still though, I think the mechanism solves more problems than it causes, especially if I keep tool designs under control, and it may be applicable to simulating non-tool objects as well. Remember, it's always best to keep CA effects as simple as possible; the more work you do on each cell, the more likely the whole simulation may, in some situations, start to drag.