Agents walk at random on a 3D lattice and deposit one of two brick types whenever the 26 cells around them match a stimulating configuration in a shared lookup table. No agent knows the plan; coordination comes only from the structure being built. Based on Theraulaz and Bonabeau, Science 269 (1995) and J. Theor. Biol. 177 (1995), and Bonabeau, Guérin, Snyers, Kuntz and Theraulaz, BioSystems 56 (2000).
The lattice is 20 × 20 × 20 cells with 10 agents, as in the papers. One brick of type 1 starts the nest near the top; the nests hang from it and grow downward. At each step every agent moves to a random free face neighbor, then reads the 26 surrounding cells. If that configuration is in the table, it deposits the brick the table names. Bricks are never removed. The tables list each configuration once; rotations about the vertical axis and reflections are also stimulating, as stated in the appendix of the J. Theor. Biol. paper.
Coordinated algorithms. The papers' main result is that coherent architectures need tables whose stimulating configurations fall into successive building stages that do not overlap: finishing one stage creates the configurations of the next, and no configuration of a later stage appears early. The stage panel shows this for the Chartergus table: stages fire in order. A random table, by contrast, grows a structureless shape that differs from run to run.
The papers built their architectures by working backwards from the shape to the rule table. These tables were obtained the same way, automatically. For each architecture I specified a target: which cells hold which brick type. A learner then ran the swarm with the current table. When the swarm had stalled, and an agent stood at a target cell on the growth front, the configuration it saw became a new rule. Whenever a rule in the table matched at a cell outside the target, or asked for the wrong type, that configuration was banned for good: this is the overlap between building stages that the papers show disorganizes construction. Learning stopped after 20 runs with no change. Each table was then tested in 20 independent runs of the plain swarm, and the best of several learning attempts was kept. The tables are explicit, without symmetric variants, so they list more rules than the published ones.
Not every architecture could be specified from the figures, which show only finished shapes, so the targets are my reading of them, designed so that local cues can tell building stages apart. Where the brick types differ from the figures, it is because that is what made the stages distinguishable.
The helices. These needed three changes from the first attempts. The roof is grown in the plane of the starting brick and bounded by the pillar below it, instead of being a separate stage that the envelope later mimics. The ramp's starting sector is not prescribed: the first ring cell the swarm deposits under the roof fixes the phase, and the learner accepts every rotation of the target. And the brick types are assigned so that no two stages share a configuration: with pillar, walls and ramp all of one type, a wall cell under a wall with the ramp beside it looks exactly like an interior cell under the ramp with the pillar beside it. On the cubic lattice the pillar and walls are type 1 and the ramp type 2; on the hexagonal lattice the rim and walls must be type 2, because there a cell outside the rim touches only one rim brick and would otherwise look like the first inner-ring cell.
Not reproduced. I could not obtain working tables for JTB Fig. 4(k) and BioSystems Fig. 2(c) (Chartergus-like envelopes with regularly spaced combs) or JTB Fig. 4(p). In each case the second deposit of the nest (a rim brick beside the center, diagonally below the starting brick) sees a configuration with one type 2 brick beside it and one type 1 brick diagonally above. With two brick types and a single starting brick, the envelopes I designed contain a type 1 brick directly above a type 2 brick, so that same configuration occurs next to the wall while the structure is partly built. Alternating the envelope's types by level, which is what spaces the combs, creates such pairs unavoidably. Banning the configuration then stops the nest at its second brick. The published Chartergus table avoids strict comb spacing (its combs are spaced irregularly) and, as noted above, completes the full nest in only about one run in ten. JTB Fig. 4(p) needs three locally distinguishable kinds of comb (the first one, left-leg combs and right-leg combs), and every typing I tried either repeated the starting brick's configuration or made two kinds look alike.
Each playground is one algorithm: a variable-length list of micro-rules (genes), each pairing a stimulating configuration with the brick to deposit. Rules are explicit, without automatic symmetric variants. It is simulated as in the BioSystems paper: 10 agents on a 16 × 16 × 16 lattice, stopping at 500 bricks or 30,000 steps. Click the architectures you find most structured, then press Breed. Selected algorithms are kept; with one selected, the others are its mutants; with two or more, each new algorithm is a crossover of two selected parents followed by mutation.
Mutation. Every gene of an offspring is replaced by a random micro-rule with probability p1 = 0.9 if it was never used in the parent's simulation, and p2 = 0.01 if it was, so rules that build are kept and dormant ones are recycled. Crossover. Two-point crossover cuts both parents at two random points and swaps the middle segments. Modular crossover splits each parent's active rules into two equal halves with few consecutive activations across the halves, and passes whole halves on together, so that co-dependent rules stay together.
Fitness F = k · F11/3 · F2 · F3 · F41/3 is computed on the construction graph, which has one node per brick and an edge from every earlier brick in the neighborhood of each new one. F1 is the fraction of rules used, F2 the number of edges per node, F3 is 0.2 times the mean size of the patterns found in the graph, and F4 measures how often patterns repeat, from 100 random pairs compared under translations and rotations about z. It is shown under each playground as a guide, and drives selection in auto-evolve.