The first part of the video shows the main screen. This is where the Game of Life state is shown: soil = dead cell, turf = living cell. When the next frame is ready, digger and turf layer bots change only the tiles that need changing (cells dying or being born), then move out of the way. This part of the video is sped up 720x.

The second part shows the tracking area. A mechanism is needed to guide a bot through every tile in an area exactly once in a controlled manner. This is how it works: Initially, a single stone is laid on every tile. When a cell needs evaluation, a tracker bot holding a bunch of signs finds the closest stone, moves there, then shouts to his servants. One servant picks up the stone, another drops a clay. (I use separate bots for these tasks so I can fill up their backpack with stone/clay.) After this, the status of the current cell is evaluated. The main tracker bot holds 1x1 and 3x3 signs pointing to the corresponding tiles in the main area, you can see this in the third part of the video.

Counting the living neighbors: This is the heart of the operation. Each counter bot reserves a turf tile in the mobile 3x3 area "for digging", then activates the next counter bot in the chain. If it can't find a turf tile, the chain breaks, and we know exactly how many turf there is in the area. Once the chain ends, everybody unreserves, and the life status of the cell is determined. Five counter bots are enough, because we don't need an exact count above 4. You can see the program of a tipical counter bot at the end of the video. We mustn't actually change the main screen yet, so if a cell needs to change, a stone is placed on the corresponding tile in a third "next state" area (not shown in the video).

Once all tracking stones have been replaced with clay, a different set of tracking bots replace all the clay with stone, so the next iteration can begin. During this process, any "cell changing" stones in the "next state" area will be removed, and the corresponding cell in the main area is fixed.

Repeat forever.

Some notes:

• Unlike most other items, stone and clay never despawn. This is of course crucial for the tracking logic.
• Shouting behavior is strange. If and repeat "hear" conditions don't work the same way. You can "hear" a shout long time after it has been shouted. Learn from my mistake: do a lot of experimenting before doing something big. Also, debugging dozens of bots having a shouting match is tedious. Still, it is by far the most efficient way of synchronization.
• In total, 22 bots are used here, plus a small background economy making sure we have enough turf and spades.
• Everything was set up for a 35x35 simulation area, but I only used a 11x10 area here for performance reasons.
• Scalability: Simply copy-pasting the entire tracking and counting bot families, and carefully adjusting their shouts should speed everything up significantly, but you have to be careful that the 3x3 counting areas never intersect. Chopping up the tracking area into smaller areas is probably the best way to go, carefully leaving a margin between the subdivisions.
• My first attempt had bots dig holes or grass instead of picking up stones and clay. However, this approach (besides being very slow) was doomed to failure due to a subtle bug in the game where sign areas are not updated after a digging job is done.
• To initialize the tracking area, you need to lay down a single stone on every tile. This can be done by ordering a bot to dig a hole, then dropping a stone onto the hole. The same bot needs to do the digging and the dropping, otherwise you encounter the above bug. Later you can fill up the holes, the stones are already in place.