Introduction

JETCARP, Jimmie’s Euclidean Tilings and Cellular Automata Research Program, runs cellular automata on almost any tiling of the plane: squares and hexagons, all eleven Archimedean tilings, the 1,248 k-uniform tilings up to k = 6, 81 isohedral tile types, tiles you draw yourself, and the aperiodic Penrose, hat and spectre tilings. It runs Life and the Life-like rules, Generations, Larger than Life, Langton’s ant and the turmites, WireWorld, the cyclic and excitable rules, sandpiles, Lenia and more, several at once if you like, on shared or separate fields. It is one program, with a graphical app, a command line, a scripting language and a Model Context Protocol (MCP) server for AI assistants, and it comes with tools that search for spaceships, oscillators and other patterns and keep verified catalogues of what they find.

This is version 0.4.0, the first public release; the changelog lists what it does, and How JETCARP was made tells where it came from.

Who it is for

• Desktop art. JETCARP can run a scene as a live wallpaper behind your windows, as a screensaver, or as still wallpapers cut to your monitors, in thirty built-in palettes or your own. Start with Your first live wallpaper.
• Hobby exploration. Pick an entry from Quick Start, move it to another tiling, change the rule, draw your own tile, and see what happens. Searching for your own spaceships takes one command. Start with Life on a new tiling.
• Research. Every run is a scene that replays bit for bit and records its state hash; every catalogued pattern has been verified exactly; the searches are resumable jobs whose results do not depend on the thread count and are designed not to depend on the machine; and everything can be scripted. Start with Core ideas and Reproducibility.

A gallery

Every picture in this book is made by JETCARP from the scene named under it, so you can run any of them yourself: jetcarp run <scene> --gens N --png out.png.

Two ways through this book

• Desktop and hobby. Getting started, then tutorials 1 and 2, then the guides (for example Wallpapers and Searching for patterns) as you need them.
• Research. Getting started and Core ideas, then the encyclopedia of cellular automata and tilings, then Research (reproducibility, search methods, what is new, findings and the bibliography) and the Reference pages.

Standing on earlier work

Almost nothing in JETCARP’s rules and tilings is new: they are the work of many people over seventy years, credited on the page for each family and tiling, in the bibliography, and in Credits. The few things that, as far as we can tell, are new are listed with their evidence in What is new in JETCARP, together with what we decided not to claim. JETCARP was built with heavy use of an AI coding assistant; How JETCARP was made says how, and how its results were checked.

Where to go next

• Install JETCARP and set it up.
• Read the core ideas: tilings, cell fields, rules and scenes.
• See what is new and what the searches found.
• Cite JETCARP if it helps your work, and contribute if you would like to.

Installing JETCARP

JETCARP is one program, jetcarp: with no subcommand it opens the app, and its subcommands are the command line, the background host and the MCP server. Every way of installing it below gives the same program. Pick the one that suits the tools you already use:

Release builds are made for Linux on x86_64 and ARM (aarch64), Windows on x86_64, and macOS on Apple silicon and Intel. Linux on ARM and Intel Macs are built by the same release workflow but have not been tried by hand. On anything else, cargo builds JETCARP from source.

The installers

On Linux and macOS, in a terminal:

curl -LsSf https://github.com/jprodgers/jetcarp/releases/latest/download/jetcarp-installer.sh | sh

On Windows, in PowerShell:

powershell -ExecutionPolicy Bypass -c "irm https://github.com/jprodgers/jetcarp/releases/latest/download/jetcarp-installer.ps1 | iex"

Each installer downloads the release archive for your computer and the release’s SHA256SUMS, refuses the archive if its checksum does not match, and unpacks it into a folder of its own:

Nothing else is changed: no administrator rights are needed, no system folders are touched, and the shell installer never edits your shell’s startup files. If ~/.local/bin is not on your PATH, it says so and shows the line to add. On Windows, open a new terminal afterwards so that it sees the new PATH.

The installers take options. With the shell installer, put them after sh -s -- (or download the script and run sh jetcarp-installer.sh OPTIONS); with PowerShell, download jetcarp-installer.ps1 and run it with the options, or set the environment variable named with each before irm | iex.

An installer only ever replaces a folder it made itself (it leaves a .jetcarp-installer file there), and refuses to replace a jetcarp on your PATH that something else put there, such as pipx or cargo.

With pipx, uv or pip

JETCARP’s Python package contains the program and the starter pack, and no Python code. It installs the program onto your PATH like any Python tool:

pipx install jetcarp
# or
uv tool install jetcarp
# or, inside a virtual environment
pip install jetcarp

The wheels are built for the same systems as the release archives, for any Python 3.8 or newer; there is no source package, so on other systems use cargo. The starter pack goes in share/jetcarp/packs inside the Python environment, and on macOS the screen saver’s code in lib/jetcarp.

With Homebrew

On macOS or Linux:

brew tap jprodgers/jetcarp
brew install jetcarp

brew install jprodgers/jetcarp/jetcarp does both in one line. The formula installs the release archive; nothing is compiled. The starter pack is in $(brew --prefix)/share/jetcarp/packs.

With Scoop

On Windows:

scoop bucket add jetcarp https://github.com/jprodgers/scoop-jetcarp
scoop install jetcarp

Scoop adds jetcarp to your PATH and a JETCARP entry to the Start menu, which starts the app without a console window.

From a release archive

Each release on GitHub has an archive for each system, such as jetcarp-0.4.0-x86_64-unknown-linux-gnu.tar.gz or jetcarp-0.4.0-x86_64-pc-windows-msvc.zip. Unpack it anywhere and run jetcarp from the folder, or put the folder on your PATH. The folder holds:

• jetcarp (jetcarp.exe on Windows), the program;
• on Windows jetcarpw.exe, which starts JETCARP without a console window, for shortcuts and the screen saver; keep it beside jetcarp.exe;
• on macOS libjetcarp_saver.dylib, the screen saver’s code, which jetcarp host saver install uses; keep it beside jetcarp;
• packs/, the starter pack;
• README.md, the licences (COPYING, UNLICENSE, LICENSE-MIT), THIRD_PARTY_NOTICES.md and THIRD_PARTY_LICENSES.html, the notices of the libraries the program is built from.

With cargo

With Rust 1.95 or newer and a C compiler (for the SQLite and Zstandard libraries JETCARP builds in), cargo builds JETCARP from source:

cargo install jetcarp

From a copy of the repository, cargo install --path crates/jetcarp --profile dist builds the same way as the releases do: the dist profile leaves out debugging information, which would otherwise make the program several hundred megabytes. cargo installs only the program, so there is no starter pack (jetcarp paths says so); you can import packs yourself. On Linux the build needs no system libraries: windowing, Wayland, X11 and Vulkan are all loaded when the program runs.

Release candidates

Before a release, its candidates (0.4.0-rc.1, 0.4.0-rc.2 and so on) are published on GitHub as pre-releases, for testing. They are not on PyPI, crates.io, Homebrew or Scoop, and they are never GitHub’s “latest” release, so name the one you want. Use the installer attached to it:

curl -LsSf https://github.com/jprodgers/jetcarp/releases/download/v0.4.0-rc.1/jetcarp-installer.sh | sh

powershell -ExecutionPolicy Bypass -c "irm https://github.com/jprodgers/jetcarp/releases/download/v0.4.0-rc.1/jetcarp-installer.ps1 | iex"

or any installer with --version 0.4.0-rc.1 (-Version 0.4.0-rc.1 in PowerShell). Installing the release itself later replaces the candidate.

On each system

Linux

The release builds run on Linux with glibc 2.28 or newer: Debian 10, Ubuntu 20.04, Fedora 29, RHEL, Rocky and AlmaLinux 8, and anything newer. They are not built for musl systems such as Alpine, where cargo works instead.

The command line needs nothing beyond glibc. The app, the background host and the GPU simulation load these libraries when they start, which a desktop system already has:

• a Vulkan driver (libvulkan.so.1 with Mesa’s or your graphics card’s driver), or failing that OpenGL ES through EGL (libEGL.so.1);
• for windows, libwayland-client.so.0 on Wayland or libX11.so.6, libX11-xcb.so.1, libxcb.so.1, libXcursor.so.1 and libXi.so.6 on X11, and libxkbcommon.so.0 (with libxkbcommon-x11.so.0 on X11);
• for the app’s file dialogs, libdbus-1.so.3 and an XDG desktop portal.

jetcarp doctor shows the graphics adapters it found; with none, simulation runs on the CPU.

macOS

The release builds run on macOS 11 (Big Sur) or newer. They are not signed with an Apple Developer ID, so the first time you open one that your browser downloaded, macOS says it cannot check it for malicious software and will not open it. Either remove the mark the browser left on the archive before unpacking it:

xattr -d com.apple.quarantine jetcarp-0.4.0-aarch64-apple-darwin.tar.gz

or, after the warning, open System Settings → Privacy & Security and click Open Anyway beside the message about jetcarp. The installers, Homebrew, pipx, uv and pip download without that mark, so this applies only to an archive downloaded in a browser. The screen saver bundle that jetcarp host saver install makes is signed on your Mac, ad hoc, as macOS requires.

Windows

The release builds run on 64-bit Windows 10 and 11, and on Windows on ARM through its x64 emulation. They are not yet signed, so Windows SmartScreen may stop a program from a zip that your browser downloaded with Windows protected your PC. Click More info, then Run anyway; or, before unpacking, open the zip’s Properties and tick Unblock. The PowerShell installer and Scoop download without the browser’s mark, so this applies only to an archive downloaded in a browser.

jetcarpw.exe, beside jetcarp.exe, starts JETCARP without opening a console window; shortcuts, the login entry and the screen saver use it.

The starter pack

Releases come with a starter pack: a folder of packs (each a pack store, as Pack format lays out) that the first-run setup offers to import into your library. JETCARP looks for this folder in one place, the first of:

1. JETCARP_BUNDLED_PACKS, if it is set;
2. share/jetcarp/packs beside the folder the program is in (<program folder>/../share/jetcarp/packs), where Homebrew and the Python package put it;
3. packs in the program’s folder, as in the release archives and the installers’ folders.

The program’s folder is the one the program really is in: a link to it on your PATH, as pipx, uv, Homebrew and the installers make, is followed. jetcarp paths shows the folder it found as bundled:, and jetcarp doctor its size, or where it looked when there is none. JETCARP reads the folder and never writes to it. To import a pack from it yourself, run jetcarp pack import with the pack’s folder.

Checking a download

Each release has a SHA256SUMS file listing the SHA-256 of every file in it. The installers check the archive they download against it; to check a file you downloaded yourself, put SHA256SUMS in the same folder and run

sha256sum --check --ignore-missing SHA256SUMS                      # Linux
grep jetcarp-0.4.0-aarch64-apple-darwin.tar.gz SHA256SUMS | shasum -a 256 --check   # macOS

or, in PowerShell, compare (Get-FileHash jetcarp-0.4.0-x86_64-pc-windows-msvc.zip).Hash with the file’s line in SHA256SUMS (the case of the letters does not matter). Once the repository is public, each release file also has a signed record of the workflow run that built it, which the GitHub CLI checks:

gh attestation verify jetcarp-0.4.0-x86_64-unknown-linux-gnu.tar.gz --repo jprodgers/jetcarp

No telemetry

JETCARP makes no network connections. It does not check for updates, report crashes or collect statistics of any kind; it never sends anything anywhere. The only sockets it opens are on your own computer, for the app’s AI control and the background host (see SECURITY.md). Packs and other files reach it only when you give them to it.

Uninstalling

Run jetcarp uninstall first, while the program is still there, to undo what JETCARP set up outside its folders; then remove the program the way you installed it. Uninstalling has the details.

First run and setup

This page is being written.

A tour of the app

This page is being written.

Core ideas: tilings, cell fields, rules, scenes

JETCARP has a handful of ideas that the rest of this book takes for granted. This page introduces them briefly, in the order they build on each other, and points to the pages that explain each one properly.

A tiling is a neighbour graph

A tiling covers the plane with tiles, with no gaps and no overlaps: squares, hexagons, mixtures of polygons, shapes you draw yourself, or the aperiodic Penrose, hat and spectre tilings, which never repeat. Each tile is a cell of the automaton.

What a rule needs to know about a tiling is only who is next to whom. JETCARP turns every tiling into a neighbour graph: one node per tile, linked to its neighbours, kept in clockwise order around each tile. There are two kinds of neighbour. Touch neighbours share an edge or just a corner; on squares these are the eight cells of the Moore neighbourhood that Conway’s Life uses. Edge neighbours share a stretch of edge; on squares, the four cells of the von Neumann neighbourhood.

On squares every cell has 8 touch neighbours. Elsewhere the numbers change, sometimes from tile to tile: a triangle touches 12 others, an octagon of the 4.8.8 tiling 8 and its squares 4, and a Penrose rhomb between 7 and 11. Most rules count neighbours, so the same rule behaves quite differently on different tilings, and that is much of what makes JETCARP interesting. Two tilings that look different can have the same graph, and then every counting rule behaves the same on both.

More: Tilings as neighbour graphs, How JETCARP generalises automata to any tiling, and the tiling catalogue.

Cells live in fields

The states of the cells are kept in a cell field: one value per tile. What a value means depends on the rule. A binary field holds live or dead cells, each with an age, the number of generations it has been in its state. A multi-state field holds a state number (Generations, WireWorld, turmite colours, JACA’s +1 and −1). A height field holds sandpile grains, and a continuous field holds a value between 0 and 1 (Lenia). Time moves in generations: every cell’s next state is computed from the current states of itself and its neighbours, all at once.

Rules and families

A rule says how a cell’s next state follows from its own state and its neighbours’. Rules come in families, each with its own notation: Life-like rules written as birth and survival counts (B3/S23 is Life), Generations rules with dying states (B2/S/C3), Larger than Life with a larger range, Langton’s ant and the turmites, which are agents that walk and turn (Ant RL), the cyclic and excitable rules, sandpiles, Lenia, priority tables, rule tables, and others. Two families are, to our knowledge, new in JETCARP, both Jimmie Rodgers’s: JACA, an annihilating two-sided Life, and layered rules, which grow Wolfram-style row rules outward from a seed on any tiling (see What is new in JETCARP). Many rules also have names, such as Life, HighLife or Brian’s Brain.

Every family is written in terms of the neighbour graph, so almost every rule runs on almost every tiling. The few that are tied to a particular grid, such as the elementary row rules and von Neumann’s 29-state automaton, say so.

More: the encyclopedia of cellular automata, one page per family, and the named rule catalogue.

Several automata on one tiling

A world is one tiling with one or more automata on it, each with its own rule, seed and palette. Every generation the automata step in order. Automata of the same kind (all binary, say) share one field by default, so they act on each other’s cells: in the built-in scene Rule 30 meets Life and ants, Rule 30 writes rows, Life rewrites what it leaves behind, and three ants wander through both. An automaton with Affects others switched off keeps a private field instead, drawn alongside the others but untouched by them. Automata whose fields cannot be shared, such as a sandpile, always keep their own. A scene can also carry a script, which switches automata on and off in turn as conditions are met.

More: Several automata at once.

Scenes are how runs are kept

A scene is a small JSON file that holds everything needed to reproduce a run: the tiling, the automata with their rules and seeds, the state of the random-number generator, and the log of every change made since. Opening a scene replays it, so it comes back exactly as it was. A saved scene records the generation and state hash it reached, and jetcarp verify checks that it still gets there: the same scene gives the same state, bit for bit, on any number of threads, on the CPU or the GPU, and, by design, on any operating system. Scenes are what you save and share, what the command line runs, and what every picture in this book is made from.

More: Scenes: saving, sharing, reproducing, the scene file format and Reproducibility.

Quick Start

Quick Start is the menu of ready-made scenes that the app opens with, each shown as a live preview. Its entries come from four sources, all kept in the pattern library: the classics built into JETCARP (hand-made scenes and a working example of every named rule, each on the grid it is usually shown on), entries from the packs you import, the atlas of runs picked from an exploratory search, and My finds, the entries you add yourself from patterns, runs and scenes. It is the quickest way to see what JETCARP can do, and an entry, once open, is a scene like any other: move it to another tiling, change its rule, save it. Right-click a card to rate it or hide it.

More: A tour of the app and Building your own Quick Start.

The pattern library

The pattern library, or catalogue, is a database of verified patterns: still lifes, oscillators, spaceships and the like, each with the tiling it lives on and the range of rules it works in, plus the runs of ants and turmites and the record of every search. Nothing goes in unverified: each pattern is run again on its own and checked cell by cell before it is stored. Patterns can be pasted into a world, rendered as pictures and animations, and promoted to Quick Start.

More: The pattern library.

Jobs

Searches can run for minutes or for weeks, so each one runs as a job: a record in the catalogue with the search’s settings, its progress and a checkpoint. A job can be stopped, closed with the program and carried on later, on this machine, and it ends exactly as an uninterrupted run would. The command line starts searches with jetcarp search <strategy> (soup hunts, ant searches, rule censuses, the evolutionary glider search and others) and manages them with jetcarp jobs.

More: Searching for patterns and Search methods.

Your first live wallpaper

This page is being written.

Life on a new tiling

This page is being written.

Hunting for spaceships

This page is being written.

Building your own Quick Start

This page is being written.

5. Scripting a rule sweep

In this tutorial you write a short Rhai script that runs 64 cellular automaton rules on the Cairo pentagon tiling, one world per rule, in parallel on every core. Then you read the results back, lay your favourites out on a contact sheet, and put the best one in your Quick Start menu. It takes about fifteen minutes, and the sweep itself runs in a couple of seconds.

You need JETCARP installed (Installing) and a text editor. Everything here runs from a terminal; the same scripts also run in the app, under Tools → Scripts and sweeps…. Everything the scripts write goes into JETCARP’s output folder, <Pictures>/JETCARP (see Folders).

1. One world

Start with a single world, to see what a script looks like. Save this as first.rhai:

// Life on Cairo pentagons: run 300 generations and save a picture and a scene.
let w = world(#{ tiling: "cairo", size: "120x80" });
w.add_ca("B3/S23", #{ seed: "random:0.35" });
w.step(300);
out_dir("cairo-life");
w.save_png("cairo-life.png");
w.save_scene("cairo-life.json");
print(`generation ${w.generation()}, ${w.population()} live cells, hash ${w.hash()}`);

and run it:

$ jetcarp script first.rhai
generation 300, 1527 live cells, hash 8c936c690b20f095
output: /home/ada/Pictures/JETCARP/2026-11-11_21-27-33_cairo-life
time:   0.10s

Line by line:

• world(…) makes a world: here 120 × 80 unit cells of the Cairo tiling, with dead edges.
• add_ca adds a cellular automaton to it, Conway’s Life (B3/S23), seeded with 35% of its cells alive.
• step(300) runs 300 generations.
• out_dir("cairo-life") makes a new folder in the output folder, named with the time and the label, and later file names are relative to it.
• save_png and save_scene write a picture and a scene.

Your hash will be the same as the one above: the same tiling, rules and seeds always give the same world, on any computer and at any thread count. jetcarp verify cairo-life.json replays the scene and checks that it reaches that hash again.

2. Sweep 64 rules

A sweep runs one world per rule. Instead of Life, take a random sample of 64 rules from a family: births on 2 to 4 live neighbours, survival on 1 to 5, and four states. In a four-state Generations rule, a dying cell fades through two more states before it is empty, which leaves coloured trails behind anything that moves. Save this as sweep.rhai:

let s = sweep(#{
    rules: "B/S", birth: "2-4", survive: "1-5", states: 4,
    sample: 64, sample_seed: 1,
    tiling: "cairo", size: "64x40",
    seed: "random:0.35", rng_seed: 1,
    max_gens: 300, palette: "Prism",
    png: #{ size: [480, 300] },
    skip: ["empty", "full"],
    out: "cairo-gen",
});
print(`${s.runs} runs, ${s.images} pictures`);

$ jetcarp script sweep.rhai
sweep done: 64 of 64 runs, 50 images, 50 kept, 0 errors in 1.4s
64 runs, 50 pictures
output: /home/ada/Pictures/JETCARP/2026-11-11_21-29-35_cairo-gen
time:   1.37s

What the options do:

• rules: "B/S" with birth and survive describes every rule whose births and survivals fall in those ranges. sample: 64 picks 64 of them at random, and sample_seed makes it the same 64 every time.
• tiling, size, seed and rng_seed are the same for every run, so the rule is the only difference between them.
• max_gens: 300 runs each world 300 generations; until can stop a run earlier, for instance when it stops changing.
• png sets each picture’s size, and palette its colours.
• skip: ["empty", "full"] doesn’t save pictures of runs that died out or filled up, which is why 50 of the 64 runs have one.

The sweep’s folder holds a picture per run (03_B23_S1_C4.png and so on) and a manifest, as manifest.csv and manifest.json, with a row per run: its rule, picture, final hash, population, density, period if it settled into one, and, for rules that write row by row, a description of its rows (row_class, row_hint). run.json records how the sweep was made.

Open the folder and look through the pictures. Some rules die at once, some freeze into specks, some crawl with worms, some boil.

3. Read the results back

The manifest is what makes a sweep useful beyond its pictures. manifest(folder) gives a script its rows, so a second script can sort and filter them. Save this as pick.rhai:

// The runs still busy at the end, most cells alive first.
let rows = manifest(params.folder).filter(|r| r.kept && r.period == ());
rows.sort(|a, b| b.population - a.population);
for r in rows {
    print(`#${r.index}  ${r.rule}  ${r.population} cells`);
}

and give it the sweep’s folder with --set:

$ jetcarp script pick.rhai --set folder=/home/ada/Pictures/JETCARP/2026-11-11_21-29-35_cairo-gen
#53  B234/S1234/C4  7581 cells
#7  B24/S234/C4  7116 cells
#58  B23/S134/C4  7095 cells
…

--set key=value puts values in the map params. A run that never settled has no period, which Rhai writes as (). Every row has the manifest’s columns, so you can sort by density, keep only row_class == "periodic", and so on.

Measure more as you go. A sweep can also call a function of yours on every world when its run ends, and add what it returns to the manifest. Add this option to the sweep above to count each run’s still lifes and oscillators:

    keep: |w, n| {
        let o = w.objects();
        #{ still_lifes: o.totals.still_life, oscillators: o.totals.oscillator }
    },

and the manifest gains still_lifes and oscillators columns. Running the sweep again with the same folder (folder: "…" instead of out:) reuses the runs already done. Since this changes what each run records, start a new folder instead.

4. A contact sheet of your favourites

jetcarp sheet lays chosen runs out on one picture, each labelled with its index and rule:

$ jetcarp sheet --folder /home/ada/Pictures/JETCARP/2026-11-11_21-29-35_cairo-gen \
    --runs "#1,#2,#3,#4,#7" --cols 5 --thumb 240 --png favourites.png
sheet: favourites.png (1248x194)

Runs are named by their index in the manifest (#3), by their rule text ("B23/S1/C4"), or for a numbered family by their number (n=588).

5. Keep the best one

When a run is worth coming back to, put it in your Quick Start menu:

$ jetcarp library promote-run /home/ada/Pictures/JETCARP/2026-11-11_21-29-35_cairo-gen "#3" --title "Cairo worms"
promoted: B23/S1/C4 as "Cairo worms" (run #3)

The entry holds the run’s tiling, rule and starting state, so opening it from the Quick Start menu replays the run exactly as the sweep ran it. The run is also starred in the folder’s favourites.json. A script can do the same with library().promote_run(folder, "#3").

Where to go from here

• Bigger sweeps. A sweep runs on every core and can be stopped with Ctrl-C: it saves its manifest first and prints the command that carries it on. Rerunning it with folder: set to its folder skips the runs already done. The named families "W", "HexW", "HexW3", "HexT" and "HexT3 sum" are numbered, so rules: "HexW3", from: 0, to: 19682 sweeps all 19,683 ternary hexagon rules. The example scripts that ship with JETCARP (Examples in the app’s script editor, and the crates/jetcarp-script/scripts folder of the source repository) include sweeps of every elementary rule.
• Without writing code. The app’s Sweep builder tab, under Tools → Scripts and sweeps…, builds the same sweeps from a form, and Sweep this world sweeps a rule over whatever world is open.
• More functions. Scripting lists every function: worlds, runs, objects, pictures, the pattern library, searches and large sandpiles.

Driving JETCARP from an AI assistant (MCP)

This page is being written.

Scenes: saving, sharing, reproducing

A scene is a small JSON file that holds everything needed to reproduce a run: the tiling, the automata with their rules and seeds, the starting state of the random-number generator, and the log of every change made since. Opening a scene replays that log, so the world comes back exactly as it was. A saved scene also records the generation and the state hash it reached, so anyone can check that it still gets there. This guide covers saving and opening scenes in the app, running and checking them from the command line, sharing them, and getting a scene back out of a picture. The file itself is described in Scene file format.

Save and open a scene in the app

• File → Save scene… (Ctrl+S) writes the current world as a scene. The file holds the tiling, the automata, the random state and every change since the last reset or change of tiling (the Command log pane lists them), together with the view (where the camera is, the zoom and the speed) and a record of the generation and state hash. The Scene pane confirms it with the file’s path and the hash.
• File → Open scene… (Ctrl+O) opens one. The world is rebuilt and its log replayed, so it opens at the saved generation and in the saved view. You can also open a scene when the app starts: jetcarp --scene scene.json.
• Quick Start entries are scenes. Open one, change what you like, and save it.

Everything you do to a world goes into its log: painting cells, pasting library patterns, adding and changing automata, reseeding, editing palettes, running. Consecutive runs are merged into one step entry, so a long session does not make a long file. Edit → Reset, choosing another tiling, and a new random state start the log again from a new base.

The state hash is shown at the right end of the menu bar, after the generation: hash 1adf6e32, the first eight of its sixteen digits. Click it, or use Edit → Copy state hash, to copy the whole hash. Worlds of more than about a million cells compute the hash only while paused, and show hash … while they run.

Run a scene from the command line

jetcarp run loads a scene, replays its log, runs more generations if asked, and reports where it ended:

$ jetcarp run crates/jetcarp-core/data/scenes/rule30-life-ants.json --gens 100 --png out.png --save out.json
scene:      crates/jetcarp-core/data/scenes/rule30-life-ants.json
tiling:     Square (parallelogram) (square): 38400 cells, 240x160 unit cells, 1 tile type(s), storage dense, edges dead
backend:    cpu (32 threads)
generation: 100
hash:       1adf6e3234b7f199
status:     Running
done:       no
field 0:    shared binary, 2124 live: Rule 30 [W30], Life [B3/S23], Langton's ant [Ant RL]
png:        out.png (1600x1067)
saved:      out.json
time:       0.03s on 32 threads

--gens N counts from where the scene ends: run out.json (saved at generation 100) with --gens 50 and it stops at generation 150. The other options:

Check that a scene still reproduces

jetcarp verify replays a saved scene and compares the generation and hash it reaches with the ones it recorded:

$ jetcarp verify out.json
ok: generation 100 hash 1adf6e3234b7f199

If they differ it says so and exits with status 1:

Error: MISMATCH: recorded gen 100 hash 1adf6e3234b7f198, replayed gen 100 hash 1adf6e3234b7f199

A scene with no record, such as one written by hand, cannot be verified (scene has no recorded hash); run it with jetcarp run --save to record one. For a check inside a script or a test, use jetcarp run scene.json --gens N --expect HASH, which fails with hash mismatch: expected …, got … unless the run ends on that hash. jetcarp verify always replays on the CPU, so it is also the way to check a run made with --gpu.

The state hash

The state hash is a 64-bit number, printed as sixteen hexadecimal digits, computed from everything that decides what the world does next: every cell’s state and age, sandpile heights, Lenia’s values, the generation, the ants, and the progress of any script or reseed policy. Two worlds with the same hash are, in practice, in the same state. The hash does not depend on the number of threads or on whether the CPU or the GPU did the work, and by design it does not depend on the operating system.

One case needs care: a HashLife jump reaches exactly the same cells as stepping, but restarts every live cell’s age at 1, so its state hash differs. Compare the hash of the cell states alone instead (states_hash() in scripts, cells_hash in the world status that MCP tools read). How the hash is computed and tested is in Reproducibility.

Share a scene

A scene is one text file, and it carries everything it needs: the rule tables and palettes it uses, and the cells of any library pattern pasted into it, so it does not need your pattern library. Send the file; the other person opens it in the app or runs jetcarp verify on it to confirm that their machine reaches the same hash. Scenes work well in version control, and with the output of jetcarp doctor they make a complete bug report.

A few limits apply:

• A scene names its format (now 1). A JETCARP that only knows an older format refuses a newer scene rather than guessing.
• Until JETCARP 1.0, a release may change how a rule or a tiling behaves. Such changes are deliberate and listed in the changelog, but an old scene may then reach a different hash. The Penrose rhombs already lay out their tiles differently from those of CART, JETCARP’s predecessor.
• Palettes you made travel inside the scene. A scene that names a palette the other person’s JETCARP does not know (a built-in palette added in a later release, say) still opens, drawn in Ember, with a warning; the name is kept, so saving the scene again keeps it.

Get the scene back from a picture

Every PNG made by jetcarp run --png, File → Export PNG…, File → Export wallpaper…, jetcarp wallpaper, jetcarp hashlife --png and a script’s save_png carries its scene inside it, as PNG text chunks: jetcarp:scene (the whole scene), jetcarp:version, jetcarp:generation, jetcarp:hash and jetcarp:dead_boundary. A picture can therefore always be traced back to the run that made it. (Animations and frames from jetcarp media do not carry them.)

JETCARP does not yet open a scene from a PNG itself, but any program that reads PNG text chunks can take it out. With Python and the Pillow library:

from PIL import Image
open("scene.json", "w").write(Image.open("out.png").text["jetcarp:scene"])

$ jetcarp verify scene.json
ok: generation 100 hash 1adf6e3234b7f199

Scenes everywhere else

• Scripts read and write scenes with load_scene(path), scene_world(json), w.save_scene(path) and w.scene() (see Scripting (Rhai) API).
• MCP tools have load_scene and get_scene (see MCP tools).
• Pictures and the desktop. jetcarp wallpaper scene.json, jetcarp media render --scene, screensaver profiles and rotations all take scene files (see Pictures and animations and Wallpapers, screensavers and the background host).
• This book. Every figure is made from a scene, named under it, and for the still pictures jetcarp run <scene> --gens N --png out.png makes it again.

To write a scene by hand, start from the short example in Scene file format; anything you leave out takes its default.

Several automata at once

A world can run any number of automata on one tiling, each with its own rule, seed, palette and settings. Every generation they step in turn. Whether they act on each other depends on their fields, the arrays of cell values they work on: automata of the same kind share one field by default, so each reads and writes the others’ cells; an automaton with Affects others switched off keeps a private field instead, drawn alongside the rest but untouched by them. This guide explains which automata share, how to change it, in what order they step, and how several fields are drawn.

Which automata share a field

Every rule needs a certain kind of field:

• Binary rules share by default. Affects others starts on, and every binary automaton with it on works on the same field.
• Other rules start on a private field. Affects others starts off. Switch it on and the automaton shares a field with the others of exactly its kind: the same field kind and the same number of states. Two B2/S/C3 automata can share; a C3 and a C4 cannot.
• Sandpiles never share. Their field holds grain heights, which no other rule understands, so the checkbox is greyed out.

When an automaton joins a shared field, its live cells are copied into it. When it leaves, it takes a private copy of the shared field as it is at that moment, and from then on the two evolve separately. A B/S rule added to a shared field that already has live cells, with no seed of its own, starts from those cells rather than scattering a random soup over another automaton’s work.

Order within a generation

The automata step in list order: the order they were added, or in a scene the order of its cas list. Each takes its steps per generation (1 to 100,000) before the next begins, so on a shared field a later automaton sees what an earlier one did in the same generation. Ants are usually given many steps per generation (100 or 200 in the built-in scenes) so that they keep up with the cellular automata around them. An automaton whose checkbox is cleared does not step at all, but its field stays and is still drawn.

To have automata take turns over longer stretches, a scene can carry a sequence: a list of steps, each naming the automata that run during it and a trigger that moves on to the next (after a number of generations, when the population passes a value, when activity drops, when the world repeats, and so on). The Sequence pane builds one with New sequence, and Apply and start runs it; it is saved with the scene. The built-in Script: Rule 30, Day & Night, Seeds, Life, ants is a five-step example, and the format is in Scene file format.

In the app

• Add automata with CA → Add from catalog (the named rules, by family), CA → Add by notation… (which opens the Add pane: pick a named rule and press Add, or type any rule in notation such as B36/S23 or Ant RLR), or CA → Load rule table….
• The CAs pane has one card per automaton. Its header has the checkbox that runs it, its name and notation, and Remove. Inside are the rule, the neighbourhood (Touching or Edge), the Affects others checkbox with the field it is on (for example field 0 · shared binary · 3 CAs), Steps per generation, Colour by, Palette, and the Seed, Random and Clear buttons. Ant cards add + Ant and what ants do at a dead edge (Edge: bounce or Edge: fall off).
• Seed and clear every automaton at once from the Seed menu (Seed every CA, Random cells in every CA, Clear every CA), or one at a time from Seed → Each CA.
• Draw into one field. The Draw pane’s Into list chooses which automaton’s field the mouse paints.

From the command line, scripts and scenes

In a scene, affects_others is a field of each automaton:

"cas": [
  {"rule": "W30", "seed": "top_center"},
  {"rule": "B3/S23", "affects_others": false, "seed": {"blob": {"radius": 0.45, "density": 0.35}}}
]

In a script, it is an option of add_ca and update_ca:

let w = world(#{ tiling: "square", size: [200, 120], boundary: "dead" });
let r30 = w.add_ca("W30", #{ seed: "top_center" });
let life = w.add_ca("B3/S23", #{ affects_others: false, seed: "blob:0.45:0.35" });
w.step(110);
w.update_ca(life, #{ affects_others: true });   // join Rule 30's field from here on

jetcarp run reports every field and who is on it:

field 0:    shared binary, 6287 live: Rule 30 [W30]
field 1:    private binary, 584 live: Life [B3/S23]

How several fields are drawn

Each field is coloured by the first automaton in the list that uses it, with that automaton’s palette and Colour by setting. Changing the palette of a later automaton on a shared field therefore changes nothing you can see; change the first one’s. Fields are drawn in list order, later ones over earlier ones, with ants on top. Empty cells take the background of the first automaton’s palette, and the area outside the tiling its stage colour. The details are in Palettes.

Examples to try

• Rule 30 meets Life and ants (Quick Start): Rule 30 writes rows, Life rewrites what it leaves behind, and three ants taking 100 steps per generation wander through both, all on one binary field.
• Script: Rule 30, Day & Night, Seeds, Life, ants (Quick Start): five rules on one shared field, switched on one after another by a sequence.
• The two scenes of the figure above: run them with jetcarp run docs/scenes/guides/several-separate.json --gens 110 --png out.png, then switch Affects others on and off in the app and watch the triangle.

More: Core ideas and How JETCARP generalises automata to any tiling.

Drawing and editing tiles

Many of JETCARP’s tilings can be reshaped, and new ones can be drawn from scratch. There are three tools: the tile editor, which bends the edges and moves the corners of a tile from one of the editable tile families or the isohedral types; the isohedral picker, which chooses one of Kaplan’s 81 isohedral types and sets its shape with sliders; and the unit cell editor, which draws any repeating arrangement of polygons. Whatever you make is saved in the scene, so a reshaped world replays exactly. (To paint cells rather than tiles, use the Draw pane.)

What can be edited

For the editable families and the isohedral types, reshaping changes how a world looks, not how a rule behaves: the automata use the neighbour graph of the family, and dragging corners or bending edges does not change which tiles meet. When curved edges would make different tiles touch, the tile editor says for how many tiles, and that CAs use the straight-edge graph. In the unit cell editor, on the other hand, which tiles are neighbours is measured from the polygons you draw, so a new cell is a new graph.

The tile editor

Open it with Tiling → Tile editor…, or Edit tile… in the Tiling pane. The window shows the tile in the middle of a canvas, with ghost copies of its neighbours around it, and the controls on the right.

1. Choose the family in the list at the top (the current tiling’s is chosen already). Below it are a note on the family and its symmetry group. For an isohedral type the type picker and its sliders appear here too (see below).
2. Pick an edge. Edges come in colour-coded classes, and each edge’s partner follows it, so the tiles always fit. Click an edge to select its class (Edge class 2 of 3).
3. Choose its shape: Free (any shape, which its partner copies), Mirror (symmetric about its midpoint), Half-turn (the same after a half turn) or Straight. Some choices are greyed out where the way an edge pairs with its partner allows only certain shapes, and the editor says so (This edge must stay half-turn symmetric to fit its neighbour).
4. Bend it. Add point, or double-click an edge, adds a point; drag points and corners with the mouse; Delete point removes the selected one. Lines joins the points with straight segments, Curves with smooth curves.
5. Use it. Use this tile rebuilds the world on the new tile. With Live ticked, the world is rebuilt after every edit.

Snap (Off, Square, Triangle) keeps points on a grid. Undo steps back, Randomize gives random edge shapes within the family’s rules, and Reset returns to the family’s default tile. A line under the controls says Valid tile, or Edges cross: tiles would overlap when an edge has been bent through another.

Copy tile JSON puts the tile on the clipboard as text, and Load JSON below reads one pasted into the box underneath, which is a way to keep and share tiles. (The Tiling pane’s Paste tile JSON from the prototype section reads tiles copied from JETCARP’s original JavaScript tiling editor.)

Isohedral types

In the Tiling pane’s family list, choose Isohedral IH01–IH93 (81 types). The type picker appears under it: < and > step through the types, and the list shows each one’s symmetry group, number of corners and number of parameters (for example IH28 p4 5 corners, 2 params). Each parameter has a slider (p1 to p6; the world is rebuilt when you let go), and Default shape returns to Tactile’s own. Types with no parameters say No shape parameters: the corners are fixed. Edges can still be reshaped. To reshape the edges, open the tile editor, which shows the same picker; its edge choices follow Tactile’s rules for the type, so the tile stays in it.

From the command line, jetcarp isohedral lists the 81 types with their symmetry groups and neighbour counts, and jetcarp isohedral --png sheet.png draws all of them on one contact sheet (with random edge shapes, or straight ones with --straight; --seed picks other random shapes). In a scene or a script, a type and its parameters look like this:

"tiling": {"family": "ih28", "params": {"p": [0.45, 0.5]}, "size": {"cells": 2000}}

let w = world(#{ tiling: "ih28", params: #{ p: [0.45, 0.5] }, size: 2000 });

The unit cell editor

The unit cell editor draws tilings of the periodic family: two lattice vectors, which say how the cell repeats, and any polygons inside one cell. Tiles may have different shapes and need not meet edge to edge. Open it with Tiling → Unit cell editor…, or Edit unit cell… in the Tiling pane (it is not available for the aperiodic tilings, which have no unit cell).

• Start from an empty square or hexagonal lattice, any fixed tiling, any tiling of the catalogue, or an editable family with straight edges.
• Tools. Select drags corners, whole tiles and the two lattice arrows; double-click an edge to add a corner. Draw tile adds a tile corner by corner: click the corners, then click the first one again, double-click or press Enter to close it; right-click removes the last corner and Esc cancels. Stamp n-gon puts a regular polygon with a chosen number of Sides on the edge you click (or in empty space), with options for its side length and which side of the edge it goes.
• Snapping. Snap to Corners, Edges and Angles, a Grid (Off, Square, Triangle), and Move shared corners together, so that dragging a corner drags every corner sitting on it. Ghost rings sets how many rings of neighbouring cells (1 to 3) are drawn around the cell.
• The selected tile can be deleted, duplicated or moved back into the cell, and its corners inserted or deleted. Undo, Redo and Fit view work as usual; scroll to zoom and drag empty space (or use the right button) to pan.

As you work, the editor checks the cell for overlaps between tiles and their copies, gaps, tiles that cross themselves and edges with nothing on the other side. It lists every tile with its number of corners, area and measured neighbours (by edge and touching), and says Valid tiling when all is well. Use this cell (available once there are no errors) rebuilds the world on it, and Live does so after every valid edit. Copy cell JSON and Load JSON below copy and paste the cell as text.

A cell in a scene or a script is written as the lattice vectors a1 and a2 and a list of polygons, each a list of corners. This one cuts the unit square into two triangles:

"tiling": {"family": "periodic",
           "params": {"a1": [1, 0], "a2": [0, 1],
                      "polys": [[[0, 0], [1, 0], [1, 1]], [[0, 0], [1, 1], [0, 1]]]},
           "size": {"rect": {"w": 40, "h": 30}}, "boundary": "wrap"}

let cell = #{ a1: [1, 0], a2: [0, 1],
             polys: [[[0, 0], [1, 0], [1, 1]], [[0, 0], [1, 1], [0, 1]]] };
let w = world(#{ tiling: "periodic", params: cell, size: [40, 30], boundary: "wrap" });

In the scene

A reshaped or drawn tile is part of the scene’s tiling: its shape parameters in params and, for tiles made in the tile editor, the shape of each edge in edges (see Scene file format). Changing the tile starts the world’s command log again from the new tiling, as any change of tiling does. Saved, the scene replays to the same hash. JETCARP’s tests pin the geometry of every family’s default shape and every catalogued tiling; a tile of your own is checked by its scene’s hash instead (see Reproducibility).

More: Editable tile families, Isohedral tilings, Tilings as neighbour graphs and the tiling catalogue.

Palettes and colouring

Every automaton draws in a palette: a list of colour stops, plus a background colour for empty cells and a stage colour for the area outside the tiling. Its colour by setting decides how its states, and how long each cell has been in its state, are spread along the stops. This guide shows how to pick a palette, make your own, and choose the colouring, including age colouring. The 30 built-in palettes, with their colours, and the exact rules for every family are in the Palettes reference.

Pick a palette in the app

• One automaton. In the CAs pane, each automaton’s card has a Palette list with the built-in palettes and any the scene has of its own. A JACA automaton has two, +1 palette and −1 palette, each with a colour button beside it that sets a single colour instead.
• The Palettes window (CA → Palettes…) shows every palette as a swatch on its own background, so the light ones (Candy, Glacier, Desert and Paper) look right. Choose what to colour under Apply to, every automaton or one, then click a swatch to apply it. Hovering over a swatch, or moving between swatches with the arrow keys after a click, previews it on the grid; Enter applies it.

On a field that several automata share, only the first automaton’s palette shows, and the grid’s background and stage colours always come from the first automaton’s palette (see Several automata at once). If a palette change seems to do nothing, change the first automaton’s instead.

Make your own palette

The lower half of the Palettes window edits a palette:

1. Start from a palette that is close to what you want, and give it a Name.
2. Change the Stops: click a colour to change it, x under it to remove it, and + to add one. The first stop colours the youngest cells or lowest states, and the last the oldest or highest. The bar above the stops shows the ramp as JETCARP will draw it.
3. Set the Background (empty cells) and the Stage (outside the tiling, and the letterbox around a wallpaper that does not fill its image).
4. Save as “name” adds it to the scene’s own palettes; an edited built-in palette is saved as “name copy”. Apply to every CA (or to the CA) saves it and applies it at once.

A palette you make belongs to the scene: it is saved in the scene file and travels with it, so whoever opens the scene sees your colours. To use it in another scene, copy its entry from the first scene’s palettes list (see Scene file format), or apply it again in the app.

You can also write colours directly wherever a palette is named in a scene or a script: #4fc3ff is one colour, and #103050-#4fc3ff a ramp from the first to the last, with any number of stops between. The same works for the --palette options of jetcarp wallpaper, jetcarp sheet, jetcarp hashlife, jetcarp pile and jetcarp media render.

Choose how cells are coloured

Every automaton has a Colour by setting, in the CAs pane, as color_by in a scene, and as the color_by option of add_ca and update_ca in a script:

The full table of what Auto means for each family is in the reference.

Age colouring

Each live cell carries an age: the number of generations it has been in its current state, starting at 1 when it is born or changes state. Coloured by age, a newborn cell takes the palette’s first stop, and older cells move along the palette on a logarithmic scale, reaching the last stop at an age of 400. So a still life ends at the last stop, an oscillator flickers near the start, and the debris of a soup shows its own history: the places still active at the young end, the parts that settled long ago at the old end. The figure at the top of this page shows it.

A few things to know:

• Choosing a palette for it. Some palettes end on a bright stop, such as Verdigris, so that settled patterns stay vivid; others, such as Ember, end on a dark stop close to their background, so that settled patterns fade and the active regions stand out instead.
• HashLife resets ages. After a HashLife jump every live cell has age 1, so the colours start over (see HashLife and very long runs).
• Ages are part of the state. They are included in the state hash, so two runs that look the same in state colouring but differ in age have different hashes.
• Media use states. The animations that jetcarp media makes colour cells by state, never by age, so that their loops close seamlessly (see Pictures and animations).

JETCARP makes no claim for age colouring: other programs, such as Chris Rowett’s LifeViewer, colour cells by age and did so first (see What is new in JETCARP).

On the command line and in scripts

• jetcarp palettes lists the built-in palettes with their background colours, and jetcarp palettes --json gives their stops, backgrounds and stages as data.
• Commands that draw pictures take --palette NAME to colour every automaton with one palette: jetcarp wallpaper, jetcarp sheet, jetcarp hashlife, jetcarp pile (sandpile heights, with --reverse to run the palette the other way), jetcarp library render and jetcarp media render (in place of the media’s own house style).
• In a script, w.add_ca(rule, #{ palette: "Tide", color_by: "age" }) sets an automaton’s palette and colouring, w.update_ca(id, #{ palette: "Ink" }) changes it, and w.save_png(path, #{ palette: "Paper" }) draws one picture in another palette without changing the world. jetcarp("reference.palettes") returns the built-in palettes as data.
• In a scene, each automaton’s palette (and, for JACA, palette_neg) and color_by fields, and the scene’s own palettes list (see Scene file format).
• Screensaver profiles and rotations can replace every automaton’s palette and colouring with their own, without changing the scene.

Reseeding

Most worlds settle down sooner or later: a Life soup turns to ash, Brian’s Brain dies out, a sandpile stops. Reseeding puts new life into a world: once, by hand, or automatically, through policies that fire when the world has settled or every so many generations. It is what keeps a wallpaper or a screensaver lively for hours. Reseeding works the same way in the app, on the command line, in scripts, through MCP and in scene files, and every reseed is planned from the world’s own random state, so a reseeded run replays exactly.

The three modes

Sizes are measured in typical tiles, so a drop six tiles across looks the same on squares, hexagons, mixed tilings and aperiodic patches; on wrapped grids, drops and blobs wrap across the edges. A reseed writes into the field of every running automaton (sandpiles excepted), or into one automaton’s field if you name it. New live cells are in state 1, with age 1.

On a JACA field, whose live cells are +1 or −1, each mode also takes a sign: either (the default: each drop or blob is all +1 or all −1, at random; in random mode, each cell), mixed (each new cell +1 or −1 at random), alternate (drops and blobs alternate, and the first sign changes with every reseed), pos or neg. Other fields ignore it.

Reseed now

• In the app: Seed → Reseed now → Random, Rain or Blobs, or the Reseed now buttons in the Reseed pane. Their settings, and which automaton they aim at, are under Reseed now settings in the same pane (Defaults puts them back).
• On the command line: jetcarp run scene.json --reseed-now rain --gens 500 reseeds once before running. The mode is a name (random, rain, blobs, optionally with a JACA sign: rain:neg) or JSON: --reseed-now '{"kind":"rain","drops":40}'.
• In a script: w.reseed("blobs") reseeds every running automaton’s field, and w.reseed(id, #{ kind: "rain", drops: 30, min_size: 2, max_size: 8 }) one automaton’s.

A reseed by hand also restarts the cooldown of every automatic policy.

Automatic policies

A policy has a mode, a trigger (when), a cooldown, and optionally a target automaton (ca; without one it reseeds every running automaton). There are two triggers:

• every fires every gens generations (1 means every generation: a continuous drizzle).
• settled fires when the world has settled. It is checked every 16 generations once the cooldown is over, and fires when any one of these holds:
  • fewer than activity of the cells (default 0.002, that is 0.2%) changed in each of the last for_gens generations (default 60);
  • the number of cells changing each generation has repeated with a period of at most cycle (default 12, at most 64) over those generations, which means only oscillators and gliders are left (Life’s ash keeps about 1% of its cells blinking, so a threshold alone would never see it settle);
  • an exact repeat of the whole state with a period of at most period was seen (off by default);
  • the running fields are empty;
  • latest generations have passed since the policy last fired, whatever the activity (off by default). This makes sure a screensaver never stalls.

The cooldown is the number of generations after a policy fires (or is installed, or a reseed by hand) during which it cannot fire, so that a new seed has time to develop; a settled policy starts counting quiet generations only once it is over.

Policies run independently of each other, and that can surprise you: a frequent every policy keeps the world busy, so a settled policy beside it may never see it settle. Here Life ran for 3,000 generations with blobs when settled and ten drops of rain every 500 generations:

$ jetcarp run crates/jetcarp-core/data/scenes/life.json --gens 3000 \
    --reseed '[{"mode":"blobs","when":"settled","cooldown":200},{"mode":{"kind":"rain","drops":10},"when":{"kind":"every","gens":500}}]'
...
reseed:     blobs when settled: fired 0 times, last at -
reseed:     rain every 500: fired 6 times, last at 3000

Giving the settled policy a latest (Anyway after in the app) makes it fire anyway.

The Reseed pane

Seed → Reseed opens the Reseed pane. At the top is a graph of the share of cells that changed in each of the last 512 generations, on a log scale, with the settled thresholds in orange, automatic reseeds in pink and reseeds by hand in blue; beside it are the current activity, the population and the generation.

Presets install a ready-made set of policies with one click. Their drop counts are tuned for a grid of 200 × 140 squares and scaled to the size of yours:

Type a name and press Save as preset to keep the current policies as a preset of your own (saved in the app’s settings and shown with a ★); Delete… removes one.

Automatic policies lists the policies, each with a checkbox that switches it on and off, its mode and settings, the Sign when a JACA field is involved, When (Settled, with Activity below, Repeating up to, Exact period up to and Anyway after; or Every N gens, and Continuous for every 3 generations), the Cooldown, and which automaton it reseeds. Each shows how often it has fired. Add policy and Remove all do what they say. Your edits are applied a moment after you stop changing them, as one logged command, so they are saved with the scene.

Seed → Auto reseed switches all the policies on or off at once; when there are none, it installs a preset: Screensaver, unless you choose another (one of yours too) under Seed → Auto reseed installs in the pane’s presets.

From the command line

jetcarp run --reseed installs policies before the run: one policy as a JSON object, or a list. The mode and the trigger can be given by name, with their defaults ("rain", "settled"), or as objects with any of their settings. The report has a line per policy saying how often it fired, and --save keeps the policies in the saved scene, where jetcarp verify replays them.

In a script

let w = load_scene("life.json");
w.set_reseed([
    #{ mode: "blobs", when: #{ kind: "settled", latest: 2400 }, cooldown: 150 },
    #{ mode: #{ kind: "rain", drops: 3 }, when: #{ kind: "every", gens: 400 } },
]);
w.step(5000);
print(w.reseed_status());   // how often each policy fired, and recent activity
w.set_reseed([]);           // remove them

In a scene

A scene keeps its policies in its command log (a set_reseed command), or, to start with them, in its top-level reseed list. Written out in full, a policy looks like this:

{
  "mode": {"kind": "rain", "drops": 10, "min_size": 2.0, "max_size": 10.0, "density": 0.5},
  "when": {"kind": "settled", "activity": 0.002, "for_gens": 60, "cycle": 12, "latest": 2400},
  "ca": 2,
  "cooldown": 200,
  "enabled": true
}

Every field but mode and when may be left out. See Scene file format.

Reseeding and reproducibility

Which cells a reseed touches depends only on the tiling and the world’s random state, not on the cells’ current states, and the policies’ progress is part of the state hash. So a reseeded run gives the same hash at any thread count and on the CPU or the GPU, and settled policies are checked only every 16 generations so that the GPU can run whole batches between checks (see Reproducibility).

Screensavers and rotations

A screensaver profile can carry reseed policies of its own, which replace the scene’s while it shows; their drop counts are scaled to the size of the screen’s grid, as the presets are. A rotation can give its items reseed policies, or none at all.

Wallpapers, screensavers and the background host

JETCARP can keep cellular automata running on your screen in four ways:

• Screensaver mode in the app fills the screen (or several) with a scene until you press Esc. It runs while the app is open.
• The background host is a separate program, jetcarp host, that keeps scenes running with no app window: in a window of its own, or as the live desktop background behind your windows. It can start at login.
• The system’s screen saver. On Windows and macOS, JETCARP can be added to the system’s own list of screen savers. GNOME has no such list; JETCARP’s lock-screen mode does the job there.
• Still wallpapers, pictures cut to fit your monitors, are covered in Pictures and animations.

What any of these shows is a screensaver profile, a rotation (a list of items that change over time), a scene file or a Quick Start entry. For a first, step-by-step setup, see Your first live wallpaper.

What works on which system

None of this needs administrator rights: everything JETCARP sets up lives in your own folders and settings, and Uninstalling undoes it.

What has been tested

These features were tested by hand in November 2026 on three machines, on the code of JETCARP’s predecessor CART just before it took its present name. The renamed program has not yet been tested on these machines again.

• Fedora 44, GNOME 50.6 on Wayland, one monitor: the live desktop background, the top-bar menu, and the lock screen in both modes, including unlocking with a real password and stopping the host by force while locked (GNOME’s own background came back and unlocking still worked). Several monitors have only been tried in a headless GNOME session. Since those tests, the part of the extension that keeps the host’s windows out of the overview and the window switcher has been rewritten, and the new version has not yet been tested in a real GNOME session.
• Windows 11 Home (version 26H2) on a laptop with two graphics adapters, with and without a second monitor: the live desktop background under the icons (including after Explorer restarts and after a change of display scaling), the screen saver (install, preview, starting after the idle time, removal), the still picture, sleep, and the pauses on battery and when busy.
• macOS 27.0.1 on an M2 Max MacBook Pro, with and without an external monitor: the live desktop background, the screen saver (preview, starting after the idle time, two screens, sleep while it runs, removal), sleep with the lid closed, the still picture on one screen, and the pauses on battery and when busy.

Not tested yet: starting at a real login on any of the three (the entries are written and removed correctly, but no one has logged in with them), a fresh boot on Windows, Linux desktops other than GNOME, Intel Macs, and any other versions of these systems.

Screensaver mode in the app

View → Screensaver mode (F12), or Start the screensaver in the Screensaver pane, hides every control and runs the screensaver; Esc leaves it. It runs full screen on the app’s monitor, or on the monitors chosen in the Display pane.

View → Screensaver settings… opens the Screensaver pane:

• Show chooses what it runs: One profile, A rotation, The current world, A scene file or A Quick Start entry (such as rule:B3/S23).
• While it runs has the caption (Show what is running (the rule and the grid), its corner, size, whether it includes the generation count, and how long it stays up after each new item; press I while the screensaver runs to show or hide it), Keep the computer awake while it runs, Leave on any key or mouse movement (else Esc only), Hide floating and popped-out windows, Start AI control, and Hide the pointer after a delay.
• Background host controls the host (see below).
• Profiles lists and edits the screensaver profiles (see below).

The app can also start straight into screensaver mode, for example from a desktop shortcut:

jetcarp --screensaver --rotation "Wolfram series" --quit-on-exit
jetcarp --screensaver --profile Life --monitors 0,1 --span --cell-px 3 --caption
jetcarp --screensaver --quickstart rule:B3/S23 --keep-awake

--scene FILE shows a scene, --mirror shows the same view on every monitor instead of one canvas across them (--span, the default), and --quit-on-exit closes the app when the screensaver ends. jetcarp --help lists every option. A running app with control switched on (Tools → AI control… or jetcarp --control) can be steered from a terminal with jetcarp app screensaver on --profile NAME, jetcarp app next, jetcarp app profiles and the other jetcarp app commands.

Screensaver profiles

A profile is a named, complete setup for the screensaver: what to show (a scene kept in the profile, a scene file or a Quick Start entry), and optionally a palette and colouring for every automaton, reseed policies that replace the scene’s own, the cell size in pixels, whether to rebuild the tiling to fill the screen, the speed, the GPU simulation, and how many minutes it gets in a rotation. JETCARP has eleven built in: Life, HighLife, Day & Night, Hexagonal Life, Brian’s Brain, Star Wars, Triangles, Snub square Life, Penrose waves, Cyclic spirals and Hodgepodge.

To make your own, set up a world as you like it and press Save current world as profile, or select a profile and change it in the editor below the list. The easiest way to tune one is to press Try in this window, adjust it with the Reseed pane, the palettes and the Run menu, and then press Update from the current world. Tune for this rule runs small copies of the profile’s world with each of the reseed presets and scores how lively each keeps it. Editing a built-in profile saves your own copy under the same name; Revert to built-in goes back.

Profiles are JSON files, one each, in the screensavers folder of the settings folder (see Folders). Export… saves one to share, Import… adds files, and Reload reads them again after editing them by hand.

The background host

The host runs as its own program, so its scenes keep going when the app closes, and only one runs at a time. It shows one or more screens, each running a rotation either in a window or as the desktop background, on a chosen monitor or across all of them.

Start and stop it from the Background host section of the Screensaver pane (Start, Stop, Pause, and ◀ ▶ for the previous and next item), from its menu, or from the command line:

$ jetcarp host start --rotation "Wolfram series"
running, pid 676359, up 0.0s, 90 MB, GPU AMD Radeon 8060S Graphics (RADV STRIX_HALO)
screen 0: Wolfram series · W0 (1 of 256) · generation 4 · 57600 cells
$ jetcarp host next
running, pid 676359, up 3.0s, 90 MB, GPU AMD Radeon 8060S Graphics (RADV STRIX_HALO)
screen 0: Wolfram series · W1 (2 of 256) · generation 198 · 57600 cells
$ jetcarp host stop
stopped

The settings are saved in host.json in the settings folder. The app and the command line both write it and tell a running host to read it again, so a setting changed while the host is stopped applies the next time it starts (saved; the host is not running). Besides pausing on battery and when busy, the host also pauses by itself while its desktop background is completely hidden behind other windows and while the screen is locked and dark. jetcarp host status --json shows what it is holding for, under held.

On Windows and macOS the host has an icon in the notification area or the menu bar, and on GNOME the extension adds one to the top bar. Its menu names what is showing and has Next, Previous, Paused, Show on the desktop, Rotation, Open JETCARP, Start at login and Quit (on GNOME, also Start JETCARP host while it is stopped).

The live desktop background

Tick Show on the desktop in the Background host section, or run jetcarp host wallpaper on. To put different rotations on different monitors, set up one screen per monitor:

jetcarp host wallpaper on --screen 0 --monitor 0
jetcarp host wallpaper on --screen 1 --monitor 1 --rotation "Classics, hourly"

jetcarp host status lists the monitors by number. A screen given no monitor fills every monitor no other screen claims, and jetcarp host wallpaper off turns the screens back into windows.

GNOME needs JETCARP’s GNOME Shell extension, JETCARP live desktop, which shows the host’s windows as the background of the desktop, the overview and the lock screen, and adds the top-bar menu. It supports GNOME Shell 50.

jetcarp host gnome install    # copy it into place and switch it on; log out and back in once
jetcarp host gnome status     # "The GNOME extension is running."
jetcarp host gnome remove

The Background host section shows the same status, with an Install button. Without the extension the host shows a plain window and says why, so nothing is left covering the desktop. The extension only places copies of the host’s picture in GNOME’s background; it takes no part in unlocking, and if the host stops, GNOME’s own background comes back.

On the lock screen (jetcarp host lock, or On the lock screen in the app) the choices are off (GNOME’s own background), live (the default: the scene, blurred behind the clock, with GNOME fading the screen to black as usual) and screensaver (the scene stays sharp and lit until someone reaches for the password box). In screensaver mode the screen and the computer stay awake while locked; --awake MINUTES (default 30, 0 for never) lets the screen go dark after that long.

Windows: the host puts a window of its own under the desktop icons, one per monitor, with no extension needed. macOS: one borderless window per monitor at the desktop’s level, behind the icons, on every Space and ignoring the mouse; the host has no Dock icon while it shows only wallpaper. Other Linux desktops are not supported yet: the host shows a window instead.

A still picture. With jetcarp host still on (Leave a still picture when it stops), the host sets a picture of its scene as the desktop’s own background when it stops, and while the live one cannot be shown, through the system’s own setting. Your own picture is remembered and put back when the still or the live background is turned off, unless you have chosen another picture in the meantime. It is off by default.

The system’s screen saver

jetcarp host saver install adds JETCARP to the system’s list of screen savers and opens the system’s screen saver settings, with JETCARP to choose. --rotation NAME chooses what it runs (otherwise the first screen’s rotation); in the app, the same choice is Screen saver runs, with an Install button. jetcarp host saver status says whether it is installed, and remove takes it out.

• Windows. A copy of JETCARP’s windowless launcher is made at %LOCALAPPDATA%\JETCARP\JETCARP.scr and selected in Screen Saver Settings, as right-clicking a .scr file and choosing Install would. It reads JETCARP’s settings each time it starts, so changes apply at once, and its Settings button opens the JETCARP app. It needs jetcarpw.exe, the windowless launcher, beside jetcarp.exe; a build from source makes it with cargo build --release -p jetcarp --features windows-launcher. Removing it also clears the selection if JETCARP was the chosen screen saver.
• macOS. macOS runs screen savers in a sandbox that cannot read JETCARP’s settings, so installing builds ~/Library/Screen Savers/JETCARP.saver with the rotation and every item’s scene copied inside it, signs it for this machine, and opens System Settings where screen savers are chosen (System Settings, Wallpaper, Screen Saver… on macOS 27). Install it again after changing the rotation. It needs libjetcarp_saver.dylib beside the jetcarp program; a build from source makes it with cargo build --release -p jetcarp-saver.
• GNOME has no list of screen savers. Use the lock screen’s screensaver mode instead: jetcarp host lock screensaver --awake 30.

Start at login

jetcarp host login on (or Start at login, in the app or the host’s menu) makes the host start when you log in; jetcarp host login off stops that. It uses each system’s own per-user mechanism:

The entry runs jetcarp host serve (on Windows through jetcarpw.exe when it is there, so no console window opens) at the path the program has now. If you move the program, turn the setting off and on again. A host already running is left alone.

More: Rotations, Reseeding, Folders and Uninstalling.

Rotations

A rotation is what the screensaver or the background host shows over time: a list of items, each a screensaver profile, a scene file, a Quick Start entry or a whole series of rules, played in order, shuffled, or one a day. Each item has the conditions that end it, such as a number of minutes, the world settling, or a time of day, and can be limited to certain days and hours. A rotation can also have a short script that decides when to move on. This guide covers the built-in rotations, using one, and making your own.

The built-in rotations

Use a rotation

• Screensaver mode in the app: in the Screensaver pane, set Show to A rotation and choose it under Rotation, or start the app with jetcarp --screensaver --rotation "Wolfram series".
• The background host: choose it under Rotation in the pane’s Background host section, or run jetcarp host rotation "Classics, hourly" (add --screen N for one screen of several). jetcarp host start --rotation NAME runs one for that run only.
• The system’s screen saver: jetcarp host saver install --rotation NAME, or Screen saver runs in the app. On macOS the rotation is copied into the screen saver, so install it again after changing the rotation (see Wallpapers).

While a rotation runs, the ◀ and ▶ buttons in the pane, Next and Previous in the host’s menu, jetcarp host next and previous, and jetcarp app next for the app’s screensaver skip between items. A rotation that names an item that no longer exists (a deleted profile, say) leaves it out; one that cannot be found at all shows Life instead.

Make a rotation in the app

In the Screensaver pane, set Show to A rotation. Under the rotation’s name are Edit, New, Duplicate and, for one of your own, Delete (for an edited built-in rotation, Revert to built-in). The editor has:

• Name, and Order: In order, Shuffled (a new random order each time through) or One a day (one item per calendar day, the next one tomorrow; it restarts if it ends during the day). Default sets the minutes for items with no ending of their own; untick it and such items run until something else moves on.
• Settings for every item: a cell size, a speed, a palette, whether periodic tilings are rebuilt to fill the screen, and No reseeding. These apply to every item that is not a stored profile.
• The items. Add profile, Add scene…, Add series (one item per rule, for example every Wolfram rule) or a Quick Start entry’s handle typed into the box (such as rule:B3/S23, langtons-ant, an atlas entry’s atlas:… or one of your own find:…; press Enter). Each item can be moved and removed, and has:
  • Ends (any of these), from Add ending: After minutes, After generations, When settled (the same test the reseed policies use, with an optional limit in generations), On low activity (under a share of cells changing, for a number of generations), When finished (a rows rule reaches the bottom, or nothing can change any more), and At a time of day. With no ending, an item takes its profile’s minutes, else the rotation’s default.
  • Hold: seconds to keep showing the finished world before moving on.
  • Only at certain times: the days of the week, and hours Between two times (which may cross midnight). Outside them the item is skipped.
  • Settings for this item, as above, for this item alone.
  • For a series: the Rules (a series name such as W or HexW, a template with {n}, or a list), the Tiling, From and To, and the Seed.
• Script: Add a script (see below).

Save keeps it, Save and start runs the screensaver on it at once, and Close discards the edits. Editing a built-in rotation saves your own copy under the same name.

Rotation files

Each rotation of your own is a JSON file in the rotations folder of the settings folder (see Folders), so rotations can be written by hand, kept and shared. The app, the host and the Windows screen saver read the same files; the macOS screen saver gets a copy when it is installed. This one shows Brian’s Brain until it settles, then Langton’s ant for ten minutes, and from 10 pm to 6 am also the 256 elementary rules:

{
  "name": "Evenings",
  "description": "Brian's Brain until it settles, then a Langton's ant for ten minutes; the Wolfram rules at night.",
  "order": "in_order",
  "default_minutes": 5.0,
  "items": [
    {"source": {"kind": "profile", "name": "Brian's Brain"},
     "end": [{"kind": "settled", "latest": 20000}], "hold_s": 3.0},
    {"source": {"kind": "quick_start", "id": "langtons-ant"},
     "end": [{"kind": "minutes", "minutes": 10.0}],
     "look": {"cell_px": 4.0, "speed": 240.0}},
    {"source": {"kind": "series", "rules": "W", "from": 0, "to": 255},
     "end": [{"kind": "done"}], "hold_s": 3.0,
     "schedule": {"from": "22:00", "to": "06:00"},
     "look": {"cell_px": 4.0, "palette": "Ink"}}
  ],
  "script": "if s.population == 0 { \"next\" }"
}

An item has a source, which is one of {"kind": "profile", "name": …}, {"kind": "scene", "path": …}, {"kind": "quick_start", "id": …} and {"kind": "series", "rules": …, "from": …, "to": …, "family": …, "boundary": …, "seed": …} (a series becomes one item per rule, on a 200 × 140 grid of the family, square and dead edges by default). It may also have a label, a list of end conditions, a hold_s in seconds, its own look, and a schedule with days (mon to sun) and from and to times. The end conditions are {"kind": "minutes", "minutes": …}, {"kind": "generations", "gens": …}, {"kind": "settled", "latest": …} (latest optional), {"kind": "low_activity", "below": …, "for_gens": …}, {"kind": "done"} and {"kind": "clock", "at": "07:30"}.

A rotation’s script

A rotation’s script runs about once a second while the rotation plays. It sees a map s describing what is showing now, and a map state in which it can keep anything it likes between runs:

Its answer decides what happens: nothing (or "continue") carries on, "next" and "previous" move on, "reseed" reseeds the world now, a number goes to that item, and #{ item: "label" } goes to the item with that label. The script runs with tight limits on how much work and memory it may use, and its print output is discarded. New scripts start from this one:

// Runs about once a second. `s` describes what is showing, `state` keeps
// anything you like between runs. Answer "next", "previous", "reseed",
// an item number, or #{item: "label"}. Anything else just continues.
if s.generation > 20000 { "next" }

This is a different, much smaller language environment from jetcarp script: none of the scripting API’s functions are available in it.

More: Wallpapers, screensavers and the background host and Reseeding.

Searching for patterns

This page is being written.

The pattern library

This page is being written.

Packs: importing, exporting, checking

A pack is how JETCARP shares data: patterns, ant and turmite runs, Quick Start entries, search runs, pictures and ratings, in files that any program can read. Every file is named or listed by its SHA-256 hash, and every version is signed by its publisher, so whoever receives a pack can check that nothing was changed on the way and who made it. JETCARP also checks every pattern’s id against the pattern itself, and runs a sample of the patterns again before trusting them.

This guide covers checking and importing a pack you were given, then publishing and exporting your own. The files themselves are described in Pack format.

Stores and exports

A pack comes in one of two layouts, and every command here takes either:

• A store is a folder that keeps every version of one or more feeds. A feed is a named series of versions, such as penrose-finds. Files in a store are named by their hashes (objects/sha256/…), so a new version adds only the files that changed, and the store can be copied to any static web host as it is.
• An export is one version laid out with readable names for a single download: a README.md, a CITATION.cff, a LICENSE, the manifest pack.json, and the tables as Parquet files under tables/.

To send someone a pack, send the export folder, for example as a zip. JETCARP 0.4 imports from a folder, so unpack a zip or tar first.

Check a pack

jetcarp pack check reads a pack and checks all of it, without importing anything. It checks the format, the publisher’s signature, the hash and size of every file, and every id:

$ jetcarp pack check penrose-finds-2026.11
sha256:a968036b…: feed penrose-finds, by SHA256:yNFIDrcM3AiT87AjIHMwLfCRBHMOW4KZm5X6pwQx1A8 (Ada Example), checking every object
…
checked sha256:a968036b… (feed penrose-finds, SHA256:yNFIDrcM… Ada Example, signed by its publisher)
  9 objects checked (213869 bytes)

The first part is the version id: the hash of the manifest, which in turn lists the hash of every file. Two packs with the same version id are the same pack. The SHA256:… value is the publisher’s key fingerprint, the same form ssh-keygen -l prints. A name after it is one the publisher gave themselves, and nothing more: trust a publisher by their key, for instance one they list on their website.

If any file was changed, the check fails and says which:

Error: part sha256:d7762c49… is altered or truncated

A pack that its publisher didn’t sign is refused unless you add --allow-unsigned. A store with several feeds needs --feed NAME, and --manifest sha256:… picks a version other than the newest.

Import a pack

jetcarp pack import runs the same checks and then merges the pack into your library:

$ jetcarp pack import penrose-finds-2026.11
…
imported sha256:a968036b… (feed penrose-finds, SHA256:yNFIDrcM… Ada Example, signed by its publisher)
  9 objects checked (213869 bytes)
  patterns: 3 added, 0 merged, 0 flagged needs_reverify
  sightings 3, ratings 0, ants 0, Quick Start 0, media 0, searches 0, retracted 0
  verified again (sample): 3 of 3 passed, 0 skipped, 0 failed

What happens to each kind of record:

• Patterns are merged by id. A pattern you don’t have is added with its finder, the date it was found, and the publisher’s name, tags and notes for it. A pattern you already have keeps your own name, tags, notes, rating and state: importing never overwrites your curation, so a later version that renames a pattern changes nothing for one you already had. Sightings are counted per search, so importing the same pack twice changes nothing.
• Patterns from another engine version. A pattern whose tiling geometry or rule meaning differs from this version of JETCARP’s is kept and flagged needs_reverify. jetcarp library reverify checks it again.
• Sample verification. After merging, JETCARP runs 3,000 of the new patterns again (fewer if the pack has fewer), chosen at random but seeded by the version id, so the same pack always checks the same sample. --verify full runs every new pattern, --verify none skips this step, --sample N changes the sample size, and --verify-seconds S caps the time (600 by default).
• Search runs become a paused explore job, so jetcarp jobs status, jobs runs and the atlas work on them as on a search you ran yourself, and jetcarp jobs resume continues it.
• Quick Start entries appear in the Quick Start menu.
• Ratings are kept under each rater’s name, as the pack gives it.
• Retractions. A publisher can withdraw a record in a later version. Importing that version flags the record as retracted, with the reason, and never deletes your copy.

--strict refuses a pack that has two different rows for one record id, instead of keeping the first. --library FILE imports into another library file than your usual one.

JETCARP never runs code from a pack. A pack holds data. A scene’s script is a list of steps, naming which automata run and when to move on (Scene file format), not a program.

Your publisher key

Every pack you make is signed with your publisher key, an Ed25519 key that JETCARP keeps in its settings folder. jetcarp pack key makes one the first time and shows it after that:

$ jetcarp pack key
made publisher key SHA256:yNFIDrcM3AiT87AjIHMwLfCRBHMOW4KZm5X6pwQx1A8
  ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGPv65+hMLaYJAVXB/chf5oAx0smWQlLyOVymcinItHV jetcarp publisher
  file /home/ada/.config/jetcarp/pack/publisher_ed25519
  not named (packs show the key only; --name to be named)

Your packs show only the key until you give a name. --orcid and --github add those too, and they appear in each pack’s CITATION.cff:

$ jetcarp pack key --name "Ada Example" --orcid 0000-0002-1825-0097

The key is an ordinary OpenSSH key, so OpenSSH can check JETCARP’s signatures too. In an export’s folder, with the publisher’s public key in a file allowed as ada ssh-ed25519 AAAA…:

$ ssh-keygen -Y verify -f allowed -I ada -n jetcarp-manifest -s sigs/*.sig < pack.json
Good "jetcarp-manifest" signature for ada with ED25519 key SHA256:yNFIDrcM3AiT87AjIHMwLfCRBHMOW4KZm5X6pwQx1A8

Back up the key file. A new key is a new publisher: later versions of your feeds would be signed by a stranger. --key FILE signs with an OpenSSH Ed25519 key of your own instead.

Publish your library

jetcarp pack publish writes your library, or part of it, as a new version of a feed in a store. The store folder is made if it doesn’t exist:

$ jetcarp pack publish --to my-store --feed penrose-finds --title "Penrose finds" --version-label 2026.11
publishing feed penrose-finds (version 1) into /home/ada/packs/my-store
3 patterns read, 3 new rows
…
published penrose-finds version 1 into /home/ada/packs/my-store
  manifest sha256:a968036b954f740867edcd9387c4d87c2ef39424903975cbea85f570154db964
  publisher SHA256:yNFIDrcM3AiT87AjIHMwLfCRBHMOW4KZm5X6pwQx1A8
  patterns       3 rows added, 2 parts
  …
  49117 bytes in all

Run it again later and it writes version 2 of the same feed, storing only what changed. The feed’s file in refs/ names its newest version and is signed too.

Choose what goes in:

Describe it: --title, --description and --version-label (free text such as 2026.11) go into the manifest and the export’s README. --licence takes an SPDX id; the default is CC0-1.0, which puts the data in the public domain. --created fixes the version’s time (RFC 3339, UTC): with the same library, key and time, publishing gives the same version id, byte for byte.

Withdraw a record: --retract pattern:ID=reason lists it as retracted in this version and every later one. Earlier versions stay as they were, since every file in them is fixed by its hash, but anyone importing the new version sees the retraction and its reason:

$ jetcarp pack publish --to my-store --feed penrose-finds --version-label 2026.12 \
    --retract 'pattern:3dec1a434a261b937448693adbeab960=duplicate of a known still life'

Combine versions: --merge FOLDER (or FOLDER@sha256:… for one version) brings another store’s records into this version. Each keeps its original publisher.

Export a version

jetcarp pack export lays one version out for a single download:

$ jetcarp pack export --from my-store --to penrose-finds-2026.11
exported sha256:a968036b… into /home/ada/packs/penrose-finds-2026.11: 24 files, 222559 bytes

Without --from, it publishes your library first, taking the same options as pack publish, and exports the result. It keeps the store it made next to the export, in a hidden folder named after it, for example .penrose-finds-2026.11.store. Use --views to add a views.sql for DuckDB (see below).

The export’s folder:

Ratings and consent

Ratings are about people’s taste, so a pack includes only the ratings of raters who have agreed to a permanent public release. Record that agreement with jetcarp pack rater, using the name the library’s ratings give:

$ jetcarp pack rater "Ada Example" --show-name
Ada Example                              rater-17935ea8ceb8a90a  consented 2026-11-12T02:14:37Z, named

• Without --show-name, a pack lists the rater only by a pseudonymous id such as rater-17935ea8ceb8a90a.
• --notes lets their notes go in too.
• --orcid adds an ORCID for a named rater.
• --withdraw takes the consent back: later packs leave that rater’s ratings out. Versions already published can’t be changed.
• A group rating, made by several people together, goes in only when every member has consented.

Your own curation (the names, tags, notes, star ratings and states you give patterns) is different: it goes into your packs as your annotations, signed with your key.

Read a pack without JETCARP

An export is plain Parquet and JSON, so any data tool can read it. With DuckDB, in the export’s folder:

$ duckdb -init views.sql
D SELECT id, class, period, cells FROM patterns ORDER BY cells;

Polars and pandas read the same files, with read_parquet on a table’s folder. JETCARP’s source repository also holds an independent reader in Python (tools/jetcarp_pack), written from the format description alone. It checks hashes, signatures and ids, at the conformance levels the format defines.

Share a pack

A store or an export is a folder of ordinary files, so any way of moving files works: a zip by email, a static web host, a Git repository with Git LFS, or a data repository such as Zenodo or Hugging Face. To publish a feed for others to follow, copy the whole store to a web host and give people the address. Copy it again after each new version: files already there never change, so only the new ones need uploading.

JETCARP 0.4 doesn’t download packs itself: download the folder first, then import it. Fetching feeds from an address and following them for new versions are planned for a later version.

Pictures and animations

JETCARP draws every picture with its own renderer, straight from a world, so a picture shows the tiles in their true shapes at any size. This guide covers still pictures of a world, desktop wallpapers cut to fit your monitors, animations, and contact sheets that put many runs side by side. Most still pictures carry their scene inside the PNG, so a picture can always be traced back to the run that made it (see Scenes).

A picture of the world

In the app, File → Export PNG… (Ctrl+E) saves the whole tiling as a PNG; the menu shows the size it will be, such as Export PNG (2400 × 1600)…. Export size, just below it, sets the scale: fit gives 2400 pixels on the longer side, and a number gives that many pixels per tile (up to 64). Large images are written in strips, so they need little memory. Tile outlines are drawn where tiles are at least 7 pixels across.

On the command line, jetcarp run writes a picture of the state it ends in:

jetcarp run scene.json --gens 500 --png out.png                # 1600 pixels on the longer side
jetcarp run scene.json --gens 500 --png big.png --max-side 8000
jetcarp run scene.json --gens 500 --png exact.png --scale 6    # 6 pixels per world unit

A tile edge is about one world unit, so --scale 6 gives tiles about six pixels across. Very large pictures (a small scale on a huge grid) are streamed in strips too.

In a script, w.save_png(path) draws the world at the screen size given by --screen (1920 × 1080 by default), fitted and centred. Its options set the size ([w, h]), scale, max_side, outlines, a palette for this picture only, and the compression (fast, balanced or high); it returns the path, the size and the number of bytes.

Desktop wallpapers

A wallpaper is a picture at exactly the size of a monitor, or of several monitors side by side.

In the app, File → Export wallpaper… opens a window that writes desktop-sized PNGs of the world while the app keeps running:

• Size: one of your monitors (as detected), All monitors as a span, a preset, or Custom size. For a span, Layout gives each monitor as WIDTHxHEIGHT+X+Y (the way xrandr prints it; Detected fills in yours), and Write chooses One span image, One per monitor (cut so that they line up across the gaps) or Both.
• Fit: Cover (the grid fills the image and is cropped, so no stage colour shows), Contain (the whole grid, letterboxed in the palette’s stage colour), Current view (what the grid view shows now, scaled to the image) or Repeat (a grid with wrapped edges, tiled seamlessly over the image at a chosen tile size).
• Grid: Fresh grid sized for the image builds a new grid of the same tiling, with this world’s automata and seeds, big enough to fill the image at a given number of pixels per tile, and runs it for a given number of generations first (on the GPU if you like). The live world is left alone; Open the fresh grid afterwards replaces it with the new grid if you want to keep it.
• Outlines (Tile outlines when tiles are at least so many pixels across), Palette (as the automata are, or one palette for all), and the Folder (Choose…; by default the wallpapers folder of the output folder). Then Export, and Open folder to see the result.

On the command line, jetcarp wallpaper takes a scene file or a Quick Start id:

$ jetcarp wallpaper life --size HD --gens 200 -o life.png
life.png (1920 x 1080)
$ jetcarp wallpaper life --monitors 2560x1440+0+0,1920x1080+2560+180 --split --gens 100 --palette Glacier
/home/ada/Pictures/JETCARP/wallpapers/Life-on-the-square-grid-1-2560x1440-2026-11-10_18-28-08.png (2560 x 1440)
/home/ada/Pictures/JETCARP/wallpapers/Life-on-the-square-grid-2-1920x1080-2026-11-10_18-28-08.png (1920 x 1080)

jetcarp --json quickstart lists the built-in Quick Start entries with their ids (such as life or langtons-ant); entries of your own are find:… and the atlas’s atlas:…. To show a wallpaper that moves, see Wallpapers, screensavers and the background host.

Animations

jetcarp media render makes a set of media: a PNG frame for every step, an animation, a poster frame and a thumbnail.

$ jetcarp media render --scene docs/scenes/automata/turmite-llrr.json --gens 120 --every 2 --no-frames --out llrr
webp   llrr/anim.webp
poster llrr/poster.png
thumb  llrr/thumb.png

• What to render. --scene FILE renders any scene from its first generation; without --out, the files go to media/<file name> in the output folder. --quickstart ID with a built-in Quick Start entry’s id or number (as jetcarp quickstart lists them) renders that entry’s scene the same way, into media/<id> without --out. The other targets come from the pattern library: --pattern ID (a catalogued pattern, shown alone), --quickstart HANDLE (one of the library’s own Quick Start entries: find:ID under My finds, atlas:…, or a pack’s qs-…), --ant ID (an ant run) and --missing (everything in the library whose media are missing or out of date, limited with --class, --only-patterns, --only-quickstart and --limit). Their media are kept in the library’s media folder, each file once under the SHA-256 of its bytes (see Library format), and rendered again only when something has changed (--force renders anyway). jetcarp media list KIND ID lists a record’s files with their paths, jetcarp media export KIND ID --to DIR copies them into a folder as frames/0000.png…, anim.gif, poster.png and thumb.png, and jetcarp media gc deletes the files no record uses any more (--dry-run lists them first).
• How. A pattern alone is shown on an empty field for --periods full periods (default 1), so the animation loops seamlessly; a spaceship’s window moves with it. From the seed, the whole grid runs for --gens generations (default 200; row rules one frame per row), with a frame every --every generations. --mode overrides the choice.
• Format. With --format auto (the default), the animation is a GIF when each frame is at most 320 × 320 pixels, the whole animation at most 8 million pixels and 256 colours, and an animated lossless WebP otherwise; --format gif and --format webp choose one. --no-frames skips the per-step PNGs.
• Look. Media have a house style: a fixed set of colours for each kind of field, cells coloured by state and never by age (so loops close), outlines where tiles are at least 8 pixels across, whole pixels per cell, about 320 pixels across for a pattern alone and 512 from the seed, and no text. --palette NAME uses a palette instead. Media files do not carry the scene inside them.

In a script, w.media(#{ gens: 200, every: 2 }) renders a world from its current state into a new media folder, and media(#{ pattern: id }) renders library media, with the same options as the command. The animations in this book are made from their scenes by a separate tool, docs/tools/render-animations.sh, which uses Python to crop and label the frames.

Contact sheets

A contact sheet lays many small pictures out in a grid, each labelled, to compare rules at a glance.

• Elementary and hexagonal row rules. File → Export contact sheet… draws the world’s first row rule and the rules after it (64 of them, or all 16 binary hexagon rules) in its palette, and Contact sheet… on an automaton’s card in the CAs pane does the same for that automaton’s rule. From the command line, jetcarp sheet --kind w --from 0 --count 64 --png sheet.png does the same for any range, with --cols, --thumb (pixels per thumbnail), --width (cells across each), --random-row DENSITY (start from a random top row instead of one cell) and --palette. The kinds are w (rules 0 to 255), hexw (0 to 15), hexw3 (0 to 19,682), hext (0 to 255), hext3 and hext3sum (see Hexagonal row rules).
• Sweep folders. jetcarp sheet --folder FOLDER --runs "#12,#40,n=588" --png picks.png lays out chosen runs of a sweep, each under its label (--labels) and rule.
• Quick Start. jetcarp quickstart --sheet sheet.png draws every built-in entry, numbered as jetcarp quickstart lists them, after --gens generations (default 300); --filter TEXT keeps the entries whose name, rule, family or tiling contains the text.
• Isohedral types. jetcarp isohedral --png sheet.png draws all 81 types (see Drawing and editing tiles).

The exploratory search makes contact sheets of its own for reviewing what it found (see Search methods).

Other pictures

• jetcarp hashlife … --png draws a pattern far in the future: with JETCARP’s renderer up to --max-cells cells (16 million by default), and as a density map beyond that (see HashLife and very long runs).
• jetcarp objects scene.json --png objects.png colours each object of a world by its class: still life, oscillator, spaceship or other.
• jetcarp library render ID --png draws a catalogued pattern’s phases side by side (see The pattern library).
• jetcarp pile draws a large sandpile (see Large sandpiles).

The still figures in this book are made with jetcarp run --png and the contact-sheet commands, from the scene named under each, by docs/tools/render-figures.sh.

Large sandpiles

jetcarp pile drops N grains of sand on one tile of an unbounded grid and lets them settle, for N from one to 2⁶⁴ − 1, on any tiling: the regular grids, every periodic tiling in the catalogue, and exact patches of the aperiodic ones. It draws the settled pile as a picture, records how it grew, and saves its progress so a pile that takes hours can be stopped and carried on. The method (it never builds a tower of N grains, but doubles a smaller pile again and again) is explained under Very large piles in the sandpile chapter.

Build a pile

$ jetcarp pile --grains 1e6
pile job 1 in /home/ada/.local/share/jetcarp/library.sqlite
pile 1: 1000000 grains on square, step 16/20 (62500 grains), 4.633e7 topplings, 2.8 s; step 17 running 3.0 s
pile 1: 1000000 grains on square, step 18/20 (250000 grains), 7.321e8 topplings, 7.0 s; step 19 running 4.0 s
pile 1: 1000000 grains on square, step 19/20 (500000 grains), 2.909e9 topplings, 15.7 s; step 20 running 1.0 s
done: 1000000 grains, 11583796400 topplings, 296811 sweeps, 20.6 s of toppling
image:   /home/ada/Pictures/JETCARP/piles/2026-11-11_21-20-08_square-1000000/pile.png
preview: /home/ada/Pictures/JETCARP/piles/2026-11-11_21-20-08_square-1000000/preview.png
folder:  /home/ada/Pictures/JETCARP/piles/2026-11-11_21-20-08_square-1000000
job:     1

A million grains take 20 steps, one for each binary digit of 1,000,000, and each step is about four times the work of the one before. N can be written 1000000, 1e7 or 2^30.

On the GPU, --gpu topples periodic tilings on the graphics card. It gives the same pile, and on the desktop these numbers come from (a Radeon 8060S), a million grains on squares took 1.7 seconds instead of 20.6 on 32 CPU threads. Aperiodic tilings are toppled on the CPU.

The pile is the same however it is built: on the CPU or the GPU, with any number of threads, in one run or resumed many times.

The pile’s folder

Each pile gets a folder under <Pictures>/JETCARP/piles/, named after when it started, its tiling and its grains (--out DIR puts it elsewhere):

The step files are small, because a settled pile holds at most a few grains per tile: the folder of the million-grain pile above is 592 KB in all. --no-png skips the full-size picture of a pile too big to want one.

Colours

Heights run along a palette: height 1 at its first stop and the tallest at its last, with empty tiles in its background colour. The default is Ember. --palette NAME picks another (jetcarp palettes lists them, or give hex colours), and --reverse runs it the other way. See Palettes and colouring.

To recolour a pile after it is built, open it in the app’s sandpile window (below), choose the colours, and use Write pile.png, preview.png, and pile.json in these colours.

Stop and carry on

Every pile is a job in your library, like a search, so the usual job commands work on it:

$ jetcarp pile --grains 1e9 --gpu --minutes 0.25 --label big
…
pile 5: 1000000000 grains on square, step 22/30 (3906250 grains), 1.750e11 topplings, 13.5 s
pile 5 paused (at its budget); `jetcarp jobs resume 5` resumes it exactly

$ jetcarp jobs list
    5  pile     paused   2026-11-12T02:21:08Z  pile 5: 1000000000 grains on square, step 22/30 (3906250 grains), 1.750e11 topplings, 13.5 s
    …

• --minutes M or --until UNIX-TIME stops it after a while, and jetcarp jobs stop JOB or Stop in the app stops it at once.
• jetcarp jobs resume JOB carries it on. So does jetcarp pile --resume JOB-OR-FOLDER, which keeps the pile’s settings and ignores the other options. Add --gpu to resume on the GPU again: it is chosen for each run, not stored with the pile.
• --detach runs the pile in a process of its own and returns at once, so jetcarp jobs status JOB can follow it.

A pile resumes from its last finished step. A step stopped part way is run again from the start, and steps get long: the last few steps of a billion-grain pile each take minutes. So give a run long enough to finish its step. Once two steps have run, jetcarp jobs status and the app show an estimate of the time left.

In the app

Tools → Large sandpile… builds the same piles. It has the options above, draws the pile as it grows, and shows each step’s progress and the time left. Stop (resumable) stops the pile, and Resume carries it on from its last finished step; a pile stopped elsewhere (from the command line, or the Hunts… window) can be resumed there too.

From scripts and other tools

The same piles are jetcarp search pile (the pile as a search strategy, taking the same options), sandpile_pile(#{ … }) in Rhai scripts (see Scripting), and the MCP server’s search tools (see MCP tools).

HashLife and very long runs

HashLife, Bill Gosper’s algorithm of 1984, jumps a pattern millions or trillions of generations ahead in a moment. It cuts the plane into blocks, remembers how each block evolves, and treats equal blocks anywhere in space and time as one, so a pattern that is regular, such as a glider gun and its stream, costs almost nothing to run far ahead. JETCARP’s HashLife was written for it from the published algorithm, and it works on every periodic tiling, not just the square grid. This guide covers what HashLife can run, the two ways of jumping, the HashLife view window, the jetcarp hashlife command, scripts, and what to do for long runs HashLife cannot help with.

What HashLife can run

• Tilings: any periodic tiling. Each unit cell of the tiling is one site of HashLife’s lattice, holding the states of all its tiles, so the square grid (with either neighbourhood), hexagons, the Archimedean and k-uniform tilings, the isohedral types and the editable families all work. The aperiodic Penrose, hat and spectre tilings have no lattice, so they do not.
• Rules: those whose next state depends only on a cell’s own state and how many neighbours are in state 1: Life-like rules and Generations rules (rules with B0 included), WireWorld and Greenberg–Hastings. A world may have several such automata, on shared or separate fields. Any other rule is refused by name.
• Ages are not kept. After a jump every live cell has age 1, so age colouring starts over, and the world’s state hash differs from that of a world stepped the same distance even though every cell matches. Compare the hash of the cell states alone: w.states_hash() in a script, cells_hash in the world status, or --compare on the command line.
• Limits: jumps of up to 2⁶² generations, and up to 65,536 different states per site (the number of states raised to the number of tile types in the unit cell). Memory is kept in check by a cap on the number of stored blocks (48 million by default, about 2 GB), beyond which unused blocks are cleared out; that never changes the result.

Two ways to jump

On the unbounded plane. The world’s live cells are taken out of their grid and run on an infinite plane, ignoring the grid’s edges, and the result is brought back as a new world: by default the same frame as the original, or any region of the plane. This works for any qualifying world on a periodic tiling.

In place, on a torus. A world with wrapped edges whose width and height, in unit cells, are both powers of two (such as 256 × 128) is a torus that HashLife can advance exactly as stepping would. The jump is logged as a jump command, so the scene replays it. A world with dead or live edges, or with a sequence installed, cannot be jumped in place.

In the app

Run → Jump opens a small menu with a Generations box, which takes a number or a form such as 2^40 or 1e6, and three choices:

• Jump ahead (HashLife) jumps the world in place. When the world does not qualify, the button is greyed out and hovering over it says why (for example, HashLife needs a torus whose sides are powers of two (this one is 200 × 140 unit cells)).
• On the unbounded plane shows the same frame after that many generations on the plane, as a new world named after the old one (… +1000000 (HashLife plane)).
• HashLife view… opens the pattern on the plane in a window of its own, also under Tools → HashLife view…. Opening it pauses the world.

In the HashLife view, type a number of generations and press Jump, or +1 for one more. Drag to pan and scroll to zoom about the pointer; Fit frames the whole pattern, and − and + halve and double the zoom. Colours uses the world’s palette or any other. The line under the toolbar gives the generation, the number of live sites, the pattern’s extent in unit cells and the zoom. The view draws straight from HashLife’s blocks at the level where one block is about one screen pixel, so zoomed out it is as fast after 2⁴⁰ generations as after 100; zoomed in, every tile is drawn in its real shape. Jumps run in the background while the window shows the last frame.

On the command line

jetcarp hashlife takes a scene, a record exported from the pattern library, or a pattern in RLE or plaintext. A Gosper glider gun, 2⁴⁰ generations on:

$ jetcarp hashlife gosper.rle --gens 2^40 --png gun.png
input:      gosper.rle
mode:       plane (square B3/S23)
generation: 1099511627776 (+1099511627776 in 0.008s)
population: 183251938004 (was 36)
bounds:     i 0..274877906961, j 0..274877906948 (274877906962 × 274877906949 unit cells)
nodes:      9277 live, 9277 peak, 0 collections
region:     i0 -8, j0 -8, 274877906978 × 274877906965
png:        gun.png (1025x1025, density map)

On the plane, the options choose what to export: --region i0,j0,w,h (in unit cells), or world for the source scene’s own frame (the default is the pattern’s bounding box plus --margin, 8), and --boundary for the exported world’s edges. --save FILE writes the region as a new scene, which starts at generation 0 with every cell at age 1 (it has no recorded hash, so run it with jetcarp run rather than jetcarp verify). --png FILE draws it with JETCARP’s renderer up to --max-cells cells (16 million) and as a density map above that, in --palette, at most --max-side pixels. --rule overrides the rule (RLE files default to their header’s rule, else B3/S23).

--torus jumps a scene in place instead, and --compare cpu (or gpu) also runs the ordinary engine and checks that every cell agrees:

$ jetcarp hashlife torus.json --torus --gens 5000 --compare cpu
input:      torus.json
mode:       torus (Square (parallelogram) (square): 65536 cells, 256x256 unit cells, 1 tile type(s), storage dense, edges wrap)
generation: 5000 (+5000 in 0.200s)
population: 1969
states:     730e938cfe04df96
hash:       4cd23522a2a2780b
nodes:      71640 live, 71640 peak, 0 collections
compare:    cpu (32 threads) 3.539s, states equal

Saved with --save, a torus jump keeps the jump command in the scene’s log, so jetcarp verify replays it. --node-cap changes the number of stored blocks before a clear-out, and --leaf-level (at most 6) how large a block is stepped directly by a fast bit-parallel stepper for Life-like and Generations rules without B0; neither changes the result.

In a script

let w = world(#{ tiling: "square", size: [256, 256], boundary: "wrap", rng_seed: 1 });
w.add_ca("B3/S23", #{ seed: "random:0.3" });
print(w.can_jump());           // true, or the reason it cannot
w.jump("2^20");                // in place, logged as a jump command
print(w.states_hash());
let later = hashlife(w, 1000); // on the plane: a new world, same frame and edges

hashlife(w, n, #{ region: [i0, j0, w, h], boundary: "dead", node_cap: 48000000 }) chooses the region and edges of the result; region: "fit" with margin takes the pattern’s bounding box. See Scripting (Rhai) API.

Long runs HashLife cannot help with

HashLife needs regularity and a lattice. For everything else:

• Run headless. jetcarp run scene.json --gens N runs as fast as the machine allows, with no drawing, on all cores; --gpu steps on the graphics adapter where the rules allow it, with an identical result. In the app, Run → Max speed and Run → GPU simulation do the same.
• Save and carry on. jetcarp run … --save records where a run got to, and running the saved scene again continues from there.
• Large sandpiles have their own method, which builds a pile of any size by doubling (see Large sandpiles).
• Movers on aperiodic tilings can be followed for millions of tiles on a sliding window that is built around them as they go (see Aperiodic patches and following movers).
• Searches run as resumable jobs, so they can run for days and survive restarts (see Searching for patterns).

HashLife was described by R. Wm. Gosper in “Exploiting regularities in large cellular spaces” (Gosper 1984). JETCARP claims nothing new about the algorithm itself.

Aperiodic patches and following movers

The Penrose, hat and spectre tilings never repeat, so they cannot be wrapped into a torus the way a periodic grid can. JETCARP builds finite patches of them instead, round pieces of the infinite tiling chosen by level, with dead edges. A pattern that travels across one of these tilings, a mover, soon reaches the edge of any patch. To see how far it really goes, JETCARP follows it on a sliding window: only the tiles near the live cells exist, and the window is rebuilt ahead of the pattern as it moves, so the memory needed depends on the window, not on the distance. This guide covers patches and their levels, running rules on them, and following movers.

Patches and levels

For the hat and both Penrose tilings, a level is a size: the given number of tiles nearest a fixed centre, so patches are round and each contains the smaller ones. For the spectre, a level is a supertile level of its substitution. Levels 7 and 8 are built in exact integer coordinates, with every neighbour found by an exact lookup; level 8 has 17 to 18 million tiles and needs more than a gigabyte of memory with its neighbour graph. Each tiling’s page in the encyclopedia says how it is built.

Patches always have dead edges: cells past the edge are missing and count as empty, so patterns near the edge behave differently from patterns deep inside. The tiles have fixed shapes and cannot be edited, and the number of neighbours varies from tile to tile (jetcarp tilings lists the ranges: a spectre tile has 4 to 7 edge neighbours, a Penrose rhomb 7 to 11 touching ones).

In the app, choose the tiling under Tiling → Family (or in the Tiling pane), where the four aperiodic tilings have a group of their own, then the level under Size, which lists levels 3 to 8 with their tile counts (Level 4 (4,401 tiles)). A new aperiodic world starts at level 3. The Edges choice is greyed out.

In a scene the level is the size:

"tiling": {"family": "spectre", "size": {"level": 5}}

and in a script, world(#{ tiling: "hat", size: #{ level: 4 } }) or, for short, world(#{ tiling: "hat", level: 4 }). Levels 1 to 8 can be used in both.

Running rules on patches

Almost every rule family runs on the aperiodic tilings; only the few tied to a grid, such as the elementary row rules and von Neumann’s automaton, do not (see How JETCARP generalises automata). The Quick Start has examples, such as B2/S34 on the hat, Sandpile on the Spectre, Spectre glider and Brian’s Brain on Penrose rhombs. Searches work on patches too: the bounded soup search runs soups on a patch, and the evolutionary glider search evolves rules that make gliders on the spectre or the hat (see Searching for patterns and Search methods). HashLife does not, since these tilings have no lattice.

When you hover over the grid in the app, the bottom left corner shows the number of the cell under the pointer and its state in each field (cell 4071 · field 0: 1). Cell numbers are the tile numbers of the patch at that level, which is how the mover commands below name starting cells.

Following a mover

A glider on an aperiodic tiling never repeats exactly, since the tiles it crosses never repeat, so it cannot be proved to run for ever by finding its period. JETCARP measures instead how far it has been seen to travel unchanged, and calls it verified to a distance: so many rings of tiles (edge steps from the starting tiles to the nearest live tile), with the distance also given in neighbour steps and in plane units. There are two ways to follow one.

On a sliding window, as a resumable job, with jetcarp search mover:

$ jetcarp search mover --rule SpectreGlider --tiling spectre --rings 200 --store
mover job 1 in /home/ada/.local/share/jetcarp/library.sqlite
start: 4071:1,4097:3
mover 1: 200 rings of 200 (634 units) after 404 of 40000 generations, 11757 gens/s, 5821 rings/s, level 7, 603 tiles | verified to distance 200 edge rings (200 touching-neighbour steps, 633.6 units) over 404 generations on a sliding window of spectre (supertile level 7, at most 1009 tiles), population 2-12; stopped at the requested distance
library: 4b70f6b289a68075

The window never held more than about a thousand tiles. This is how JETCARP followed James Edmond’s Spectre glider pair for 10 million rings of tiles, and the hat glider for a million (see Findings).

Over fixed patches of growing level, with jetcarp library movers track, which runs the pattern on each patch from --level up to --max-level (7 on the spectre by default, where 8 is on request; the largest elsewhere) and checks that each level agrees with the one before:

$ jetcarp library movers track --rule SpectreGlider --tiling spectre --gens 3000
start: 4071:1,4097:3
verified to distance 224 edge rings (224 touching-neighbour steps, 708.2 units) over 451 generations on spectre level 7 (2147679 tiles), population 2-12; stopped at the edge of the largest patch
  level 4 (4401 tiles): 35 generations, Edge, 16 rings, population 2-12, 0.0s
  level 5 (34649 tiles): 35 generations, Edge, 16 rings, population 2-12, agrees with the smaller level, 0.1s
  level 6 (272791 tiles): 268 generations, Edge, 132 rings, population 2-12, agrees with the smaller level, 2.0s
  level 7 (2147679 tiles): 451 generations, Edge, 224 rings, population 2-12, agrees with the smaller level, 7.2s
  group of 5 cells at 712.0 units, heading 107.9 degrees
  group of 6 cells at 712.0 units, heading -131.7 degrees

Both commands take the same description of the pattern:

jetcarp search mover also takes --rings (stop, verified, at this distance), --margin (how much of the tiling to keep around the live cells, in plane units, default 24) and --fixed-levels (on the spectre, the window follows the same tiles as the fixed patches up to this level, default 8), and the options every search job has: --label, --minutes, --limit, --resume, --detach, --threads and --library (see Search methods). A run stops when it reaches the distance asked for, the generation limit or the edge of the largest patch, or early when the pattern dies, grows past the cell limit or repeats in place (then it is an oscillator, not a mover).

The library keeps movers with the distance they were verified to. jetcarp library movers list lists them, farthest first, and jetcarp library movers verify ID follows one again from where it was stored (20,000 generations by default) and updates its record.

In a script, track_mover(#{ rule: "SpectreGlider", tiling: "spectre", level: 4, cells: [[4071, 1], [4097, 3]], window: true, rings: 100 }) does the same and returns the report; without window it tracks over the fixed patches. library().query(#{ class: "mover" }) lists the stored movers (see Scripting (Rhai) API).

How the window stays exact

Every tile of the window is placed by an exact rigid motion in integer coordinates, so tiles built at different times match exactly and neighbours are found without rounding. Live cells are always kept at least three neighbour steps from the window’s open edge, so every cell that can change sees its true neighbours, and the run equals the run on the whole infinite tiling. The method is described in full in Search methods.

Website export

jetcarp site export turns the public part of your library into a folder you can put on any web host: one JSON file per pattern, ant run or Quick Start entry, its pictures and animation, a manifest.json that lists everything, and a viewer page, index.html, that shows it all as a grid. Run it again after curating and it writes only what changed and deletes what is no longer public, so the folder can be synced to a host as it is.

A website export is for people to look at. To give someone data they can import, check and build on, make a pack instead.

Export

$ jetcarp site export --to site
wrote   patterns/21e9bac2df7b770a5ff0f34bd68a514a.json
wrote   media/pattern/21e9bac2df7b770a5ff0f34bd68a514a/anim.gif
wrote   media/pattern/21e9bac2df7b770a5ff0f34bd68a514a/poster.png
wrote   media/pattern/21e9bac2df7b770a5ff0f34bd68a514a/thumb.png
…
wrote   manifest.json
wrote   index.html
site: 2 patterns, 0 Quick Start entries; 10 files written, 0 deleted, 0 items unchanged, 2 media rendered

Pictures and animations a pattern doesn’t have yet are rendered first, in the house style. Use --palette NAME (or hex colours) to render them in another palette, or --no-render to export only the media that already exist. They are the same files jetcarp media render makes (see Pictures and animations). --frames copies each animation’s frames as PNGs too.

Run the same command again and it compares each file’s hash with the copy already in the folder:

$ jetcarp site export --to site
site: 2 patterns, 0 Quick Start entries; 0 files written, 0 deleted, 2 items unchanged, 0 media rendered

What counts as public

Only what you’ve curated goes out. By default that is:

• patterns you’ve marked reviewed or promoted (jetcarp library update ID --state reviewed, or in the app’s library window);
• ant and turmite runs in the same two states;
• Quick Start entries you’ve added yourself.

A rejected pattern never goes out. Mark an exported pattern rejected (or back to new), export again, and its files are deleted from the folder.

To narrow it further:

View it

Browsers don’t let a page read files from a file:// address, so serve the folder over HTTP to look at it on your own computer:

$ python3 -m http.server -d site 8000

Then open http://localhost:8000/. The page shows every item’s animation in a grid, with filters by kind and class, a sort order (highest score first by default), a search box over names, rules and grids, and a detail view for each item.

The page is plain HTML and JavaScript with no build step and nothing loaded from elsewhere, so it works from any static host. --no-page leaves it out, for instance if you’ve written your own page over manifest.json. A page of your own can also read the data from another folder: the viewer’s DATA constant, near the top of its script, names the folder that holds manifest.json.

Put it online

Copy the folder to any static host: GitHub Pages, Netlify, an S3 bucket or your own server. Files that haven’t changed keep their names and contents, so a sync tool such as rsync or aws s3 sync uploads only the new ones after each export. The page asks for each file with its hash in the address, so browsers and caches never show a stale picture.

The files

Each JSON file has a format field (1). The page refuses nothing, but warns in the browser’s console about a manifest format it doesn’t know.

Uninstalling

JETCARP keeps almost everything in three folders, for settings, data and output (see Folders). Outside them it sets things up only when you ask it to: the background host starting at login, the GNOME Shell extension, the Windows or macOS screen saver, and a still picture as your desktop background. Removing JETCARP takes three steps: undo those with jetcarp uninstall, decide what to do with the folders, and remove the program itself.

1. Undo what JETCARP set up

jetcarp uninstall, on its own, shows what it would do without changing anything:

$ jetcarp uninstall
Would undo (run again with --yes):
  stop the host starting at login

Kept the data folder /home/ada/.local/share/jetcarp (2.1 GB); add --data to delete it.
Your pictures and exports in /home/ada/Pictures/JETCARP are never deleted.

To remove the program itself, use what installed it: the installer again with `--uninstall`, `pipx uninstall jetcarp`, `uv tool uninstall jetcarp`, `pip uninstall jetcarp`, `brew uninstall jetcarp`, `scoop uninstall jetcarp`, `cargo uninstall jetcarp`, or delete its folder.

jetcarp uninstall --yes does it, and reports each step as done or FAILED with the reason. The steps it may list are:

• stop the background host;
• put your own desktop picture back, if the host left a still there (Leave a still picture when it stops, or jetcarp host still on) or will as it stops. JETCARP saved your picture when it first put a still up; if you have chosen another picture since, that one is left alone;
• stop the host starting at login;
• remove the GNOME Shell extension (Linux): it is switched off and its folder deleted. Log out and back in once to finish;
• remove the Windows screen saver (JETCARP.scr), clearing the choice in Windows’ screen saver settings if JETCARP was the one chosen;
• remove the macOS screen saver (JETCARP.saver);
• forget the recorded host command, a small file in the settings folder that GNOME’s menu and the Windows screen saver use to start the host.

Run it from your desktop session where you can, since putting your picture back and switching the GNOME extension off both go through the desktop. From another desktop, a text console or over SSH it still finds the GNOME extension’s files and deletes them; GNOME Shell skips an extension on its list whose files have gone.

Two options also delete JETCARP’s folders:

The output folder, with your pictures, wallpapers, script runs and sweeps, is never deleted. If you want to keep your pattern library, copy library.sqlite (and its media folder) out of the data folder first; jetcarp doctor shows where it is. If you moved the library elsewhere with JETCARP_LIBRARY, --data does not delete it. Like every JETCARP command, jetcarp uninstall uses the folders that JETCARP_CONFIG_DIR, JETCARP_DATA_DIR and JETCARP_OUT point to when they are set; jetcarp paths shows which.

2. What lives where

If you would rather remove things by hand, or check that nothing is left, this is everything JETCARP writes outside the program’s own folder. ~ is your home folder.

The Linux paths are the usual ones; they follow your XDG settings. jetcarp uninstall does not remove the runtime files or the macOS screen saver’s log, which are small; delete them by hand if you like. To remove the GNOME extension by hand, switch it off in GNOME’s Extensions app before deleting its folder, or run jetcarp host gnome remove, which does both.

3. Remove the program

Remove the program last: jetcarp uninstall needs it to undo the rest. Then use what installed it (see Installing JETCARP):

Each removes the program with the files that came with it (on Windows jetcarpw.exe, the windowless launcher; on macOS libjetcarp_saver.dylib; the starter pack) and nothing of yours: the settings, data and output folders stay until you delete them (step 1’s --settings and --data, or by hand). If you built JETCARP from source, delete the folder you built it in.

How JETCARP generalises automata to any tiling

Almost every well-known cellular automaton was invented on the square grid, and most of their rules are written in terms of that grid: “the eight surrounding cells”, “the cell above”, “turn left”. JETCARP runs these rules on hexagons, pentagons, mixtures of polygons, tiles you draw yourself and aperiodic tilings such as the hat. It can do this because it reduces every tiling to the same object, a neighbour graph, and rewrites each rule family in terms of that graph. This page explains the graph, the choices it involves, and which families could not be carried over.

What it is

A cellular automaton is a grid of cells, each in one of a few states, updated all at once in steps called generations. Each cell’s next state depends only on its own state and the states of its neighbours. Change what counts as a neighbour and you change the automaton.

On a tiling, the natural neighbours of a tile are the tiles next to it. JETCARP records them as a graph: one node per tile, and a link between two tiles that are neighbours. Everything a rule needs is then a question about the graph: how many neighbours are alive, which neighbour lies to the left, how far away a tile is.

There are two ways for tiles to be “next to” each other, and JETCARP offers both:

• Touch neighbours share an edge or at least one corner. On the square grid this is the eight-cell Moore neighbourhood used by Conway’s Life.
• Edge neighbours share a stretch of edge. On the square grid this is the four-cell von Neumann neighbourhood.

On squares the two give 8 and 4 neighbours. Elsewhere the numbers change, sometimes a lot. A triangle has 12 touch neighbours but only 3 edge neighbours; a Cairo pentagon has 7 and 5; a hexagon has 6 either way, because hexagons never meet at a corner alone. In a tiling with several kinds of tile, the counts differ from tile to tile: in the 4.8.8 tiling a square has 4 neighbours and an octagon 8. On aperiodic tilings they vary irregularly: a Penrose rhomb touches between 7 and 11 others. The tiling catalogue lists the counts for every tiling.

This matters because most rules count neighbours. Life’s rule “born with exactly 3 live neighbours” means something quite different when a cell has 12 neighbours, or when some cells have 4 and others 8. Much of what is interesting about running old rules on new tilings comes from this.

Where it came from

The two square-grid neighbourhoods are named after Edward F. Moore, who described machine models of self-reproduction at a 1961 symposium (Moore 1962), and John von Neumann, whose 29-state automaton used the four edge neighbours (von Neumann 1966; see LifeWiki: Moore neighbourhood and Von Neumann neighbourhood).

Running automata on other grids is almost as old. Marcel Golay used hexagonal cellular logic for image processing (Golay 1969). Carter Bays explored Life-like rules on the triangular tiling (Bays 1994) and on hexagons and pentagons (Bays 2005). Life on Penrose tilings was studied by Hill, Stepney and Wan (2005) and by Owens and Stepney (2010), and Adam Goucher found a glider that travels across a Penrose tiling (Goucher 2012). Ants and turmites have run on triangular and hexagonal grids in Tim Hutton’s Golly rules (Hutton 2015) and on Penrose tilings (ptiles/ant).

General tools came later. Ready, from the GollyGang project, runs user-defined rules on polygonal and polyhedral meshes (Ready). Andrew Trevorrow’s HatLife ran Life-like, Larger than Life-style and WireWorld rules on the hat tiling within weeks of its discovery (Trevorrow 2023), and James Edmond’s work on the hat and spectre runs Generations and priority-table rules on a general graph (Edmond 2026). In October 2026 Trevorrow’s SpectreLife did for the spectre what HatLife did for the hat, with Edmond’s rules (Trevorrow 2026), and bellissimogiorno’s aperiodic-life package runs Life on square, hexagonal and aperiodic tilings (bellissimogiorno 2026). JETCARP builds on all of this.

How JETCARP runs it

One graph, three ways of storing it

Every tiling becomes a neighbour graph in which each tile’s neighbours are kept in clockwise order. How the graph is stored depends on the tiling, but the rules never see the difference:

• Dense storage for lattices of one tile shape (squares, hexagons, bricks), where the neighbours follow a fixed stencil.
• Periodic storage for tilings that repeat a unit cell containing several tiles (the Archimedean, k-uniform and isohedral tilings, and tiles you draw), with one table of neighbour offsets per tile in the cell.
• Explicit storage for finite patches of aperiodic tilings (Penrose, hat and spectre), with every tile’s neighbour list written out.

Periodic worlds can have dead edges (cells beyond the edge count as empty), wrapped edges (a torus), or live edges (cells beyond the edge count as alive). Aperiodic patches have dead edges.

Rules that count

Life-like rules, Generations, JACA, WireWorld and the cyclic, Greenberg–Hastings, rock-paper-scissors, Hodgepodge and forest-fire families all depend on how many neighbours are in some state. They carry over directly: a cell counts its neighbours in the graph, whatever their number. Each automaton in a scene chooses touch or edge; in B/S notation a trailing V means edge neighbours, as on LifeWiki. Because some tiles have more than nine neighbours, counts of 10 or more are written with commas: B3,10/S2,3.

The Abelian sandpile is the clearest case of a rule that depends on degree: a tile topples when it holds as many grains as it has neighbours, so on the spectre the threshold differs from tile to tile.

Rules that turn

Langton’s ant and the turmites need direction: “turn right and step forward”. JETCARP measures turns in slots of a tile’s clockwise list of edge neighbours. R and L turn one slot either way, U turns half the tile’s degree, and R2 and L2 turn two slots (120 degrees on a hexagon). After a step the ant faces “straight on”, the slot opposite the edge it came in by. On a tile with an odd number of sides there is no exact opposite, so “straight on” is rounded and stays relative to the entry edge. This one convention lets the same ant run on squares, pentagons, mixed tilings and the hat.

Rules that measure distance

Some families need “within r cells” or “the next row out”. JETCARP uses distance in the graph, counted in steps from neighbour to neighbour:

• Larger than Life counts the cells within r steps, over touch neighbours for its Moore form and over edge neighbours for its von Neumann form. On the square grid these are the usual box and diamond.
• Layered rules grow outward from a seed tile one layer at a time, where a layer is all the tiles at the same graph distance. This is how JETCARP carries Wolfram’s row-by-row rules to any tiling.
• JACA’s blast radius destroys every cell within N steps of an annihilation.
• Lenia is the exception: its smooth kernel uses straight-line distance between tile centres, measured in units of the average tile size.

What stays on its own grid

A few families are tied to a grid’s geometry in a way that has no natural meaning elsewhere, and JETCARP does not pretend otherwise:

• Elementary rules (W30) read the three cells above in a square grid; the hexagonal row rules (HexW, HexT) read the hexagons above. Their any-tiling counterpart is the layered family.
• Margolus block rules update 2 × 2 blocks of squares on alternating offsets.
• Von Neumann’s 29-state automaton depends on the four compass directions; JETCARP refuses to place it on another tiling.

What is new here

None of the ingredients on this page is new on its own, as the history above shows: Ready runs arbitrary rules on meshes, HatLife, SpectreLife and Edmond’s work run several families on the hat and spectre, and many single families have been run on hexagons, triangles or Penrose tilings. What JETCARP adds, to our knowledge, is breadth: one engine that runs every family listed here on every class of tiling it supports (lattices, the 1,248 k-uniform tilings, 81 isohedral types, drawn tiles, and the Penrose, hat and spectre tilings), with the same neighbour model throughout. Not all of these are different graphs: the 81 isohedral types have only the eleven graphs of the Laves tilings, and several drawn families copy the square or hexagonal grid (see Isohedral tilings). Tests check that results agree across thread counts and, where available, between CPU and GPU.

Our prior-art search found no earlier version of the cyclic, Greenberg–Hastings, rock-paper-scissors, Hodgepodge or forest-fire rules on aperiodic tilings, or of turmites on the hat and spectre. Each of these is a direct application of a known rule to a known graph, though, so we do not count them as discoveries. The search behind these statements is summarised in What is new in JETCARP.

Try it

• In the app, any Quick Start entry can be moved to another tiling: change the tiling and the rule keeps running. The Tiling showcase entries pair each tiling with a rule chosen to stay lively there.
• Run the figures above from their scenes, for example jetcarp run docs/scenes/automata/generalising-touch.json --gens 1 --png touch.png.
• jetcarp tilings lists every tiling family with its edge and touch neighbour counts.

References

• Moore 1962; von Neumann 1966
• Golay 1969; Bays 1994; Bays 2005
• Hill, Stepney and Wan 2005; Owens and Stepney 2010; Goucher 2012
• Hutton 2015; ptiles/ant
• Ready; Trevorrow 2023; Edmond 2026; Trevorrow 2026; bellissimogiorno 2026

Life-like rules

Conway’s Game of Life is the best-known cellular automaton, and it belongs to a large family of rules that work the same way: each cell is alive or dead, and whether it is alive next generation depends only on whether it is alive now and how many of its neighbours are. JETCARP runs every rule of this family on every tiling it supports, with either of two neighbourhoods.

What it is

A Life-like rule is fixed by two lists of neighbour counts:

• Birth (B): a dead cell becomes alive if its number of live neighbours is in this list.
• Survival (S): a live cell stays alive if its number of live neighbours is in this list. Otherwise it dies.

Life itself is B3/S23: a dead cell with exactly three live neighbours is born, and a live cell with two or three survives. From these two lines come gliders that travel across the grid, guns that fire them, and, as Conway sketched and later builders made explicit, machines that can compute anything a computer can.

Rules of this kind are called outer totalistic: the new state depends on the cell itself and the total of its neighbours, not on which neighbours are alive. On the square grid with the eight surrounding cells as neighbours, counts run from 0 to 8, so there are 2¹⁸ = 262,144 Life-like rules (LifeWiki: Life-like cellular automaton). Many have names and their own communities of explorers; JETCARP’s named rule catalogue lists 96 of them.

Where it came from

Life. John Horton Conway’s Game of Life reached the public through Martin Gardner’s “Mathematical Games” column in Scientific American in October 1970 (Gardner 1970), followed by a second column in February 1971 (Gardner 1971). Conway was simplifying ideas from von Neumann’s self-reproducing automaton, and offered a $50 prize for a pattern that grows without limit; an MIT group led by Bill Gosper won it in November 1970 with the glider gun (LifeWiki: Conway’s Game of Life). Berlekamp, Conway and Guy’s Winning Ways for your Mathematical Plays (1982) gave Conway’s sketch that Life can hold a universal computer (Berlekamp, Conway and Guy 1982), and Paul Rendell later built an explicit Turing machine in Life (Rendell 2002).

Neighbourhoods. The eight-cell neighbourhood is named after Edward F. Moore (Moore 1962) and the four-cell one after John von Neumann, whose 29-state automaton used it (LifeWiki: Von Neumann neighbourhood).

The rule space. Norman Packard and Stephen Wolfram surveyed two-dimensional automata, numbering outer-totalistic rules and studying their behaviour (Packard and Wolfram 1985). David Eppstein later classified Life-like rules by whether patterns can grow out of a bounding box and whether they can die out (Eppstein 2010).

Notation. Two orders are in use. The older survival/birth form writes Life as 23/3; it was common for years, and Mirek Wójtowicz’s MCell rule lexicon uses it (Wójtowicz, rules lexicon). The birth/survival form B3/S23 is the one Golly and LifeWiki use today (LifeWiki: Rulestring). We found no source that says who first wrote rules as B…/S….

Variants. People began trying other counts almost at once. LifeWiki traces 3-4 Life (B34/S34) to Robert Wainwright’s newsletter Lifeline in December 1971 (LifeWiki: 3-4 Life). A few of the many named rules that followed, with credits as the sources give them:

• HighLife (B36/S23), first considered by Nathan Thompson in 1994 and named by Conway; it has a small replicator (LifeWiki: HighLife).
• Day & Night (B3678/S34678), explored by Nathan Thompson from 1997; swapping live and dead cells leaves it unchanged (LifeWiki: Day & Night).
• Seeds (B2/S), first studied by Brian Silverman and named by Wójtowicz (LifeWiki: Seeds).
• Life without Death (B3/S012345678), which Tommaso Toffoli and Norman Margolus described as INKSPOT (Toffoli and Margolus 1987).
• Vote and Anneal, Gérard Vichniac’s majority and twisted-majority rules (Vichniac 1986).

Software. Golly, by Andrew Trevorrow and Tom Rokicki, first released in 2005, made these rules easy to explore and fast to run (Golly credits; Golly changes). Before it came the CAM-6 hardware of Toffoli and Margolus (1987), Rudy Rucker and John Walker’s CelLab (1989) and Wójtowicz’s MCell. Chris Rowett’s LifeViewer now shows patterns in the browser on LifeWiki and the forums, colouring cells by age if asked (Rowett: LifeViewer; LifeWiki: LifeViewer; Rowett 2019).

How JETCARP runs it

Notation

JETCARP reads the birth/survival form, in upper or lower case:

Any of the named rules can be typed by name instead.

Any tiling, two neighbourhoods

A Life-like rule needs only a neighbour count, so it runs unchanged on any neighbour graph (see How JETCARP generalises automata). By default a cell counts its touch neighbours, which share an edge or a corner; on squares that is Moore’s eight.

Edge neighbours: the V suffix

A trailing V switches the rule to edge neighbours, which share a side; on squares that is von Neumann’s four. This follows LifeWiki’s convention (LifeWiki: Rulestring). The neighbourhood can also be set per automaton in a scene ("neighborhood": "edge").

Counts mean different things on different tilings. A triangle has 12 touch neighbours, a hexagon in the 3.3.3.3.6 tiling has 18, and a square in 4.8.8 has only 4. A rule tuned for one tiling is usually a different creature on another.

B0 rules

If 0 is in the birth list, every dead cell with no live neighbours is born, so the empty background switches on. Without survival on the maximum count it switches off again next generation, and the whole picture flashes. Golly avoids this by running such a rule as two complementary rules that alternate on even and odd generations, so that what you see is the rule’s real behaviour without the strobing (Golly: QuickLife); Golly credits David Eppstein with the idea (Golly credits). JETCARP does the same, and its tests check the result against running the rule by brute force. B0 rules also run under HashLife.

Speed

On lattice tilings JETCARP can step Life-like rules on the GPU as well as the CPU, with identical results, and HashLife can jump wrap-edge lattice worlds far ahead.

What is new here

Life-like rules on other tilings are not new: Carter Bays studied them on triangles, hexagons and pentagons (Bays 1994; Bays 2005), Life has been run on Penrose tilings (Hill, Stepney and Wan 2005; Owens and Stepney 2010) and on the hat (Trevorrow 2023), and H. S. Guttesen studied Life on the Archimedean tilings (Guttesen 2026).

What JETCARP adds is a search for spaceships (patterns that move) across many tilings and rules at once. Some of what it found was already known. Guttesen reported a period-4 glider and a glider gun for Life on the kagome tiling (3.6.3.6) and a period-8 glider on the snub square tiling; JETCARP’s soup searches found the same kagome glider (cell for cell, in one of its phases) and, by comparison with Guttesen’s figure, the same snub-square glider independently, and the credit for them is Guttesen’s.

Beyond those, JETCARP’s catalogue holds spaceships in Life-like rules on the 4.8.8, 3.12.12, 4.6.12, 3.4.6.4, 3.3.3.4.4 and 3.3.3.3.6 tilings, on 3.6.3.6 in rules other than Life, and on several 2- and 3-uniform tilings. Each ship was checked in three ways before it was claimed:

• Against every Archimedean, 2-uniform, 3-uniform and isohedral tiling, with both neighbourhoods. A ship that sees exactly the same neighbour counts in a corridor of a simpler tiling belongs to that tiling, and so does one whose live tiles evolve the same way there in some rule.
• For being two smaller ships flying together.
• On large patches, with wrapped edges and with dead edges.

Ten catalogue entries turned out to be pairs of smaller ships flying side by side, eight of them two of Guttesen’s kagome gliders, and they are not claimed; every Life candidate on the kagome tiling was such a pair. Eight ships found on 3-uniform tilings run unchanged on a simpler tiling, and they are listed there. A looser test, which asks only that the live tiles evolve the same way whatever the neighbour counts of the empty tiles around them, found two more catalogue entries that are the same ship as another, and eight ships that run on a simpler tiling than the one they were found on. That leaves 60 distinct objects. Thirteen are a smaller ship with a passenger, or a bound pair, and are listed with the smaller ship. Twenty-eight, six of those thirteen among them, carry a flag: they are small and turn up often in soups, run in a well-known rule, are built on Guttesen’s gliders, or run on 4.8.8 or 3.12.12 in the rules where EricG reported many unlisted spaceships in 2013 (EricG 2013), so others may well have seen them, although we found no report. To our knowledge, the remaining 25 single ships, on 3.4.6.4, 3.3.3.4.4, 3.3.3.3.6 and on 2- and 3-uniform tilings, have not been reported before. Spaceships on these tilings are not new as such: EricG found ships in Life-like rules on every Archimedean tiling, and Martin Büttner found one in Life on a 2-uniform tiling in 2014 (Code Golf 2014); only these particular ships are claimed. Only two of the 60 run in Life itself: both are on the snub square tiling, both are built around Guttesen’s glider, and both are flagged. The rest are in other rules.

The searches behind those 60 ran Life itself on only a few tilings, though. A census of Life on all 92 Archimedean, 2-uniform and 3-uniform tilings, 50,000 random soups on each, found Life spaceships on 28 of them: Conway’s glider and spaceships on the square grid, Guttesen’s two gliders, a ship on 3.3.3.4.4 that is probably the one EricG reported in 2013, the period-20 ship on k2-007 that is very likely Büttner’s, and ships on 5 of the 2-uniform and 19 of the 3-uniform tilings. To our knowledge, nobody had reported running Life on any of those 2- and 3-uniform tilings but k2-007. Most of the census’s ships are common ships flying in pairs, or ships of a simpler tiling running in a corridor; those that passed every check are listed in Life on the Archimedean and k-uniform tilings.

Ships found on isohedral tilings are not claimed at all. Each isohedral tiling has the neighbour graph of one of the eleven Laves tilings, and every “ship” JETCARP found on one is a known ship of the square or triangular grid in another drawing, Conway’s glider among them. The full list, with every check, is in Findings; the claims are on What is new in JETCARP.

Try it

• Quick Start: Life on the square grid, Life on the 12-neighbour triangle grid, B2/S34 on the hat, and one entry for every named rule, each on its usual grid.
• From the command line: jetcarp run docs/scenes/automata/life-square.json --gens 500 --png life.png.
• Change the tiling of any Life-like entry in the app and watch the same rule on a new graph.

References

• Gardner 1970; Gardner 1971; Berlekamp, Conway and Guy 1982; Rendell 2002
• Moore 1962; Packard and Wolfram 1985; Eppstein 2010
• Toffoli and Margolus 1987; Vichniac 1986; Rucker and Walker 1989
• Golly: QuickLife; Golly credits; Golly changes; Rowett 2019
• Bays 1994; Bays 2005; Hill, Stepney and Wan 2005; Owens and Stepney 2010; Trevorrow 2023; Guttesen 2026
• LifeWiki: Life-like cellular automaton, Rulestring, Conway’s Game of Life, 3-4 Life, HighLife, Day & Night, Seeds

Generations

A Generations rule is a Life-like rule in which dying cells do not vanish at once. They fade through a fixed number of “ageing” states first, and while they fade nothing can be born in their place. That one change turns static Life-like worlds into restless ones full of waves, trails and fast-moving gliders.

What it is

A Generations rule has three parts: birth counts, survival counts, and a number of states C.

• State 0 is empty and state 1 is alive. Only state-1 cells count as live neighbours.
• An empty cell is born (becomes 1) when its number of live neighbours is in the birth list.
• A live cell stays at 1 when its count is in the survival list. Otherwise it starts to age: it moves to state 2, then 3, and so on up to C − 1, one step per generation, and then becomes empty.
• An ageing cell ignores its neighbours, and no cell can be born on top of it.

With C = 2 there are no ageing states and the rule is an ordinary Life-like rule. The ageing states act as a wake: a pattern cannot fall back into the space it has just left, which is why so many Generations rules are full of spaceships.

The best-known example is Brian’s Brain, B2/S/C3, which reads naturally as a model of neurons. Each cell is ready (0), firing (1) or refractory (2). A ready cell fires when exactly two of its neighbours are firing; a firing cell always becomes refractory (the survival list is empty); a refractory cell becomes ready again.

Where it came from

The earliest dated member of the family we found is Brian’s Brain. Tommaso Toffoli and Norman Margolus describe it in Cellular Automata Machines (1987), in a section on the firing of neurons, as a three-state rule they ran on their CAM-6 hardware as BRIAN’S-BRAIN; a footnote says the rule was suggested by Brian Silverman, while the neuron interpretation is theirs (Toffoli and Margolus 1987). LifeWiki dates the rule to the mid-1990s (LifeWiki: Brian’s Brain), but the 1987 book shows it was published by then. Rudy Rucker and John Walker’s CelLab (Autodesk, 1989) included it as “Brain”, along with many other multi-state rules (Rucker and Walker 1989; CelLab rules).

The family got its name and its notation from Mirek Wójtowicz’s MCell (“Mirek’s Cellebration”), a Windows program Wójtowicz began in January 1999 (Wójtowicz 2024). MCell made Generations a named family with a survival/birth/states notation, and its documentation calls it perhaps the most beautiful family in the program (MCell families). We found no source that says who first used the name. Wójtowicz’s own Star Wars (B2/S345/C4) dates from March 1999 (LifeWiki: List of Generations rules).

Around MCell grew a community of rule authors. The MCell rules lexicon and LifeWiki’s list credit rules to Wójtowicz, John Elliott, Michael Sweney, Charles A. Rockafellor, Scott Robert Ladd, Brian Prentice, Jason Rampe, Anders Starmark, Rudy Rucker and John Walker, and others (MCell rules lexicon; LifeWiki list); the named rule catalogue gives the credit for each rule. Golly added Generations in version 2.0 in December 2008 (Golly changes; Golly: Generations).

How JETCARP runs it

Notation

JETCARP writes Generations rules as LifeWiki does, B…/S…/C<states>, with 2 to 255 states:

B2/S/3 (no C) is also accepted. MCell’s survival/birth order is not; write the birth list first. Forty-five named Generations rules can be typed by name (see the catalogue).

On any tiling

Like Life-like rules, Generations rules only count live neighbours, so they run on every tiling’s neighbour graph with touch neighbours by default, or edge neighbours with the V suffix (see How JETCARP generalises automata). Brian’s Brain on Penrose rhombs, below, keeps its waves going across a tiling with no repeating pattern at all.

Colours, speed and long runs

Each state gets its own colour from the palette. On lattice tilings Generations rules can be stepped on the GPU with identical results, and HashLife can jump wrap-edge lattice worlds far ahead, including rules with birth on 0.

What is new here

Nothing on this page is new. Generations-style rules have run on the hat in Andrew Trevorrow’s HatLife (Trevorrow 2023) and on the hat and spectre in James Edmond’s work (Edmond 2026). JETCARP’s part is running the family on every tiling it supports with the same engine as everything else.

Try it

• Quick Start: Brian’s Brain, Brian’s Brain on Penrose rhombs, and one entry for each of the 45 named Generations rules.
• jetcarp run docs/scenes/automata/generations-brain.json --gens 200 --png brain.png
• Try Brian’s Brain with edge neighbours (B2/S/C3V) on the hat; with fewer neighbours, firing needs a different count to spread.

References

• Toffoli and Margolus 1987; Rucker and Walker 1989; CelLab rules
• Wójtowicz 2024; MCell families; MCell rules lexicon
• LifeWiki: Generations, List of Generations rules, Brian’s Brain
• Golly: Generations; Golly changes
• Trevorrow 2023; Edmond 2026

Larger than Life

Larger than Life widens Life’s neighbourhood. Instead of the eight cells around it, a cell looks at every cell within some range r, and is born or survives when the number of live cells there falls in a range of values. With a large enough neighbourhood, Life’s small, jagged creatures give way to big, smooth, almost organic ones.

What it is

A Larger than Life rule has a range r, a neighbourhood shape, and a birth and survival condition given as ranges of counts:

• On the square grid, the usual (Moore) shape is the box of side 2r + 1 around the cell, so a range-5 cell has 120 neighbours. The von Neumann shape is the diamond of cells within r steps up, down, left and right.
• A dead cell is born when the number of live cells in its neighbourhood is in the birth range; a live cell survives when the count is in the survival range.

Life is the range-1 case. Larger ranges average over more cells, which smooths out the randomness of small counts: patterns grow round edges and move as large coherent bodies. Kellie Evans showed that rescaled versions of Life’s gliders and replicators exist at large ranges; Evans called the gliders “bugs” (Evans 1996).

The modern generalisation, higher-range outer-totalistic (HROT) rules, allows any list of counts rather than a single interval for birth and for survival (LifeWiki: HROT).

Where it came from

Golly’s documentation credits David Griffeath with first imagining Larger than Life in the early 1990s, to see whether Life sits near a critical point when its thresholds and range are scaled up together (Golly: Larger than Life). Golly cites Griffeath’s “Self-organization of random cellular automata: four snapshots” as the first reference (Griffeath 1994).

Kellie Michele Evans developed the family in a 1996 PhD thesis at the University of Wisconsin–Madison, Larger than Life: It’s So Nonlinear, supervised by Griffeath. Evans’s preface says the question came from Griffeath: would glider-like “digital creatures” emerge from random starts if Life’s rule were rescaled to larger neighbourhoods? The thesis studies the family with tools from probability and from dynamics, including large-range analogues of Life’s replicators and gliders (Evans 1996). Evans continued the work in a series of papers (Evans 2001; Evans 2003; Evans 2003, replicators; Evans 2005; Evans 2010; Evans 2016).

MCell’s rules lexicon says the “Bugs” rule was found while exploring the parameter space on the CAM-8 cellular automaton machine, and credits it to Evans (MCell rules lexicon). Golly’s help says that “Bosco”, a period-166 oscillator, was discovered by Evans, and that Dean Hickerson used MCell to build the first bug gun from it (Golly: Larger than Life). The rule became known as Bosco’s Rule (LifeWiki: Larger than Life). Other named rules include Griffeath’s Majority, Majorly and Bugsmovie, Evans’s Waffle, Wójtowicz’s Globe and Charles A. Rockafellor’s ModernArt (see the catalogue).

Mirek Wójtowicz’s MCell (from 1999) gave the family its first widely used notation, with ranges up to 10 (MCell families). Chris Rowett’s LifeViewer added Larger than Life and HROT rules in January 2019, accepting Adam P. Goucher’s lifelib notation for HROT (Rowett 2019). Golly added a Larger than Life algorithm in version 3.0 (2017) and HROT rules in 4.0 (2020) (Golly changes).

How JETCARP runs it

Notation

JETCARP reads both the HROT form and MCell’s form:

In HROT form the centre cell is never counted. Counts can be lists of values and ranges separated by commas. Rules with weighted or custom neighbourhoods (an NW… suffix) are not supported yet, so the named rule Coexistence cannot be run.

On any tiling

On the square grid the Moore shape is the box and the von Neumann shape the diamond. On any other tiling JETCARP measures range in steps over the neighbour graph: Moore means “within r steps over touch neighbours” and von Neumann means “within r steps over edge neighbours”. On the square grid these definitions give exactly the box and the diamond, and range 1 is checked to equal Life. The cross shape has no such reading and stays on the square grid.

Neighbourhood sizes change with the tiling, so a rule’s thresholds usually need adjusting when it moves. On the hat, below, Bosco’s thresholds are scaled down by a quarter, and bug-like hollow blobs appear on an aperiodic tiling.

What is new here

Larger than Life-style range rules have run on the hat before, in Andrew Trevorrow’s HatLife (Trevorrow 2023); we did not confirm whether HatLife measures range in graph steps. Golly supports hexagonal, triangular and other neighbourhood shapes (Golly: Larger than Life). We do not claim anything new for this family. Defining range as graph distance is what lets JETCARP run the family on every tiling, including the k-uniform, isohedral and aperiodic ones.

Try it

• Quick Start: the eight runnable named rules, for example Bosco’s Rule, Majority (LtL) and ModernArt.
• jetcarp run docs/scenes/automata/ltl-bosco.json --gens 300 --png bosco.png
• Move Bosco’s Rule to hexagons and lower its thresholds until bugs appear; the neighbourhood of range 5 is smaller there than on squares.

References

• Griffeath 1994; Evans 1996; Evans 2001; Evans 2003; Evans 2003, replicators; Evans 2005; Evans 2010; Evans 2016
• MCell rules lexicon; MCell families
• Golly: Larger than Life; Golly changes; Rowett 2019
• LifeWiki: Larger than Life, Higher-range outer-totalistic
• Trevorrow 2023

Elementary (Wolfram) rules

The elementary cellular automata are the simplest interesting ones: a single row of cells, each alive or dead, where each cell’s next state depends on itself and its two neighbours. There are only 256 such rules, yet among them are rules that make nested fractals, rules that look random, and one that can compute anything. JETCARP draws them the classic way, one row per generation down the square grid.

What it is

A cell and its two neighbours form a pattern of three cells, and there are eight possible patterns (from 111 down to 000). An elementary rule says which of the eight patterns produce a live cell in the next generation. Reading those eight outputs as a binary number, from pattern 111 down to 000, gives the rule’s number between 0 and 255. Rule 30 is 00011110 in binary: patterns 100, 011, 010 and 001 produce a live cell, the rest a dead one.

Because the automaton is one-dimensional, its whole history fits in one picture: put each generation below the last. Some famous members:

• Rule 90, where each cell is the exclusive or (XOR) of its two neighbours. From one cell it draws Pascal’s triangle mod 2, the Sierpinski triangle.
• Rule 30, whose centre column looks random enough to be used as a source of pseudorandom bits.
• Rule 110, in which moving structures collide on a periodic background, and which can emulate any computer.
• Rule 184, where live cells move right when the cell ahead is empty: a simple model of traffic.

Where it came from

One-dimensional cellular automata were studied in symbolic dynamics as maps that commute with the shift; Gustav Hedlund’s 1969 paper is the standard reference for that line of work (Hedlund 1969).

Stephen Wolfram studied the 256 three-neighbour rules systematically in “Statistical mechanics of cellular automata” (1983), numbering each rule by its outputs read as a binary number, the scheme now called the Wolfram code (Wolfram 1983; Wikipedia: Wolfram code). In 1984 Wolfram sorted cellular automaton behaviour into four qualitative classes, from rules that die out to rules with complex, long-lived structures (Wolfram 1984), and with Olivier Martin and Andrew Odlyzko worked out the algebra of the additive rules such as 90 and 150 (Martin, Odlyzko and Wolfram 1984). Wolfram proposed rule 30 as a random-number generator in 1986 (Wolfram 1986).

Wolfram’s 1985 list of open problems asked which cellular automata are computation-universal (Wolfram 1985). Matthew Cook proved that rule 110 is, by showing it can emulate cyclic tag systems. Cook presented the proof at the CA98 conference at the Santa Fe Institute; Wolfram Research then took legal action over Cook’s nondisclosure agreement, and the proof was published in 2004 (Cook 2004; Wikipedia: Rule 110; Giles 2002). Turlough Neary and Damien Woods later showed that rule 110 simulates Turing machines efficiently, so predicting it is P-complete (Neary and Woods 2006). Wolfram’s A New Kind of Science (2002) brought the elementary rules to a wide audience (Wolfram 2002).

How JETCARP runs it

Notation

Golly’s Wn rules are limited to even numbers, because in an odd rule the empty pattern 000 produces a live cell, which raises the same problem as B0 rules (Golly: QuickLife). JETCARP runs odd rules too: their background simply alternates from row to row, which shows as stripes.

Rows on the square grid

An elementary rule in JETCARP fills the square grid from the top down: each generation computes the next row from the one above it. The first row is set by the seed: one live cell in the middle (top_center) or a random row (top_random). With dead edges, cells beyond the sides count as dead; with wrapped edges the row is a ring, and the rule keeps going for one full pass of the grid. The run is done when the bottom row has been written, which searches and scripts use to know when to stop. Colour by row gives the gradients often seen in pictures of these rules.

An elementary rule can share a field with other automata: in the Quick Start entry Rule 30 meets Life and ants, Life rewrites the rows rule 30 leaves behind while ants wander through them.

Not on other tilings

“The cell to the left and the cell to the right in the row above” only makes sense on a grid with rows, so the W rules stay on squares. JETCARP carries the idea elsewhere in two ways: the hexagonal row rules, which read the two or three hexagons above a cell, and layered rules, which replace rows with layers of graph distance and run on any tiling.

What is new here

Nothing. The elementary rules are among the most studied objects in the field, and JETCARP runs them as everyone does. Its own additions are the hexagonal and layered families described on their own pages.

Try it

• Quick Start: Rule 30, Rule 90, Rule 110, and ten more named rules (18, 22, 45, 54, 60, 73, 105, 126, 150, 184).
• jetcarp sheet --kind w --from 64 --count 64 --png sheet.png draws the next 64 rules.
• jetcarp run docs/scenes/automata/elementary-rule110.json --gens 200 --png rule110.png

References

• Hedlund 1969
• Wolfram 1983; Wolfram 1984; Martin, Odlyzko and Wolfram 1984; Wolfram 1985; Wolfram 1986; Wolfram 2002
• Cook 2004; Giles 2002; Neary and Woods 2006
• Wikipedia: Wolfram code, Rule 110, Rule 184
• Golly: QuickLife

Hexagonal row rules: HexW and HexT

Elementary rules build a picture row by row on the square grid, each cell reading the three cells above it. On a grid of hexagons the rows are staggered, so a cell sits under two cells, or, if the hexagons are turned to have flat tops, under three cells at two different heights. JETCARP has a family for each: HexW with two parents and HexT with three. Both come in binary and three-state versions.

What it is

Two parents (HexW, HexW3). On a grid of pointy-topped hexagons, each hexagon touches two hexagons in the row above, one up and to the left, one up and to the right. A two-parent rule gives the new cell’s state as a function of those two. With two states there are 2 × 2 = 4 parent patterns and so 2⁴ = 16 rules; with three states there are 9 patterns and 3⁹ = 19,683 rules. HexW 6 is the exclusive or of the two parents, which draws Pascal’s triangle mod 2 just as rule 90 does on squares.

Three parents (HexT, HexT3). Turn the hexagons a quarter turn so they have flat tops. Now three hexagons touch a cell’s upper edges: NW and NE, half a row higher, and N, a full row higher. The grid fills in by height in half-row layers, and each new layer is computed from the two layers before it. With two states there are 8 parent patterns and 256 rules, numbered like Wolfram’s elementary rules; with three states there are 27 patterns and 3²⁷ (about 7.6 trillion) rules. Two smaller sets are easier to explore: totalistic rules, which depend only on the sum NW + N + NE (2,187 three-state rules, 16 binary ones), and left-right symmetric rules, which treat NW and NE alike.

Where it came from

Hexagonal grids have a long history in cellular automata. Marcel Golay used hexagonal cellular logic for image processing in 1969 (Golay 1969). Norman Packard and Stephen Wolfram’s survey of two-dimensional automata counted the rules on the hexagonal neighbourhood alongside the square ones (Packard and Wolfram 1985), and the hexagonal lattice gas of Frisch, Hasslacher and Pomeau showed why hexagons matter for physics: their symmetry is enough to recover fluid flow, where the square grid’s is not (Frisch, Hasslacher and Pomeau 1986).

The two-parent rules are Wolfram’s. In a note in A New Kind of Science, Wolfram observes that if the cells on successive steps are arranged “like hexagons or staggered bricks”, each cell depends on two cells instead of three; Wolfram counts 16 two-colour rules and 19,683 three-colour rules, of which 1,734 are fundamentally different (Wolfram 2002, p. 885). HexW and HexW3 are exactly this family. Matej Kerekrety’s 2020 web tool also draws the 16 binary rules on hexagons, along with the 256 elementary rules on squares and pentagons (Kerekrety 2020).

The three-parent rules are a known kind of rule in a new presentation. A cell that depends on two cells one layer back and one cell two layers back is a second-order one-dimensional automaton on a staggered lattice. Second-order rules are standard: A New Kind of Science uses them to build reversible rules (p. 437 and the note on p. 1017), and the Wolfram Language’s CellularAutomaton supports staggered ranges and rules of any order (Wolfram 2002; Wolfram Language documentation). The 16 HexT rules of the form g(NW, NE) XOR N are exactly the reversible second-order versions of the 16 two-parent rules.

How JETCARP runs it

Notation

HexT 90 is NW XOR NE, Pascal’s triangle mod 2 again; HexT 150 is the XOR of all three parents; HexT 4 copies N straight down.

Grids

The two-parent rules run on the ordinary hexagon tiling (hex). The three-parent rules need the flat-top hexagon tiling (hex_flat), whose rows are the half-row layers. As with the elementary rules, each generation writes one more row or layer from a seed at the top (top_center for one cell, top_random for a random row), with dead, live or wrapped edges, and the run is done when the bottom is reached. These families are tied to rows of hexagons and do not run on other tilings; the any-tiling version of the idea is the layered family.

Sheets and sweeps

jetcarp sheet --kind hexw, hexw3, hext, hext3 or hext3sum draws a contact sheet of consecutive rules, and scripts can sweep whole sets. A first run classified all 256 HexT rules and all 2,187 HexT3 sum rules from a single cell with JETCARP’s row descriptors, which label the rows a rule leaves behind as uniform, periodic, shifting or aperiodic (and the aperiodic ones as nested, regular or chaotic). For HexT that gave 44 uniform, 127 periodic, 46 shifting and 39 aperiodic rules, three of them chaotic (153, 165 and 195). The labels are a quick heuristic, not a proof.

What is new here

The two-parent rules are not new: they are Wolfram’s two-cell rules, drawn on hexagons as Wolfram describes, and Kerekrety’s tool draws the binary ones too.

The three-parent rules are built from standard ingredients, but we found no earlier source that presents them as a family of hexagon rules, numbers all 256 binary and 3²⁷ three-state rules in this way, adds the totalistic and symmetric subsets, or catalogues them. To our knowledge, presenting and cataloguing the HexT and HexT3 family is new with JETCARP. The search behind this is summarised in What is new in JETCARP.

Try it

• Quick Start: Hex rule 6 (XOR), Hex ternary 8229 (sum mod 3), Hex3 rule 90 (NW xor NE), Hex3 ternary sum 588 (sum mod 3) and Hex3 ternary sum 314. On a hexagon rule’s card, < and > step through the rule numbers.
• jetcarp sheet --kind hext3sum --from 0 --count 64 --png sheet.png draws 64 totalistic three-parent rules.
• jetcarp run docs/scenes/automata/hex-hext3-sum588.json --gens 200 --png diamonds.png

References

• Wolfram 2002 (p. 885 note on two-cell neighbourhoods; p. 437 and the p. 1017 note on second-order rules); Wolfram Language: CellularAutomaton
• Kerekrety 2020
• Golay 1969; Packard and Wolfram 1985; Frisch, Hasslacher and Pomeau 1986

Layered rules

A layered rule is an elementary-style rule that grows outward from a seed instead of downward from a top row. The “rows” are the layers of the tiling’s neighbour graph around the seed: the seed, then every tile next to it, then every tile next to those, and so on. Because any tiling has layers in this sense, the same rule runs on squares, Cairo pentagons and the aperiodic spectre alike.

What it is

Pick one or more seed tiles. The layers are the sets of tiles at the same distance from the seeds, counting steps from neighbour to neighbour: layer 0 is the seeds, layer 1 the tiles that touch them, and so on. Each generation writes the next layer.

A tile’s parents are its neighbours in the layer before. A layered rule is totalistic: the new tile’s state depends only on the sum of its parents’ states. The rule is a list of outputs, one for each sum, and the list repeats, so the output for sum s is entry s mod the list’s length:

• Layer 2/01: two states; an even sum gives 0 and an odd sum gives 1. Each tile is the parity (XOR) of its parents.
• Layer 3/012: three states; each tile is the sum of its parents mod 3.

The totalistic form is what makes this work on any tiling. On squares every cell has the same number of parents, but on a Cairo or spectre tiling the number of parents varies from tile to tile, and a rule that depends only on the sum stays well defined.

On the square grid with edge neighbours the layers are diamonds, and Layer 2/01 draws Pascal’s triangle mod 2 in each quarter, the same pattern rule 90 draws from one cell (Martin, Odlyzko and Wolfram 1984). On other tilings the same rule draws patterns that have no simple formula.

Where it came from

Layered rules are Jimmie Rodgers’s construction, introduced in JETCARP in 2026. They combine the row-by-row picture of Wolfram’s one-dimensional rules (Wolfram 1983) with a tiling’s neighbour graph.

The closest earlier work we found carries one-dimensional rules into other tilings in different ways. Maurice Margenstern embedded one-dimensional automata in hyperbolic tilings along a chosen line of tiles (Margenstern 2010), and Matej Kerekrety’s web tool draws elementary rules row by row on hexagons and pentagons, using the lattice’s fixed rows (Kerekrety 2020). Neither uses graph-distance layers from a seed.

A note on the name: Abhishek Dalai’s “Layered Cellular Automata” (Dalai 2023) is a different idea, two coupled layers of computation, and is unrelated to JETCARP’s layered rules.

How JETCARP runs it

Notation

Layer <states>/<outputs>, where the outputs are listed for sums 0, 1, 2, … and repeat:

Seeds, neighbours and edges

The layers are computed once, by a breadth-first search over the automaton’s neighbourhood (touch or edge), from every cell that is non-zero when the rule first runs. With no live cells it starts from the centre tile and switches it on. Several seeds give layers that grow from all of them at once and meet in the middle. The run is done when the last layer has been written; on a finite patch that is when the layers reach its edge.

Touch and edge neighbourhoods give different layers. On squares, touch layers are square rings and edge layers are diamonds; on most other tilings the two differ in more irregular ways, and so do the pictures.

Colour

By default each tile is coloured by state. Colour by row ("color_by": "row") shades tiles by their height in the picture instead, as in the spectre figure above.

What is new here

To our knowledge, layered rules are a new presentation: Wolfram-style totalistic rules whose rows are the graph-distance shells around a seed, so that they run unchanged on any tiling, including aperiodic ones. We found no earlier source that defines them or runs them on Penrose, hat or spectre tilings. The idea is simple enough that it may exist unpublished, for example in hobby code or in work on rules over graphs that our search did not reach, so we claim only that we have not seen it published. The search is described in What is new in JETCARP.

Try it

• Quick Start: Layered parity on the Spectre, Layered parity and Layered sum mod 3 (both on Cairo pentagons).
• jetcarp run docs/scenes/automata/layered-spectre.json --gens 400 --png spectre-layers.png
• Seed a few cells by hand with the Draw tool before starting a layered rule: the layers then grow from all of them.

References

• Wolfram 1983; Martin, Odlyzko and Wolfram 1984
• Margenstern 2010; Kerekrety 2020
• Dalai 2023 (unrelated, same name)

JACA: Jimmie’s Annihilating Cellular Automata

JACA is a family of two-sided Life-like rules. Cells are positive, negative or empty; each sign grows by its own birth/survival rule; and wherever the two signs touch, they destroy each other. Started from a mixed soup, the two signs sort themselves into territories separated by glowing, shifting fronts, and the fight between them can last thousands of generations. JACA is Jimmie Rodgers’s idea and is introduced in JETCARP.

What it is

Each cell holds one of three values: +1, −1 or 0 (empty), a balanced ternary digit. Every generation is computed from the current state in three steps:

1. Contact. A live cell with at least one neighbour of the opposite sign is a contact cell. Contact cells are destroyed: they are empty next generation.
2. Blast. With a blast radius N greater than 0, every cell within N neighbourhood steps of a contact cell is destroyed too, whatever its sign. With the default blast 0, only the touching cells go.
3. Everything else follows its own sign’s rule. A +1 cell survives if its number of +1 neighbours is in the +1 rule’s survival list; an empty cell is born +1 if its number of +1 neighbours is in the +1 rule’s birth list; and likewise for −1. Each sign counts only neighbours of its own sign. An empty cell that both signs would fill stays empty: the two births cancel.

Two properties make the family easy to reason about. A world that contains only one sign runs that sign’s plain birth/survival rule exactly, so JACA B3/S23 with only +1 cells is Conway’s Life. And the two signs can follow different rules: JACA +B3/S23 -B36/S23 sets Life against HighLife.

What emerges depends on the rules, the tiling and the blast radius. Among the behaviours found so far:

• Territory wars. Seeds-like rules (birth on 2, little survival) in mixed soups form territories that merge and push along their fronts until one sign holds the whole grid, on every tiling tried.
• Rainbow fronts. In rules whose territories go still while their fronts stay active, colouring by age turns every front into a rainbow, as in the figure above.
• Trenches. A blast radius of 1 to 3 leaves a strip of no-man’s-land between territories: bands, beads, ropes, collapsing loops.
• Annealing. With births on 3 or more, fronts become smooth and move to reduce their curvature, like grain boundaries in a cooling metal.
• Two different rules. Bubbles of one rule growing in the other’s still sea, or still crystal against noise, with either side winning.

Where it came from

JACA is Jimmie Rodgers’s idea, from November 2026; it first appeared in JETCARP’s predecessor CART on 8 November 2026. Each of its ingredients has a precedent, and we credit them here:

• Two-player Life. Mark Levene and George Roussos’s two-player game of life (2003) has black and white tokens; opponents weaken each other’s survival through a difference count, and a tie at birth is settled by a coin flip (Levene and Roussos 2003).
• +1, −1 and 0, with cancelled births. The CodinGame bot game “Game of Life or Death”, described on the Unsupervision Blog in November 2025, encodes the two players as 1 and −1; each side treats the other’s cells as dead, and a cell both sides would switch on stays dead (Unsupervision Blog 2025). This is the closest precedent for JACA’s encoding, own-sign counting and cancelled births. Touching cells of opposite sides are not destroyed there.
• Matter and antimatter Life. In September 2018 KittyTac proposed, on the ConwayLife.com forums, a Life with two kinds of cell where contact turns both cells into energy, and wildmyron implemented it as the “Energetic” rule, in which the energy decays into photons (KittyTac and wildmyron 2018; LifeWiki: Rule:Energetic). This is the closest precedent for annihilation on contact. There the products are part of the state and can create cells, and both kinds follow one fixed rule.
• Physics. Opposite particles that annihilate when they meet, A + B → 0, are a classic problem in the physics of diffusion (Toussaint and Wilczek 1983); Chopard and Droz treat such reaction–diffusion processes with cellular automata (Chopard and Droz 1998).

How JETCARP runs it

Notation

The blast radius runs from 0 to 64. Rules with birth on 0 are refused. Counts of 10 or more are written with commas, as in other B/S rules.

On any tiling

JACA uses only neighbour counts and neighbourhood steps, so it runs on every tiling (see How JETCARP generalises automata); the blast radius is measured in steps of the automaton’s own neighbourhood. It runs on the CPU; there is no GPU or HashLife version yet.

Seeds, colours and counts

A JACA field is stored as a three-state field (states 1 and 2 are +1 and −1), so drawing, scenes and scripts treat it like any other multi-state rule. The usual start is a mixed soup ({"signed": {"density": 0.3, "negative": 0.5}}: 30% of cells live, half of them negative); a halves start puts +1 cells on the left and −1 on the right. Each sign has its own palette (palette and palette_neg), coloured by age. Destroyed cells glow briefly and fade; the glow is drawn only and is not part of the state or its hash. The app’s card shows the number of cells of each sign and how many were touching and destroyed; the world status that scripts and the MCP server read also reports cancelled births.

Presets

The Quick Start’s JACA family has 5 named rules and 71 presets. Each preset is a whole scene: tiling, neighbourhood, a rule per sign, blast radius, start and palette pair. Together they cover 24 tilings, from squares and hexagons through the Archimedean and k-uniform tilings to two isohedral tilings, both Penrose tilings, the hat and the spectre. (For a rule, the isohedral IH28 is the Cairo tiling and IH41 the square grid, and the brick, herringbone and Pythagorean presets play on the hexagonal, hexagonal and 4.8.8 graphs; see Isohedral tilings.) They came from a six-hour search over about 130,000 configurations: random rule pairs, mutations and crossovers of the best, and transplants of good pairs to other tilings, scored on balance between the signs, contact along fronts, territory changing hands and activity, then reviewed by eye as contact sheets.

What is new here

Each ingredient of JACA has been published before, as the list above shows, and we do not claim “the first signed Life” or “the first matter–antimatter Life”. To our knowledge, JACA’s particular combination is new: an independent birth/survival rule for each sign, counting only same-sign neighbours; destruction of every live cell that touches the other sign; a blast radius measured in neighbourhood steps; cancelled double births; an exact reduction to the plain rule when one sign is alone; and all of this on any periodic or aperiodic tiling. The searches behind this statement, and their known gaps (MCell’s weighted rules and parts of the ConwayLife forums were not searched), are described in What is new in JETCARP.

The colouring is not part of the claim: colouring cells by age and fading destroyed cells have precedents in other programs.

Try it

• Quick Start, family JACA: JACA Life, JACA Life vs HighLife, JACA war on the hat tiling, JACA rainbow fronts (Cairo), JACA bead borders (square, blast 1), and the other presets.
• jetcarp run docs/scenes/automata/jaca-hat-war.json --gens 3000 --png hat-war.png
• Try a halves start with two different rules, and watch which front advances.

References

• Levene and Roussos 2003
• Unsupervision Blog 2025
• KittyTac and wildmyron 2018; LifeWiki: Rule:Energetic
• Toussaint and Wilczek 1983; Chopard and Droz 1998

Langton’s ant and turmites

Langton’s ant is a single moving agent with a two-line rule: on a white cell turn right, on a black cell turn left; flip the colour of the cell and step forward. From an empty grid it wanders for about ten thousand steps in what looks like chaos, then suddenly starts building a straight “highway” and never stops. Turmites generalise the ant to more colours and to internal states. JETCARP runs them on any tiling.

What it is

An ant sits on a cell, facing one of the cell’s sides. Each step it reads the colour of its cell, turns according to that colour, changes the cell to the next colour, and moves to the neighbour it now faces. A turn string gives the turn for each colour: Langton’s ant is RL (two colours: right on colour 0, left on colour 1), and LLRR has four colours, each cell cycling through 0, 1, 2, 3.

A turmite adds internal states: what it writes, how it turns and which state it moves to all depend on both its state and the cell’s colour, like a Turing machine whose tape is the plane. An ant is a turmite with one state.

These agents are interesting for how much they do with so little. The RL ant’s highway repeats every 104 steps, moving two cells diagonally each period. Some turn strings, such as LLRR, grow patterns that keep returning to perfect mirror symmetry; others fill squares or triangles, or wander forever. A single ant can compute: its path can be made to evaluate any logical circuit.

Where it came from

Christopher G. Langton described single-state two-dimensional Turing machines, which Langton called vants (virtual ants), in “Studying artificial life with cellular automata” (1986); the RL ant is among them (Langton 1986). Greg Turk’s 2025 review credits Langton with the term and, as far as Turk knows, with being the first to study such machines. Turk also points to a related earlier idea, the “worms” of Paterson and Conway that Martin Gardner wrote about in 1973 (Turk 2025; Gardner 1973).

Turk rediscovered the RL ant independently and sent several two-dimensional Turing machines to A. K. Dewdney, whose Scientific American column of September 1989 presented them and coined the name tur-mite (Dewdney 1989; Turk 2025). David Gale’s columns in The Mathematical Intelligencer took up the ant (Gale 1993) and reported James Propp’s work on ants whose turns are a string of Ls and Rs (Propp 1994). Gale, Propp, Scott Sutherland and Serge Troubetzkoy identified a class of ants whose patterns are, at times, bilaterally symmetric, and proved it (Gale et al. 1995); the columns were collected in Gale’s Tracking the Automatic Ant (Gale 1998). Ian Stewart’s 1994 Scientific American article brought the ant to a wide audience (Stewart 1994).

Physicists met the same dynamics independently, as a particle bouncing off rotators that flip when hit, a Lorentz lattice gas. Bunimovich and Troubetzkoy’s recurrence results are the source usually cited for the theorem that the ant’s path is always unbounded (Bunimovich and Troubetzkoy 1992); Kong and Cohen studied related lattice gases on the triangular lattice (Kong and Cohen 1991). Gajardo, Moreira and Goles showed that the ant’s path can compute any boolean circuit, so predicting it is P-hard (Gajardo, Moreira and Goles 2002), and Tsukiji and Hagiwara extended hardness results to generalised ants on square and hexagonal grids (Tsukiji and Hagiwara 2011).

The highway’s onset is usually given as step 9,977, with period 104 (Hutton 2015); we have not traced that number to a primary publication, but JETCARP’s own run reproduces it exactly. Tim Hutton’s Golly scripts generate turmite rules, including on triangular and hexagonal grids, and Hutton’s page credits Allen H. Brady with first studying the triangular case (Hutton 2015). Other programs that run ants include CelLab (Rucker and Walker 1989), Uri Wilensky’s NetLogo model (Wilensky 2005) and, on Penrose tilings, ptiles/ant (ptiles/ant). Turk’s 2025 paper publishes much of Turk’s own work from around 1989, including multistate, universal and self-reproducing turmites (Turk 2025).

How JETCARP runs it

Notation

In a table each entry is <colour to write><turn><next state>, one group per state and one entry per colour. Up to 16 colours and 16 states are allowed, with 10 to 15 written a to f.

Turns on any tiling

A turn is counted in slots of the current tile’s edge neighbours, listed clockwise. R and L turn one slot, R2 and L2 two slots (120 degrees on a hexagon), U half the tile’s number of sides, and N not at all. After a step, the ant faces “straight on”: the side opposite the one it came in by. A tile with an odd number of sides has no opposite side, so straight on is rounded, and on such tiles N and U are relative to the entry edge. With this one convention the same turn string runs on squares, hexagons, pentagons, mixed tilings and the aperiodic tilings, even though R means 90 degrees on a square, 60 on a hexagon and something irregular on a hat (see How JETCARP generalises automata).

Running and searching

In a scene, an ant automaton takes steps_per_gen (how many ant steps make one generation) and an ants seed with a count; several ants can share a field, and on a field shared with other automata they interact with Life or an elementary rule. At a dead edge an ant either bounces or falls off.

For research, jetcarp search ants runs turn strings and turmite tables on an unbounded periodic tiling and classifies every run. When it reports a highway, it has proved one: it checks that the ant and every cell ahead of it recur, shifted, after a fixed number of steps, which by induction repeats forever. It reproduces the RL ant’s published highway (period 104, onset 9,977) and finds, for example, a highway for LNL on hexagons with period 35 from step 161,093. This engine is tested to agree cell for cell with the ordinary world’s turmites on seven tilings.

What is new here

Ants have run on hexagons, triangles and Penrose tilings before (see above). Our prior-art search found no earlier turmites on the hat or spectre tilings, but that is a direct application of a known rule to a known graph, so we do not count it as a discovery. We make no novelty claim for this family.

Try it

• Quick Start: Langton’s ant, Four-colour turmite LLRR, and the named turmites RLR, LRRRRRLLR, LLRRRLRLRLLR and RRLLLRLLLRRR.
• jetcarp run docs/scenes/automata/turmite-langton.json --gens 120 --png ant.png
• Move Langton’s ant to the hat or to 4.8.8, where tiles of different degree make R mean different angles from step to step.

References

• Langton 1986; Turk 2025; Gardner 1973; Dewdney 1989
• Gale 1993; Propp 1994; Gale et al. 1995; Gale 1998; Stewart 1994
• Bunimovich and Troubetzkoy 1992; Kong and Cohen 1991; Gajardo, Moreira and Goles 2002; Tsukiji and Hagiwara 2011
• Hutton 2015; Rucker and Walker 1989; Wilensky 2005; ptiles/ant

WireWorld

WireWorld is a cellular automaton for building circuits. You draw wires, and “electrons” run along them, split at junctions, and are stopped or passed by small arrangements of wire that act as diodes and logic gates. With enough wire it can compute anything; David Moore and Mark Owen, with help from others, built a complete programmable computer in it (Moore and Owen: The Wireworld computer).

What it is

Each cell is in one of four states: empty, conductor (copper), electron head or electron tail. The rule:

• An empty cell stays empty.
• An electron head becomes an electron tail.
• An electron tail becomes conductor.
• A conductor cell becomes an electron head if exactly one or two of its neighbours are electron heads; otherwise it stays conductor.

A head followed by its tail is an electron with a direction: the tail behind it stops it moving backwards. The “one or two” condition is what makes the circuits work. Where wires meet, a junction shaped so that an electron coming one way sees one head and one coming the other way sees three can pass electrons in only one direction (a diode), and similar small shapes give OR, AND, XOR and NOT gates, clocks and memory (LifeWiki: WireWorld).

Where it came from

WireWorld was devised by Brian Silverman, who also created Brian’s Brain and Seeds. LifeWiki says Silverman proposed it in 1987 as part of the program Phantom Fish Tank (LifeWiki: WireWorld), and the CelLab manual’s references list The Phantom Fishtank (Logo Computer Systems, Montreal, 1987) (Silverman 1987). A 2025 blog post gives 1984 instead (daneelsan 2025), so the rule itself may be older than the program; we have not been able to settle this.

A. K. Dewdney’s Scientific American column of January 1990 described WireWorld and made it widely known (Dewdney 1990; LifeWiki: WireWorld). David Moore and Mark Owen, “with the help of many others”, designed a complete programmable computer in WireWorld between 1990 and 1992 and wrote it up in September 2004 (Moore and Owen: The Wireworld computer); a copy that computes prime numbers ships with Golly (LifeWiki: WireWorld). WireWorld has long been built into MCell and Golly, and Andrew Trevorrow’s HatLife ran it on the hat tiling in 2023 (Trevorrow 2023).

How JETCARP runs it

Notation and states

The rule is written WireWorld. States are 0 (empty), 1 (electron head), 2 (electron tail) and 3 (conductor), drawn by default as dark background, blue, red and amber; use the Draw tool to paint wire and electrons.

On any tiling

WireWorld only asks how many neighbours are electron heads, so it runs on any neighbour graph (see How JETCARP generalises automata). The circuits designed for the square grid depend on its geometry, though: a junction that is a diode on squares is just a blob of wire on hexagons. On another tiling you have to find new gates, which is part of the fun. Touch neighbours are the default, as in the classic rule; edge neighbours make thin wires behave differently at corners. WireWorld can be stepped on the GPU on lattice tilings, and HashLife can jump wrap-edge lattice worlds far ahead.

The adder

The adder in the figure was built for JETCARP, cell by cell, by code that can regenerate and check it. Every component keeps one timing rule: electrons that leave their sources together reach each column together, so the inputs of every gate arrive at the same moment and no delay lines are needed. Its parts are fan-outs, a three-cell OR junction and a 17-cell XOR junction in which two simultaneous electrons annihilate. The OR and XOR junctions were found by JETCARP’s own search, an exhaustive scan of small junction shapes and simulated annealing, not copied from earlier designs. Half adders are built without any wire crossings, and the tests run all 16 input combinations. jetcarp demo wireworld-adder --a A --b B builds it for any inputs from 0 to 3.

What is new here

WireWorld, its gates and its computers are not ours. The adder’s particular junctions were found by JETCARP’s search, but we make no claim that they are new shapes; small WireWorld gates have been designed by many people. Running WireWorld on other tilings has been done before, on the hat.

Try it

• Quick Start: WireWorld clocks, WireWorld adder: 2 + 3 (family Computing).
• jetcarp demo wireworld-adder --a 3 --b 3 --png adder.png builds and runs the adder for 3 + 3.
• Paint a loop of wire with one head and one tail behind it and watch it act as a clock.

References

• LifeWiki: WireWorld
• Silverman 1987; daneelsan 2025
• Dewdney 1990
• Moore and Owen: The Wireworld computer
• Trevorrow 2023

Cyclic, Greenberg–Hastings and rock-paper-scissors

These three families share one idea: states arranged in a cycle, where each state can be overtaken only by the next one around. From a random start they organise themselves into travelling waves and rotating spirals, the same patterns seen in chemical oscillators, heart tissue and competing species. JETCARP runs all three on any tiling.

What it is

Cyclic cellular automaton. There are n colours arranged on a wheel, 0, 1, …, n − 1 and back to 0. A cell of colour k changes to colour k + 1 (mod n) when at least a threshold number of its neighbours already have colour k + 1; otherwise it stays. Every colour is “eaten” by the next. From random colours, the grid first breaks into patches, then small cycles of colours that chase each other around a point appear, and these spiral cores, once formed, take over the whole grid.

Greenberg–Hastings. A model of an excitable medium. A cell is resting (0), excited (1), or in one of several refractory stages (2 to n − 1). A resting cell becomes excited when at least a threshold number of its neighbours are excited; every other state advances one step on its own, the last refractory stage returning to rest. An excited region therefore fires once and cannot fire again for a while, so excitation travels as waves that annihilate when they meet. In the cyclic automaton every state needs a neighbour to advance; in Greenberg–Hastings only the resting state does (Fisch, Gravner and Griffeath 1991).

Rock-paper-scissors. Each cell is one of n species in a cycle of dominance (with three: rock, paper, scissors). A cell is taken over by its predator, the next species around the cycle, when more than a threshold number of its neighbours are that predator. This is a cyclic automaton with a strict threshold: RPS n/t behaves like Cyclic n/(t+1).

Where it came from

Greenberg–Hastings (1978). J. M. Greenberg and S. P. Hastings introduced their discrete model of excitable media in 1978 (Greenberg and Hastings 1978), and the same year Greenberg, Hassard and Hastings surveyed pattern formation in reaction–diffusion systems (Greenberg, Hassard and Hastings 1978). The model belongs to the tradition of excitable media such as nerve and heart tissue and the Belousov–Zhabotinsky reaction. Rigorous results followed from Durrett and Steif (1991), Fisch, Gravner and Griffeath (1993) and Durrett and Griffeath (1993).

The cyclic automaton (late 1980s). The cyclic cellular automaton came from David Griffeath’s probability group at the University of Wisconsin–Madison; MCell’s documentation says it was discovered and explored by Griffeath (MCell families). Griffeath described it in “Cyclic random competition” in the Notices of the AMS in December 1988 (Griffeath 1988); its random ancestor is the cyclic particle system of Bramson and Griffeath (1989). Griffeath’s student Robert Fisch analysed the one-dimensional version (Fisch 1990; Fisch 1990b). A. K. Dewdney presented the two-dimensional rule as “cyclic space” in Scientific American in August 1989; the “demons” of Dewdney’s title are the spiral cores (Dewdney 1989). The standard reference, which treats the cyclic and Greenberg–Hastings rules together with a range and a threshold, is Fisch, Gravner and Griffeath’s “Threshold-range scaling of excitable cellular automata” (1991).

Rock-paper-scissors. Three species in a cycle of dominance on a lattice have been studied in physics and ecology since Kei-ichi Tainaka’s lattice Lotka–Volterra models (Tainaka 1988; Tainaka 1989), including Frean and Abraham’s “survival of the weakest” (2001), Kerr, Riley, Feldman and Bohannan’s experiment with strains of E. coli (2002), and Reichenbach, Mobilia and Frey’s work on mobility and spiral waves (2007). Those models are stochastic. The deterministic threshold rule JETCARP implements is the one described by Softology, maker of Visions of Chaos, in a 2018 blog post (Softology 2018).

How JETCARP runs it

Notation

The cyclic automaton uses edge neighbours by default, the four orthogonal neighbours on squares; Greenberg–Hastings and rock-paper-scissors use touch neighbours. Either can be changed per automaton. With edge neighbours and threshold 1, as in the cyclic figures, spirals form readily. Starting patterns are usually random states (random_states).

On any tiling

All three families only count neighbours in particular states, so they run on any neighbour graph (see How JETCARP generalises automata). The spirals change shape with the tiling: square on squares, rounder on hexagons, irregular on Penrose and hat tilings, but they still form. Greenberg–Hastings worlds on lattice tilings can be jumped far ahead with HashLife.

What is new here

Cyclic automata have been run on general networks before: Yiqing Cai and Robert Ghrist studied cyclic automata on sensor networks and the waves they carry (Cai and Ghrist 2014). Our prior-art search found no earlier version of these three families on aperiodic tilings such as Penrose, hat or spectre, but that is a direct application of known rules to known graphs, so we do not count it as a discovery.

Try it

• Quick Start: Cyclic CA, Greenberg-Hastings and Rock-paper-scissors.
• jetcarp run docs/scenes/automata/cyclic-hat.json --gens 600 --png spirals.png
• Raise the threshold of Cyclic 16/1 to 2 or 3 with touch neighbours: Fisch, Gravner and Griffeath mapped how range and threshold decide between spirals, turbulence and fixation.

References

• Greenberg and Hastings 1978; Greenberg, Hassard and Hastings 1978; Durrett and Steif 1991; Fisch, Gravner and Griffeath 1993; Durrett and Griffeath 1993
• Griffeath 1988; Bramson and Griffeath 1989; Fisch 1990; Fisch 1990b; Dewdney 1989; Fisch, Gravner and Griffeath 1991; MCell families; Cai and Ghrist 2014
• Tainaka 1988; Tainaka 1989; Frean and Abraham 2001; Kerr et al. 2002; Reichenbach, Mobilia and Frey 2007; Softology 2018

Hodgepodge and forest fire

Two models from the late 1980s and early 1990s that brought cellular automata into chemistry and statistical physics. The hodgepodge machine imitates a catalytic chemical reaction and produces rotating spiral waves. The forest-fire model grows trees and burns them, and became a standard example of self-organised criticality: a system that tunes itself, without outside adjustment, to a state where events of every size happen.

What it is

The hodgepodge machine. Each cell holds a number from 0 to n. State 0 is healthy, n is ill, and everything between is infected, more so for larger numbers. Ill cells recover; healthy cells are infected by their neighbours; infected cells get worse, faster when their neighbours are worse. The parameters k1 and k2 set how easily healthy cells catch the infection, and g how fast infection grows. With suitable values the grid fills with spiral waves.

JETCARP’s version of the rule, per generation, is:

• An ill cell (state n) becomes healthy (0).
• A healthy cell becomes ⌊a / k1⌋ + ⌊b / k2⌋, where a is the number of infected neighbours and b the number of ill neighbours.
• An infected cell becomes ⌊S / (a + b + 1)⌋ + g, where S is the sum of the states of the cell and its neighbours.
• Results above n are capped at n.

This follows the commonly published form of the rule; we have not yet checked it line by line against Gerhardt and Schuster’s paper.

The forest fire. Each cell is empty, a tree or burning. Each generation a burning tree burns out and leaves empty ground; a tree catches fire if a neighbour is burning, or is struck by lightning with a small probability f; and empty ground grows a tree with probability p. When lightning is much rarer than growth, trees build up into large forests, and a single strike can burn a forest of any size. The sizes of the fires then follow a power law, with no typical scale.

Where it came from

Hodgepodge. The hodgepodge machine was designed by Martin Gerhardt and Heike Schuster of the University of Bielefeld, inspired by catalytic chemical reactions. A. K. Dewdney’s Scientific American column “The hodgepodge machine makes waves” introduced it to the public in August 1988 (Dewdney 1988), and the CelLab manual credits it as invented by Gerhardt and Schuster (Rucker and Walker 1989). Their own paper appeared in Physica D in 1989 (Gerhardt and Schuster 1989). With John J. Tyson they went on to a more quantitative automaton model of excitable media, published in Science in 1990 (Gerhardt, Schuster and Tyson 1990).

Forest fire. Per Bak, Kan Chen and Chao Tang introduced a forest-fire automaton in 1990: trees grow, fire spreads from burning trees to their neighbours, and fires never start on their own (Bak, Chen and Tang 1990); Chen, Bak and Jensen published a deterministic variant the same year (Chen, Bak and Jensen 1990). Barbara Drossel and Franz Schwabl added lightning in 1992, and showed that with lightning much rarer than growth the model organises itself into a critical state with fires of all sizes (Drossel and Schwabl 1992). Theirs became the standard forest-fire model; the review by Clar, Drossel and Schwabl tells the story and notes that C. L. Henley independently invented the limit in which clusters burn instantly (Clar, Drossel and Schwabl 1996; Henley 1993). The model descends from Bak, Tang and Wiesenfeld’s idea of self-organised criticality, introduced with the sandpile (Bak, Tang and Wiesenfeld 1987). Later work showed that its scaling is not simple at very large sizes (Grassberger 2002).

How JETCARP runs it

Notation

States are 0 to n for the hodgepodge machine (so n + 1 states) and 0 (empty), 1 (tree) and 2 (burning) for the forest fire.

Randomness that replays

The forest fire is random, but JETCARP’s random numbers are a fixed function of the scene’s seed, the generation and the cell, so a scene replays to exactly the same state every time, on any number of threads. The hodgepodge machine is deterministic.

On any tiling

Both rules count neighbours in particular states, so they run on any neighbour graph with touch or edge neighbours (see How JETCARP generalises automata). The hodgepodge machine can also be stepped on the GPU on lattice tilings. On tilings where tiles have different numbers of neighbours, the hodgepodge machine’s averages and the forest’s spreading vary from tile to tile, but the spirals and fires still appear.

What is new here

Our prior-art search found no earlier version of either model on aperiodic tilings such as Penrose, hat or spectre, and no hodgepodge machine off the square grid at all, though forest fires on triangular and hexagonal lattices probably exist in the physics literature. Either way this is a direct application of known rules to known graphs, so we do not count it as a discovery.

Try it

• Quick Start: Hodgepodge machine and Forest fire.
• jetcarp run docs/scenes/automata/hodgepodge-penrose.json --gens 1000 --png hodge.png
• Lower the forest fire’s lightning probability while keeping growth the same: fires become rarer and larger.

References

• Dewdney 1988; Gerhardt and Schuster 1989; Gerhardt, Schuster and Tyson 1990; Rucker and Walker 1989
• Bak, Chen and Tang 1990; Chen, Bak and Jensen 1990; Drossel and Schwabl 1992; Clar, Drossel and Schwabl 1996; Henley 1993; Grassberger 2002
• Bak, Tang and Wiesenfeld 1987

Margolus block rules

Most cellular automata update each cell from its neighbourhood. Block rules work differently: the grid is cut into 2 × 2 blocks, every block is replaced as a whole by looking it up in a table, and the cut moves by one cell between steps so that information can cross block boundaries. This arrangement, the Margolus neighbourhood, makes it easy to build rules that are reversible and conserve particles, which is why it was invented: to make physics-like models of computation.

What it is

The square grid is partitioned into 2 × 2 blocks. On even steps the blocks start at even coordinates; on odd steps they start at odd coordinates, so each new block straddles four old ones. A block of four binary cells has 16 possible states, and a block rule is a table giving the new state for each of them.

Two properties are easy to see in the table:

• The rule is reversible, meaning every state has exactly one predecessor and the evolution can be run backwards, exactly when the table is a one-to-one map of the 16 block states.
• The rule conserves particles when every block keeps its number of live cells.

Some well-known block rules:

• Billiard ball machine. A lone ball (live cell) crosses its block to the opposite corner; two balls on a diagonal leave along the other diagonal; everything else stays. Balls fly diagonally and bounce off each other like hard spheres, which is enough to build logic gates.
• Critters. A block with exactly two live cells stays; otherwise every cell is complemented, and a block that had three live cells is also turned half a turn. Reversible, and full of gliders.
• Tron. A block whose four cells agree is complemented. Rectilinear patterns grow from any seed.
• HPP gas (in its diagonal Margolus form). Every particle crosses its block to the opposite corner, except that two particles on a diagonal leave along the other diagonal: a toy gas.
• Single Rotation. A block with exactly one live cell turns 90 degrees clockwise; all others stay. A remarkably simple reversible rule with many spaceships.

Where it came from

Edward Fredkin and Tommaso Toffoli’s “Conservative logic” (1982) set out reversible, conservative computation, including a billiard-ball model in which logic signals are hard balls and gates are their elastic collisions (Fredkin and Toffoli 1982). Norman Margolus, in the Information Mechanics Group at MIT with Toffoli, found a very simple reversible automaton that runs the billiard-ball model, using the partitioning scheme now named after Margolus (Margolus 1984). Margolus later wrote that the partitioning technique was first developed for that purpose, and that Toffoli had built the first universal invertible automaton earlier by another route (Margolus 1999).

Toffoli and Margolus built dedicated cellular automaton hardware at MIT, the CAM machines, and wrote Cellular Automata Machines (1987) around the CAM-6; a whole chapter is devoted to the Margolus neighbourhood (Toffoli and Margolus 1987). Critters and Tron are usually credited to that book. Margolus describes Critters as a universal invertible automaton that evolves interesting complexity (Margolus 1999). Toffoli and Margolus reviewed invertible automata in 1990 (Toffoli and Margolus 1990).

The HPP lattice gas is older than the Margolus neighbourhood: J. Hardy, Y. Pomeau and O. de Pazzis introduced it on the square lattice in 1973 and analysed it in 1976 (Hardy, Pomeau and de Pazzis 1973; 1973b; Hardy, de Pazzis and Pomeau 1976). Margolus recalls that the MIT group rediscovered it about a decade later (Margolus 1999). The hexagonal gas of Frisch, Hasslacher and Pomeau removed its unphysical extra conservation laws (Frisch, Hasslacher and Pomeau 1986), and Margolus, Toffoli and Vichniac described automaton hardware for fluid dynamics the same year (Margolus, Toffoli and Vichniac 1986).

The Single Rotation rule was posted in November 2013 on the blog Random thoughts and fancy math by its author, who writes as dmishin; the post doubts that so simple a rule had not been found before but notes that its author had not seen it elsewhere (dmishin 2013).

How JETCARP runs it

Notation

The table lists the new state of the block for block states 0 to 15, numbering the cells as MCell does: upper left 1, upper right 2, lower left 4, lower right 8. The named tables are built in JETCARP’s code from the published descriptions of each rule, not copied from rule files, and were checked against those descriptions.

Square grid only

Block rules depend on cutting the grid into 2 × 2 squares on two alternating offsets, which has no natural counterpart on other tilings, so they run on the square grid only (see How JETCARP generalises automata). Which offset comes next is part of the saved state, so scenes replay exactly. With wrapped edges the blocks wrap across the seam when a side has even length; with dead or live edges, or an odd side, a block that would cross the edge is left unchanged, so conserving rules still conserve. Use even sides for a true torus.

Checks

JETCARP’s tests run Critters forward 101 generations and then backward with the inverse table, and recover the starting pattern exactly; check that the billiard ball machine keeps its number of balls; and check the lone ball, the Single Rotation square and Tron’s flashing background. Block rules run on the CPU.

What is new here

Nothing. These rules, and the idea of the Margolus neighbourhood, belong to the people credited above.

Try it

• Quick Start: Billiard ball machine, Critters, Tron, Single Rotation and HPP gas (Margolus).
• jetcarp run docs/scenes/automata/margolus-tron.json --gens 101 --png tron.png
• Draw a single cell in Single Rotation and watch it circle a 2 × 2 square with period 4.

References

• Fredkin and Toffoli 1982; Margolus 1984; Margolus 1999
• Toffoli and Margolus 1987; Toffoli and Margolus 1990
• Hardy, Pomeau and de Pazzis 1973; Hardy, Pomeau and de Pazzis 1973b; Hardy, de Pazzis and Pomeau 1976; Frisch, Hasslacher and Pomeau 1986; Margolus, Toffoli and Vichniac 1986
• dmishin 2013

Lenia

Lenia is a continuous cellular automaton. Instead of being alive or dead, each cell holds a value between 0 and 1; instead of counting a few neighbours, it takes a smooth weighted average over a wide ring around it. The result looks less like a grid of pixels and more like a dish of microorganisms: soft, round creatures that glide, rotate and divide. Bert Wang-Chak Chan, who created it, catalogued hundreds of them and named them like biological species.

What it is

Each cell holds a value A between 0 and 1. Every step:

1. Each cell computes a potential U, a weighted average of the values around it. The weights form a kernel K: a smooth ring of radius R cells (or several concentric rings), normalised so the weights add up to 1.
2. A growth function G turns the potential into a change between −1 and +1. It is positive when U is close to a preferred value μ (within a width σ) and negative otherwise.
3. The value moves by a small time step, A ← clip(A + G(U) / T, 0, 1), where T sets how many steps make one unit of time.

Life is a very coarse version of the same recipe: its “kernel” is the eight neighbours and its “growth function” is the birth and survival lists. Lenia smooths out space, states and time, and the creatures it supports reflect that: they look like living things rather than machines.

Where it came from

Bert Wang-Chak Chan introduced Lenia in “Lenia — Biology of Artificial Life”, posted in December 2018 and published in Complex Systems in 2019. The paper reports over 400 “species” in 18 families, gives them Linnaean-style names such as Orbium and Scutium, and studies their form and behaviour the way a biologist would (Chan 2019).

Chan places Lenia at the end of a line of generalisations of Life: Life itself (Gardner 1970), Chan’s own multi-state program “Primordia” from around 2005, Larger than Life (Evans 2001; Evans 2003; see Larger than Life), Marcus Pivato’s RealLife, the continuum limit of Larger than Life (Pivato 2007), and Stephan Rafler’s SmoothLife (Rafler 2011). Chan writes that SmoothLife and Lenia were developed independently and look strikingly alike, an example of what Chan calls convergent evolution, and traces a “phylogeny of the glider” from Life’s glider through Larger than Life’s bugs and SmoothLife’s smooth glider to Lenia’s creatures (Chan 2019).

Chan later extended Lenia to more dimensions, kernels and channels (Chan 2020), and Flow-Lenia made it conserve mass (Plantec et al. 2022). Chan’s reference code, in several languages, is open source under the MIT licence (Chan, Lenia code). Lenia has also become a test bed for automated discovery: intrinsically motivated goal exploration with learned goal spaces (Reinke, Etcheverry and Oudeyer 2020), quality-diversity search with MAP-Elites (Faldor and Cully 2024) and search guided by foundation models (Kumar et al. 2025).

How JETCARP runs it

Notation

JETCARP uses Chan’s parameters and the numbering of kernels and growth functions from Chan’s code:

Lenia R=13,T=10,b=1,m=0.15,s=0.015 is Orbium’s rule. The Orbium unicaudatus pattern itself comes from the animals.json file in Chan’s repository, used under its MIT licence; the seed {"lenia": {"name": "orbium"}} places it.

On any tiling

Lenia’s kernel is a ring in the plane, so JETCARP measures it with straight-line distances between tile centres, in units of the mean tile size (the square root of the mean tile area). On squares this is exactly Chan’s kernel. On hexagons, triangles and every Archimedean, k-uniform and isohedral tiling the kernel is precomputed per tile type; on aperiodic patches each tile gets its own list of kernel weights, and cells beyond the patch edge count as 0. This is the one family where JETCARP uses geometric distance instead of steps in the neighbour graph (see How JETCARP generalises automata).

Reproducible to the last bit

Lenia’s values are floating-point numbers, and the usual maths library functions can differ in their last bit from one operating system to another. JETCARP computes Lenia’s exponentials, powers and distances with its own portable arithmetic, using only operations that IEEE 754 defines exactly, and sums each cell’s kernel in a fixed order. The state hash includes every value’s exact bits, so a Lenia scene replays to the same hash on any machine and any number of threads, and the tests pin hashes to check it.

What is new here

Lenia is Chan’s. Running it on other tilings by measuring the kernel in the plane is a natural step, and we make no novelty claim for it.

Try it

• Quick Start: Orbium (Lenia).
• jetcarp run docs/scenes/automata/lenia-hat.json --gens 300 --png lenia-hat.png
• Try Orbium’s rule on hexagons or triangles from a random blob, and adjust m and s until something survives.

References

• Chan 2019; Chan 2020; Plantec et al. 2022; Chan, Lenia code
• Reinke, Etcheverry and Oudeyer 2020; Faldor and Cully 2024; Kumar et al. 2025
• Rafler 2011; Pivato 2007; Evans 2001; Evans 2003; Gardner 1970

The Abelian sandpile

The sandpile is a toy model of avalanches. Drop grains of sand on a grid one at a time; when a cell holds too many, it topples and passes one grain to each neighbour, which may make them topple in turn. The model became famous as the first example of self-organised criticality, and turned out to hide a beautiful piece of algebra: the stable piles form a group, whose identity element is a striking fractal picture. In JETCARP a tile topples when it holds as many grains as it has neighbours, so the model runs on any tiling, with a different threshold on every tile where tiles differ.

What it is

Each cell holds a whole number of grains. A cell with at least as many grains as it has neighbours is unstable: it topples, giving one grain to each neighbour and keeping the rest. Grains that would go past the edge of a finite grid are lost; the edge is a sink. Toppling continues until every cell is stable.

Two facts make the model special:

• Order does not matter. However the topplings are ordered, the final stable pile is the same. This is the abelian property that gives the model its name, and it means adding grains and then stabilising behaves like addition.
• The recurrent piles form a group. The stable piles that keep coming back when grains are added at random form a finite abelian group, the sandpile group. Every group has an identity element: here, the one recurrent pile that, added to any recurrent pile and stabilised, changes nothing. On a square grid this identity is an intricate fractal, and its shape depends on the shape of the grid.

A different classic experiment drops a great many grains on a single cell. The result is a large, roughly round pile with a fractal pattern inside that looks the same at every scale.

Where it came from

Per Bak, Chao Tang and Kurt Wiesenfeld proposed the sandpile in 1987 as an explanation of how systems can organise themselves into a critical state, in which avalanches of every size occur and their sizes follow a power law (Bak, Tang and Wiesenfeld 1987; 1988). Deepak Dhar showed in 1990 that the final state does not depend on the order of topplings, so that adding grains defines commuting operators and the recurrent configurations form an abelian group (Dhar 1990); Lionel Levine and James Propp credit the name “sandpile group” to Dhar (Levine and Propp 2010). Majumdar and Dhar later linked the model to spanning trees and the q → 0 Potts model (Majumdar and Dhar 1992).

The same dynamics have been invented several times under other names, including chip-firing; in combinatorics the main early reference is Björner, Lovász and Shor’s “Chip-firing games on graphs” (1991; see Levine and Propp 2010).

Michael Creutz drew attention to the identity element and its fractal structure on the square grid (Creutz 1991); Caracciolo, Paoletti and Sportiello call it the Creutz identity (Caracciolo, Paoletti and Sportiello 2008), and Le Borgne and Rossin studied it combinatorially (Le Borgne and Rossin 2002). Single-source piles on the square grid were studied by Srdjan Ostojic (Ostojic 2003), and Wesley Pegden and Charles Smart proved that the rescaled piles converge to a limit (Pegden and Smart 2013). Off the square grid, Fersula, Noûs and Perrot computed identities on triangular and hexagonal grids and on Penrose tilings (Fersula, Noûs and Perrot 2020).

How JETCARP runs it

The rule on any tiling

The rule is written Sandpile. A tile topples when its number of grains reaches its number of neighbours, so the threshold is the tile’s degree in the neighbour graph: 4 on squares and 6 on hexagons with edge neighbours, but anything from 3 to 12 on a 2-uniform tiling and 4 to 7 on the spectre. Sandpiles use edge neighbours by default; with touch neighbours a square topples at 8. Dead edges, and the open boundary of an aperiodic patch, are sinks. A wrapped grid has no sink, so it has no identity and cannot absorb more grains than it can hold.

Starting piles include {"pile": {"grains": N}} (N grains on the centre tile) and random heights; steps_per_gen sets how many toppling sweeps make one generation, so you can watch an avalanche spread or let it settle quickly.

The identity

JETCARP computes the identity of the sandpile group as stab(2m − stab(2m)), where m is the pile in which every tile holds one grain fewer than its threshold and stab means “topple until stable”. Its tests check that the result is idempotent, stab(I + I) = I, on squares, hexagons, Cairo pentagons and the spectre. The app’s Identity button and the scene command {"op": "sandpile", "action": "identity"} compute it on any tiling with sink edges.

Very large piles

jetcarp pile drops N grains on one tile of an unbounded grid. It never builds a tower of N grains: it reads N’s binary digits from the most significant end and repeats s ← stab(2s + bit · δ), where δ is one grain on the centre tile. The abelian property makes the result the same as stabilising all N grains at once, while heights stay small at every step. The board grows as the pile does, so no grain is ever lost, and on aperiodic tilings the pile is built on an exact patch of up to about 17 million tiles. Piles can be toppled on the GPU on periodic tilings, and are saved after every doubling step so a long run can be resumed. The app’s Sandpile… window builds one too, as a catalog job: it draws the pile as it grows, and a stopped pile carries on from its last finished step, from the window, the Hunts… window, or jetcarp jobs resume. See the guide Large sandpiles.

What is new here

Sandpile identities have been computed before on triangular, hexagonal and Penrose grids (see above), and on hexagonal and 4.8.8 grids in Eli T. Johnson’s master’s thesis (Johnson 2019); single-source piles on the square grid have a long literature. To our knowledge, JETCARP is the first to show sandpile identities and large single-source piles on the hat and spectre monotiles, on the k-uniform tilings with k of 2 or more, and on the Laves tilings other than the regular grids. The last are what the isohedral tilings amount to: a sandpile sees only the neighbour graph, and the 81 isohedral types have only the eleven graphs of the Laves tilings (see Isohedral tilings), so an identity on an isohedral type is an identity on its Laves tiling. Our search found no published sandpile work on the hat or spectre at all. The doubling method follows directly from the abelian property and is presumably known, so we do not claim it. The search is described in What is new in JETCARP.

Try it

• Quick Start: Abelian sandpile, Sandpile identity on Cairo pentagons, Sandpile on the Spectre, Sandpile on hexagons, and a sandpile on every tiling in the Tiling showcase.
• jetcarp run docs/scenes/automata/sandpile-identity-cairo.json --png identity.png
• jetcarp pile --tiling spectre --grains 1e6 builds a million-grain pile on the spectre.

References

• Bak, Tang and Wiesenfeld 1987; Bak, Tang and Wiesenfeld 1988; Dhar 1990; Majumdar and Dhar 1992
• Björner, Lovász and Shor 1991; Levine and Propp 2010
• Creutz 1991; Le Borgne and Rossin 2002; Caracciolo, Paoletti and Sportiello 2008
• Ostojic 2003; Pegden and Smart 2013
• Fersula, Noûs and Perrot 2020

Von Neumann’s 29-state automaton

John von Neumann designed this automaton in the early 1950s to answer a question about life itself: can a machine build a copy of itself, including the instructions for building the next copy? Von Neumann’s answer was a universal constructor made of cells, each with 29 states, connected to its four neighbours. Conway’s Life began as a simplification of its ideas. JETCARP runs it on the square grid, from the rule as published.

What it is

Every cell is in one of 29 states, and talks only to its four edge neighbours:

• Ground (unexcitable), the empty background.
• Transmission states: ordinary and special, each pointing in one of four directions, each quiescent or carrying a signal (16 states). A transmission cell passes a signal in the direction it points, one cell per step. A signal of the other kind (ordinary versus special) pointed at a transmission or confluent cell destroys it, turning it back to ground.
• Confluent states (4), which combine signals: a confluent cell fires only when all the ordinary cells pointing into it fire, and it delays its output, which lets it act as an AND gate and a memory element.
• Sensitised states (8), the intermediate steps by which a signal arriving at ground builds a new cell. A sequence of signals sent into ground decides, bit by bit, which of the other states the new cell becomes.

With these parts, a constructing arm can extend into empty space, build any pattern of cells by sending the right signal sequences, and withdraw again. Von Neumann’s design couples such an arm to a long tape of instructions; the machine reads the tape, builds a copy of itself, and copies the tape into it: self-reproduction from a description, a constructor and a copier.

Where it came from

Von Neumann’s work on automata began with “The General and Logical Theory of Automata” (1948) and a series of lectures at the University of Illinois in 1949, which described a kinematic self-reproducing machine built from mechanical parts. Arthur W. Burks writes that Stanisław Ulam suggested a cellular framework would be easier to treat mathematically. Von Neumann then designed an infinite array of square cells, each holding the same 29-state automaton. Von Neumann began the manuscript in September 1952 and worked on it until 1953, and left it unfinished (von Neumann 1966).

Burks edited and completed the work as Theory of Self-Reproducing Automata (1966), which states the transition rule and shows how to finish the self-reproducing design (von Neumann 1966). A footnote there notes that Edward F. Moore’s 1962 paper proposed the name “tessellation model” (Moore 1962). E. F. Codd later reduced the number of states to 8 (Codd 1968; see Rule tables).

The first working implementation of a self-reproducing universal constructor was built by Renato Nobili and Umberto Pesavento in 1994; to simplify the design they extended the rule so that confluent cells can cross signals (Pesavento 1995; Nobili and Pesavento 1996). Golly runs the original 29-state rule and the extended Nobili32 and Hutton32 variants (Golly: JvN), and Yinusa and Nehaniv used it to show that the completed machine passes heritable mutations to its offspring (Yinusa and Nehaniv 2011). Greg Turk’s 2025 review traces the line from von Neumann through Codd and Langton to the present (Turk 2025).

How JETCARP runs it

From the book

JETCARP’s JvN29 was written from Burks’s 1966 edition: the states and transition rule (section 2.8.1), its verbal summary (2.8.2) and the worked illustrations (2.8.3). The book’s formal statement of the rule is garbled in the scanned text that was available, so the implementation follows the clear verbal summary, which the legible parts of the formal rule agree with. Where the text left details open, the choices were checked against the book’s own examples:

• A cell is destroyed by a signal of the other kind pointing at it from any side, including head on, so an ordinary and a special signal pointing at each other destroy each other.
• Destruction wins over receiving a signal but not over sending one: a cell excited at one step still delivers its signal at the next, even though it has become ground.
• In the storage loop of Fig. 12 the text says four cells store five bits, which four one-step cells cannot do, so one of them must be a confluent cell (a two-step delay). Starting it that way reproduces the book’s trace exactly.
• The construct-and-withdraw sequence of Fig. 14 builds its path, writes the confluent cell and withdraws in exactly the 37 ticks the book states.

The book is in copyright; only the rule, which is an algorithm, is reimplemented. No code, rule files or patterns from other programs were used. JETCARP numbers the states its own way (ground 0, sensitised 1 to 8, transmission 9 to 24, confluent 25 to 28), so its patterns are not interchangeable with other programs’ files.

Notation and display

The rule is written JvN29 (also JvN or VonNeumann29). The Draw tool lists the states by name. Ordinary transmission cells are blue and special ones red, excited forms pale and bright; confluent cells are green and sensitised ones amber. Pictures draw an arrow on each transmission cell when tiles are at least 10 pixels across.

Square grid only

The rule depends on the four compass directions, so it has no meaning on other tilings, and JETCARP refuses to place it on one or to switch a world containing it to another tiling. Cells beyond a dead edge count as ground; wrapped edges work.

What is new here

Nothing. This is von Neumann’s automaton as Burks published it. JETCARP’s contribution is a fresh, documented reading of the book, with the ambiguities and how they were resolved written down.

Try it

• Quick Start: von Neumann: storage loops growing channels and von Neumann: construct and withdraw.
• jetcarp run docs/scenes/automata/vonneumann-construct.json --gens 37 --png construct.png runs the whole Fig. 14 sequence.

References

• von Neumann 1966; Moore 1962; Codd 1968
• Pesavento 1995; Nobili and Pesavento 1996; Golly: JvN; Yinusa and Nehaniv 2011; Turk 2025

Priority rules and the Spectre glider

For years it was an open question whether anything could glide across an aperiodic tiling: a small pattern that moves forever through a tiling that never repeats. In 2026 James Edmond found gliders on both of the new aperiodic monotiles, the hat and the spectre, by widening the space of rules to priority tables and searching it with an evolutionary algorithm. JETCARP runs Edmond’s rules, and reimplements that search on every tiling.

What it is

A priority table is a rule written as an ordered list of rows. Each row says: if the cell is in this state (or any state), and its neighbours meet these conditions, then its next state is this. The conditions are thresholds on how many neighbours are in each state, joined by “and”. The first row that matches decides the cell’s next state; a cell that matches no row becomes empty.

This is more expressive than a birth/survival rule, which only counts live neighbours, and it contains the Generations rules as a special case. Edmond found that searches over simpler rules on the hat and spectre turned up only travellers that eventually die, and that priority tables over the touch neighbourhood were rich enough to hold true gliders.

The Spectre glider rule is one such table with four states, of which it uses three. A head (state 1) excites wings (state 3) around it; a wing next to a head becomes a head; crowded wings die. The result is a relay that moves one ring of tiles every two generations. From the seed it emits two gliders on lanes 120° apart, and Edmond’s paper reports that its gliders travel a million rings at constant speed and heading (Edmond 2026).

Where it came from

Life on Penrose tilings was studied for its still lifes and oscillators; Hill, Stepney and Wan, and Owens and Stepney, found no moving objects (Hill, Stepney and Wan 2005; Owens and Stepney 2010). Adam P. Goucher found the first glider on an aperiodic tiling in 2012, with a four-state rule on a Penrose tiling (Goucher 2012); Edmond’s paper says this overturned a conjecture, backed by a small cash prize, that no such object exists. After the hat was announced in 2023, Andrew Trevorrow’s HatLife let people explore rules on it interactively, including a hand-designed “Worms” rule whose worms cross the patch (Trevorrow 2023).

James Edmond’s “Gliders on Aperiodic Monotilings: Cellular Automata on the Hat and Spectre” (2026) introduced priority tables, presented as Edmond’s own rule family, and found gliders on both monotiles with a genetic algorithm over four-state tables on the touch neighbourhood. The gliders’ headings fall on a “six-spoke compass”, and the Spectre glider is Edmond’s record of the evolved Spectre rule (Table 7 of the paper’s second version), found with no known rule planted in the search (Edmond 2026). Within weeks, Trevorrow’s HatLife and the new SpectreLife ran Edmond’s rules, SpectreLife with the glider rule modified to support eaters, oscillators and glider guns (Trevorrow 2026).

How JETCARP runs it

Notation

Priority <states>: is followed by rows separated by semicolons. Each row is <own state>|<conditions>-><next state>, where the own state is a number or * for any state, and the conditions are terms nS>=m (“at least m neighbours in state S”) joined by &, or always. The first matching row wins and the default is 0. SpectreGlider is exactly the three rows above: these are the rows of Edmond’s Table 7 that do not lead to state 0, since 0 is the default anyway.

On any tiling

A priority table only counts neighbours by state, so it runs on any neighbour graph (see How JETCARP generalises automata). Edmond’s rules use touch neighbours, which is also JETCARP’s default for them. The seed glider_pair places the Spectre glider’s two-tile seed at the centre of a patch.

Evolutionary search and verified movers

jetcarp search evolve reimplements Edmond’s evolutionary search and runs it on any tiling, periodic or aperiodic. It is written from Edmond’s paper and a reading of Edmond’s repository; two small functions, the mutation step and the table notation, are adapted from the monotile-ca code under its MIT licence, as listed in JETCARP’s third-party notices. Movers it finds on aperiodic tilings are followed across ever larger exact patches (jetcarp library movers track), or on a sliding window that generates tiles around the mover as it goes (jetcarp search mover), and recorded as verified to a distance: the number of rings of tiles the mover was followed without changing.

What is new here

Priority tables, the evolutionary method, the Spectre glider and the hat gliders are Edmond’s. The hat glider JETCARP’s search found is Edmond’s hat glider B in another table: with B’s states renamed, the two tables agree on every configuration the glider meets, and run side by side they give the same states every generation (checked for 1,467 generations on a level-7 patch). JETCARP’s table has one extra row, and its seed launches the glider on a different lane, which is why it first looked like a different glider. Credit for it is Edmond’s.

JETCARP’s own part is running the search on every tiling and verifying movers to a distance. For this glider that meant following it on a sliding window for 1,000,000 rings of tiles, at a steady 2.14 units per generation; Edmond’s certificates already prove it immortal. We make no novelty claim for this family. The comparison is described in Findings.

Try it

• Quick Start: Spectre glider and Spectre glider (Edmond 2026).
• jetcarp script docs/scenes/automata/glider-trail.rhai --out pictures --set scene=$PWD/docs/scenes/automata/priority-spectre-glider.json --set gens=70 --set png=trail.png draws the glider’s trail over 70 generations as one picture.
• jetcarp search evolve --help describes the search. Each search is a catalog job, saved after every generation: jetcarp jobs resume JOB carries on one that was stopped, ending exactly as an uninterrupted run would, and the app’s Hunts… window lists, stops, and resumes it. The app’s Catalog tools… window (the Evolve tab) starts one the same way, with Stop and Resume.

References

• Edmond 2026
• Goucher 2012; Hill, Stepney and Wan 2005; Owens and Stepney 2010
• Trevorrow 2023; Trevorrow 2026

Rule tables

Every family on the other pages has its rule built into JETCARP. A rule table is the way to write your own: a list of transitions, each saying “a cell in this state, with these neighbours in these positions, becomes this”. Rule tables can express almost any rule with a handful of states, including rules that depend on direction, which is how classic constructions such as Codd’s automaton and Langton’s loops are usually written down.

What it is

A rule table lists transitions of the form c,n1,…,nk:new: if the cell is in state c and its neighbours, read in a fixed order, are in states n1 to nk, its next state is new. Each position can also be * (any state) or a set of alternatives such as 1|2|3. A symmetry setting saves writing out every rotation of a case: rotate applies each transition to all rotations of the neighbours, rotate_reflect also to their mirror images, and permute treats the neighbours as an unordered collection. The first transition that matches wins; a cell that matches none keeps its state.

Because a table can tell neighbours apart by position, it can express rules that depend on direction: a signal travelling along a wire, a gate that only lets it pass one way. That is what made tables the standard way to write constructions like Codd’s.

Where it came from

Edgar F. Codd’s PhD thesis at the University of Michigan (1965), advised by John H. Holland, and Codd’s book Cellular Automata (1968) reduced von Neumann’s 29 states to 8 while keeping computation and construction universal, with signals running along wires wrapped in a sheath (Codd 1965; Codd 1968; Wikipedia: Codd’s cellular automaton). Christopher Langton’s self-reproducing loop of 1984 was derived from Codd’s periodic emitter; it replicates with a few dozen cells but does not compute universally (Langton 1984). Rules like these are naturally written as transition tables. Tim Hutton found four flaws in Codd’s published specification, corrected them and built Codd’s complete self-replicating computer, whose tape alone is 208 million cells long (Hutton 2010).

Golly’s RuleTable format, written by Hutton, made tables a common exchange format (Golly: file formats; Golly credits), and Hutton’s Rule Table Repository collected Codd’s rule, John Devore’s 1973 variant, Langton’s loops and their successors by Byl, Chou and Reggia, and Sayama (Rule Table Repository).

How JETCARP runs it

JETCARP’s own format

JETCARP’s tables are its own JSON format; it does not read Golly’s files and uses none of Golly’s code. A table looks like this:

{
  "name": "parity-example",
  "states": 2,
  "neighborhood": "edge",
  "symmetry": "rotate",
  "arity": 4,
  "transitions": ["0,1,0,0,0:1", "1,1,1,0,0:0"]
}

arity is the number of neighbours each transition lists. A scene can carry its own tables in a tables list, and the app can load one from a file; an automaton then uses it with the rule Table <name>. One table is built in: Table parity, Fredkin’s replicator rule on edge neighbours (each cell becomes the XOR of its four neighbours), generated in JETCARP from the rule’s definition.

Neighbour order on any tiling

The neighbours are read in the cell’s clockwise slot order, the same order turmites use for turning (see How JETCARP generalises automata). On squares with edge neighbours that is north, east, south, west. Edge neighbours are the default; touch neighbours can be chosen. Cells past a dead edge read as 0 (or 1 with live edges). On a tiling where tiles have different numbers of neighbours, a positional table only applies to tiles with exactly arity neighbours, and the others keep their state; a permute table counts neighbours without regard to position.

Codd’s automaton

JETCARP v0.4.0 does not ship Codd’s rule; adding it, written from Codd’s book, is on the roadmap.

What is new here

Nothing. Rule tables are a standard tool; JETCARP’s contribution is only its own file format and running tables on any tiling’s neighbour order.

Try it

• Quick Start: Parity (von Neumann table).
• jetcarp run docs/scenes/automata/ruletable-hex.json --gens 47 --png hex-parity.png, then edit the scene’s table and run it again.

References

• Codd 1965; Codd 1968; Wikipedia: Codd’s cellular automaton
• Langton 1984; Hutton 2010
• Golly: file formats; Golly credits; Rule Table Repository

Named rule catalogue

Generated page. Built by docs/tools/gen-named-rules.py from the program’s own rule list (crates/jetcarp-core/data/rules/named.json) and the credits file docs/data/named-rule-credits.tsv. Edit those files, not this page.

JETCARP knows 166 rules by name, collected from the rule lists that the Life community has kept for decades. You can type a name anywhere a rule is expected (jetcarp rules lists them, with a few more built-in names for families that have no standard list). Every one of them runs on any tiling, though most were found on the square grid and behave differently elsewhere; see How JETCARP generalises automata.

About the credits. Most of these rules were named, and often found, by hobbyists: through Mirek Wójtowicz’s MCell program and its rules lexicon in the late 1990s, the ConwayLife.com forums, and LifeWiki’s lists. The Credit column names a person only when a source does, with the role the source gives (found, named, studied). An empty cell means no source we checked names anyone, not that nobody did. Where sources disagree, both are shown. 76 of the 166 rules have a named person. The credits were checked in November 2026 against LifeWiki (read through its mirror, since conwaylife.com refuses automated reading), the MCell lexicon, Toffoli and Margolus’s Cellular Automata Machines (1987) and Wikipedia. If you know of an earlier or missing credit, please open an issue.

The Source column links the list each rule was taken from. The short descriptions JETCARP shows for each rule are written in our own words.

Life-like

Family page: Life-like.

Life-like (B0)

Family page: Life-like (B0).

Life-like, hexagonal

Family page: Life-like, hexagonal.

Life-like, von Neumann

Family page: Life-like, von Neumann.

Generations

Family page: Generations.

Larger than Life

Family page: Larger than Life.

Elementary

Family page: Elementary.

Agents

Family page: Agents.

Layered

Family page: Layered.

¹ Listed in the data file but not yet accepted by this version of JETCARP: Coexistence. Coexistence uses a weighted Larger than Life neighbourhood, which JETCARP does not read yet.

Tilings as neighbour graphs

A tiling covers the plane with tiles, leaving no gaps and no overlaps. For a cellular automaton, what matters about a tiling is not the shapes of its tiles but who is next to whom: its neighbour graph. JETCARP builds that graph for every tiling it supports, and every rule runs on the graph. This page explains how the graph is made and why two very different-looking tilings can be the same thing as far as an automaton is concerned.

What it is

The neighbour graph has one node for each tile and a link between every two tiles that are neighbours. There are two kinds of neighbour (see How JETCARP generalises automata):

• Touch neighbours share any part of their boundary: an edge or just a corner.
• Edge neighbours share a stretch of edge, not just a point.

A tile’s number of neighbours is its degree. In a tiling with one kind of tile placed the same way everywhere, every tile has the same degree; in mixed tilings the degree depends on the tile; in aperiodic tilings it varies irregularly across the plane. The tiling catalogue lists the degrees of every tiling.

Many tilings that look different have the same graph. A brick wall in running bond has the same neighbour graph as the hexagon tiling, and so does a herringbone pattern: each tile meets six others in the same arrangement. Escher’s lizards, on the three-fold hexagon tile, are hexagons as far as a rule is concerned. Any rule that only counts neighbours behaves identically on tilings whose graphs are the same, so a pattern found on one is a pattern on the other. This matters for honest claims. Every isohedral tiling has the graph of one of the eleven Laves tilings, so JETCARP’s 81 isohedral types are only eleven worlds for a rule: 30 of them are the square grid, 19 the hexagonal grid, 8 the triangular grid and 3 the Cairo tiling (see Isohedral tilings). Spaceships first found on isohedral tilings were Conway’s glider and its relatives in a different drawing. Likewise the quadrilateral, glide and four-fold families are squares and the Pythagorean tiling is 4.8.8. JETCARP compared all 362 combinations of its tiling families, isohedral types and 2- and 3-uniform tilings with both neighbourhoods and found 196 distinct graphs (Findings).

Rules that turn, such as Langton’s ant, also need the order of a tile’s neighbours around it, so JETCARP keeps each tile’s neighbours in clockwise order. And one family, Lenia, uses actual distances between tile centres, so for it the geometry matters too.

Where it came from

The standard reference on tilings is Branko Grünbaum and G. C. Shephard’s Tilings and Patterns, which defines the terms used here, such as edge-to-edge tilings and the symmetry groups of periodic tilings (Grünbaum and Shephard 1987; 2nd edition 2016). Treating the cells of an automaton as the nodes of a graph is a standard idea; the earliest automata already defined their neighbourhoods as fixed sets of nearby cells, named after John von Neumann and Edward F. Moore (Moore 1962). General tools that run rules on arbitrary polygon meshes, such as Ready, work the same way (Ready).

How JETCARP runs it

Building the graph

JETCARP stores a tiling in one of three ways, depending on its kind:

For tilings that are not edge to edge, such as herringbone, the Pythagorean tiling and tiles you draw yourself, JETCARP measures contact from the geometry: two tiles are edge neighbours if they share a stretch of boundary and touch neighbours if they share any point. The tests check tilings for overlaps and gaps.

Size and edges

A periodic world is a rectangle of whole unit cells, given either as a number of cells (roughly square) or as a width and height in unit cells. Its edges can be dead (cells beyond count as empty), wrapped (a torus, so the tiling has no edges at all) or live (cells beyond count as alive). An aperiodic world is a patch of a chosen level, from 10 tiles at level 1 to about 35,000 at level 5 and about 18 million at level 8, always the tiles nearest a fixed centre, so smaller patches sit inside larger ones. Aperiodic patches have dead edges.

Different tilings, same rule

Because rules only see the graph, any scene can switch tiling and keep its rules (apart from the few families tied to one grid; see How JETCARP generalises automata). jetcarp tilings and jetcarp isohedral print the degrees JETCARP measures.

What is new here

Nothing on this page is new as an idea. What JETCARP adds is breadth: the same graph model for the regular, Archimedean, k-uniform, isohedral, drawn and aperiodic tilings, so that every rule runs on all of them. JETCARP’s exploratory search also treats the tiling itself as one of the dimensions it explores; see What is new in JETCARP.

Try it

• jetcarp tilings lists every tiling family with its edge and touch degrees.
• Run the same rule on the brick tiling and on hexagons: it behaves the same way on both, because the graphs are the same.
• jetcarp run docs/scenes/tilings/graph-rhomb.json --gens 1 --png rhomb.png

References

• Grünbaum and Shephard 1987; Grünbaum and Shephard 2016
• Moore 1962; Ready

Regular and Archimedean tilings

The regular tilings, by triangles, squares or hexagons alone, are the grids most cellular automata were born on. Add the eight Archimedean tilings, which mix regular polygons so that every corner looks the same, and you have the eleven uniform tilings of the plane. Each gives a rule a different neighbour graph: some tiles see three neighbours, some eighteen, and in the mixed tilings neighbouring tiles see different numbers. JETCARP runs every rule on all eleven.

The eleven uniform tilings, named by their vertex configurations, with JETCARP's family ids. Thumbnails from the tiling catalogue, drawn by JETCARP with each tile in a random colour.

What it is

A tiling by regular polygons is edge to edge when tiles meet only along whole edges, corner to corner. It is uniform (or 1-uniform, Archimedean) when every vertex looks the same: the same polygons, in the same order, meet at each corner. A vertex is described by listing the polygons around it, so 4.8.8 means a square and two octagons, and 3.3.4.3.4 means triangle, triangle, square, triangle, square. Repeated numbers can be written with exponents: 3⁶ for six triangles, 3².4.3.4 for the snub square.

There are exactly eleven: the three regular tilings 3⁶, 4⁴ and 6³, and the eight mixed ones 3.6.3.6 (trihexagonal, also called kagome), 4.8.8 (truncated square), 3.12.12 (truncated hexagonal), 4.6.12 (truncated trihexagonal), 3.4.6.4 (rhombitrihexagonal), 3.3.3.4.4 (elongated triangular), 3.3.4.3.4 (snub square) and 3.3.3.3.6 (snub hexagonal), which comes in two mirror-image forms.

For an automaton the differences are large. With touch neighbours a triangle in the triangular tiling has 12 neighbours, a hexagon 6; in 3.3.3.3.6 each hexagon touches 18 tiles and each triangle 9. In 3.12.12, touch and edge neighbours are the same (3 for a triangle, 12 for a dodecagon), because no two tiles meet at a corner only. Rules that count neighbours respond to all of this.

Where it came from

The regular tilings are ancient as patterns. The first systematic mathematical treatment of edge-to-edge tilings by regular polygons, including the eight further Archimedean tilings, is Johannes Kepler’s in Book II of Harmonices Mundi (1619) (Kepler 1619; English translation Kepler 1997). Darrah Chavey’s 1984 thesis examined Kepler’s results in detail (Chavey 1984). Branko Grünbaum and G. C. Shephard surveyed the subject “from Kepler to the present” in 1977 and in their book Tilings and Patterns, the standard modern reference (Grünbaum and Shephard 1977; 1987).

The dotted vertex notation (4.8.8) is commonly named after H. M. Cundy and A. P. Rollett’s Mathematical Models (Cundy and Rollett 1961); Grünbaum and Shephard use exponents. Later notations designed for generating tilings automatically include the GomJau-Hogg notation (Gomez-Jauregui et al. 2021).

Cellular automata on these tilings have their own history. Carter Bays studied Life-like rules on the triangular tiling (Bays 1994) and on hexagons and Cairo pentagons (Bays 2005), and wrote an overview (Bays 2009). In June 2013 EricG emulated all eight mixed Archimedean tilings and their duals in Golly, with cells that share an edge or a vertex as neighbours, and reported spaceships in Life-like rules on every one of the eight, in Life itself on 3.6.3.6, 3.3.4.3.4 and 3.3.3.4.4 (EricG 2013); EricG named rules but did not list the ships, and the pattern files are no longer online. A 2014 Code Golf challenge ran Life on several non-square tilings; Peter Taylor found only oscillators on 3.4.6.4 (Code Golf 2014). H. S. Guttesen ran Life on six of the mixed Archimedean tilings, described gliders on 3.6.3.6 and 3.3.4.3.4 and built a glider gun on 3.6.3.6 (Guttesen 2026).

How JETCARP runs it

The triangle, square and hexagon tilings are reshapeable families (triangle, square, hex): their tiles can be any triangle, any parallelogram or any of a family of hexagons, and the regular shapes are the default (see Editable tile families). The eight mixed tilings are fixed families: trihex, oct, trunchex, trunctrihex, rhombitrihex, elongtri, snubsq and snubhex. All eleven also appear in the k-uniform catalogue as its k = 1 entries, k1-001 to k1-011.

In a scene the tiling is given by its family id, a size and an edge rule, for example "tiling": {"family": "rhombitrihex", "size": {"cells": 9000}, "boundary": "wrap"}. A flat-topped version of the hexagon tiling, hex_flat, exists for the three-parent hexagonal row rules.

What is new here

The tilings are classical. On them, JETCARP’s searches have found spaceships in Life-like rules on 4.8.8, 3.12.12, 4.6.12, 3.4.6.4, 3.3.3.4.4 and 3.3.3.3.6, and on 3.6.3.6 in rules other than Life. After the checks described in What is new in JETCARP, six single ships with no flag remain on these tilings, four on 3.3.3.4.4 and one each on 3.4.6.4 and 3.3.3.3.6. They run in none of the rules in which EricG reported ships, and to our knowledge they have not been reported before. Three of the four on 3.3.3.4.4 were found in strips of squares and triangles inside 2- and 3-uniform tilings; their live tiles evolve the same way on the elongated triangular tiling itself, so they are listed there. Two ships on 4.8.8 and two on 3.12.12 passed the same checks but run in the B2 and B26 rules where EricG saw many ships, so they are flagged until EricG’s patterns can be compared. Four ships are below.

The others on these tilings are described rather than claimed. On 4.8.8, 3.12.12, 4.6.12, 3.6.3.6 and 3.3.3.4.4 the rest are small ships that turn up often in soups, ships in well-known rules such as HighLife or B2/S34, or a smaller ship with a passenger, and others may well have seen them. Guttesen’s Life gliders on 3.6.3.6 and 3.3.4.3.4 (on tilings where EricG had seen Life spaceships in 2013), which JETCARP also found, are Guttesen’s, and so are the pairs of them that JETCARP’s catalogue first listed as separate ships. In Life on 3.3.4.3.4, JETCARP also found two larger ships built around Guttesen’s glider, of periods 16 and 24; we found no earlier report of them. Every ship is listed in Findings.

A census of Life itself, 50,000 random soups on each of the eleven tilings, found spaceships only on the square grid, 3.6.3.6, 3.3.4.3.4 and 3.3.3.4.4 (see Life on the Archimedean and k-uniform tilings). On the first three they are Conway’s and Guttesen’s ships, the pairs and bound pairs those form, and the larger snub-square ships above. On 3.3.3.4.4 it is one ship, now and then flying in a pair: eight to twelve cells, period 2, moving along the rows at c/2, in about one soup in eleven. It is probably the “common spaceship (although it only travels horizontally)” that EricG reported there in 2013, although EricG’s patterns are not online to compare. On the hexagonal and triangular grids, 4.8.8, 3.12.12, 4.6.12, 3.4.6.4 and 3.3.3.3.6 no soup produced a Life ship; on the last five, Guttesen and the 2014 Code Golf challenge had found none either.

Try it

• Quick Start, family Tiling showcase: a lively rule and a sandpile on each of the eleven.
• jetcarp run docs/scenes/tilings/archimedean-rhombitrihex.json --gens 200 --png 3464.png
• Run Life (B3/S23) on trihex from a random start and look for small gliders, as Guttesen did.
• jetcarp run docs/scenes/tilings/ship-57a0326c.json --gens 126 --png ship.png runs the period-42 ship for three periods.

References

• Kepler 1619; Kepler 1997; Chavey 1984
• Grünbaum and Shephard 1977; Grünbaum and Shephard 1987
• Cundy and Rollett 1961; Gomez-Jauregui et al. 2021
• Bays 1994; Bays 2005; Bays 2009; EricG 2013; Code Golf 2014; Guttesen 2026

k-uniform tilings

Allow more than one kind of corner and the eleven uniform tilings grow into an enormous family. A tiling by regular polygons is k-uniform when its corners fall into k classes: within a class every corner is the same, but the classes differ. JETCARP carries Brian Galebach’s complete catalogue up to k = 6, all 1,248 tilings, and every rule runs on each of them.

What it is

In an edge-to-edge tiling by regular polygons, two corners are equivalent if a symmetry of the whole tiling (a translation, rotation or reflection that maps the tiling onto itself) carries one onto the other. The tiling is k-uniform if there are exactly k classes of corner. The 1-uniform tilings are the eleven Archimedean tilings. With k = 2 there are 20, and the numbers grow quickly:

A tiling’s name lists the vertex type of each class, in square brackets: [3.4.6.4; 4.6.12] has one class of corners where a triangle, two squares and a hexagon meet and another where a square, a hexagon and a dodecagon meet. When different tilings share a name, a number is added (#1, #2). Mixing polygons this way gives tilings where neighbouring tiles have very different degrees, which changes how rules behave from one region to the next.

Six of the 2- and 3-uniform tilings. The full list, with neighbour counts, is in the tiling catalogue.

Where it came from

Otto Krötenheerdt classified the k-uniform tilings in which every class has a different vertex type in three papers in 1969 and 1970 (Krötenheerdt 1969; 1970; 1970b). Branko Grünbaum and G. C. Shephard treated k-uniform tilings in their 1977 survey and in Tilings and Patterns (Grünbaum and Shephard 1977; 1987). Darrah Chavey’s 1984 thesis gave the number of 3-uniform tilings, 61, and Chavey’s 1989 paper is the standard printed catalogue (Chavey 1984; Chavey 1989).

Brian Galebach wrote a program that generates complete sets of k-uniform tilings. Galebach’s entry in the On-Line Encyclopedia of Integer Sequences records 151 4-uniform and 332 5-uniform tilings (2002) and 673 6-uniform tilings (2003); Galebach’s page says the 6-uniform run took about a month of computation and reproduced Krötenheerdt’s list (Galebach, OEIS A068599; Galebach, n-uniform tilings). Marek Čtrnáct later extended the counts to k = 13 and, with Eryk Kopczyński, built an online tessellation catalogue (Čtrnáct and Kopczyński).

José Ezequiel Soto Sánchez, Tim Weyrich, Asla Medeiros e Sá and Luiz Henrique de Figueiredo gave an integer representation for periodic tilings by regular polygons (Soto Sánchez et al. 2021; see also Medeiros e Sá et al. 2018), and Soto Sánchez publishes Galebach’s collection in that form, with an online viewer, under the CC BY 4.0 licence (Soto Sánchez, tiling viewer). That file is JETCARP’s source.

How JETCARP runs it

JETCARP includes Soto Sánchez’s Galebach file unchanged, with attribution under its CC BY 4.0 licence. A script rebuilds each tiling exactly, in coordinates that are whole-number combinations of twelfth roots of unity, finds its translation lattice, symmetry group and vertex classes, and rejects anything inconsistent. The tilings are numbered kN-NNN in Galebach’s order. (The one exception to exact coordinates is 4.8.8, whose octagons need different numbers; it is built separately.)

In a scene a catalogue tiling is a periodic tiling with a catalogue id: "tiling": {"family": "periodic", "params": {"catalog": "k3-011"}, "size": {"cells": 9000}}. Scripts accept the id directly as the tiling (world(#{ tiling: "k3-011" })). In the app, the tiling panel’s Tiling catalog lists every tiling and can be filtered by k or searched by vertex type or symmetry group.

What is new here

The catalogue is Galebach’s, and the data and its representation are Soto Sánchez and colleagues’. What JETCARP adds is running cellular automata on all of it. Our prior-art search found no published cellular automaton work on k-uniform tilings with k of 2 or more. JETCARP has computed sandpile identities and piles across the catalogue, and its searches have found Life-like spaceships on 2- and 3-uniform tilings. No 2- or 3-uniform tiling has the neighbour graph of a lattice, of Cairo or of an Archimedean tiling (the k-uniform tilings with k from 4 to 6 have not been surveyed), so a ship found on one is not a lattice ship in disguise.

A k-uniform tiling can still contain a corridor of a simpler tiling, and a ship that runs in such a corridor belongs to the simpler tiling. JETCARP’s skeptical pass checked every ship against all the 2- and 3-uniform tilings: eight ships found on 3-uniform tilings run unchanged on a 2-uniform tiling or on 3.6.3.6, and are claimed there, and others run on several tilings of the same k. A looser congruence test, which asks only that the live tiles evolve the same way whatever the neighbour counts of the empty tiles around them, moved eight more: five ships of strips of squares and triangles run on the Archimedean tiling 3.3.3.4.4, and three 3-uniform ships run on a 2-uniform tiling. It also showed that two pairs of catalogue entries are one ship each. After those checks, 13 single ships with no flag on 2-uniform tilings and 6 on 3-uniform tilings are, to our knowledge, new; a few more are flagged because they were very common in their search or run in HighLife. All are listed in Findings; see also What is new in JETCARP.

Those ships run in rules other than Life. A census of Life itself (B3/S23), 50,000 random soups on each of the 81 2- and 3-uniform tilings, found Life spaceships on 5 of the 20 2-uniform tilings and on 19 of the 61 3-uniform ones. To our knowledge, Life had not been reported on any 3-uniform tiling before, nor on any 2-uniform tiling but k2-007, where Martin Büttner very likely found a period-20 ship in 2014; other rules had been run on k2-001, [3.4.6.4; 4.6.12], without ships (see What is new in JETCARP). Most of what the census found is common ships flying in pairs, or ships of simpler tilings running in corridors; the single ships that passed every check are in Life on the Archimedean and k-uniform tilings.

Treating the tiling as a dimension of an exploratory search also depends on having this catalogue.

Try it

• Quick Start, family Tiling showcase: entries on k2-001, k2-002, k3-011, k4-100, k5-058 and k6-673.
• jetcarp run docs/scenes/tilings/kuniform-k3-011.json --gens 200 --png k3-011.png
• In a script, for id in catalog_tilings(2) { ... } loops over the 2-uniform tilings.

References

• Krötenheerdt 1969; Krötenheerdt 1970; Krötenheerdt 1970b
• Grünbaum and Shephard 1977; Grünbaum and Shephard 1987; Chavey 1984; Chavey 1989
• Galebach, OEIS A068599; Galebach, OEIS A068600; Galebach, n-uniform tilings; Čtrnáct and Kopczyński
• Soto Sánchez et al. 2021; Medeiros e Sá et al. 2018; Soto Sánchez, tiling viewer

Isohedral tilings

An isohedral tiling uses a single tile shape, placed so that every tile is surrounded in exactly the same way: some symmetry of the tiling carries any tile onto any other. Escher’s drawings of birds, fish and lizards interlocking across the page are, almost all, isohedral tilings with decorated tiles. There are 93 types, and JETCARP supports the 81 of them that can be told apart by the tile’s shape alone, each with sliders that reshape the tile within its type.

What it is

Grünbaum and Shephard sorted isohedral tilings into 93 types, IH1 to IH93, by the way each tile’s edges and corners relate to its neighbours’: which edges must match which, and by what symmetry (a slide, a half turn about the edge’s midpoint, a rotation about a corner, a reflection). Within a type, a tile can change shape freely as long as those relations hold. Twelve of the types are marked: they need a motif drawn inside the tile to cut its symmetry down, so as bare shapes they coincide with other types. That leaves 81 types that can be told apart by shape alone.

For an automaton, the type fixes the neighbour graph, whatever the parameters: reshaping a tile changes the picture but not which tiles touch. Many types give the hexagonal graph (six neighbours each); others give the square grid’s or something else. The same rule can behave very differently on two tilings that look alike, and identically on two that look different; the tiling catalogue lists each type’s degrees, and the next sections show that there are only eleven graphs in all.

Where it came from

Elli and Heinrich Heesch completed a classification of 28 types of asymmetric tiles that give isohedral tilings in 1932; they submitted it in 1934 but chose not to publish, and tried for years to patent it (Reichenberger 2023). Heesch and Otto Kienzle published the 28 types in Flächenschluß (1963), with each tile’s boundary described as a word in letters for its edge symmetries; their scheme leaves out tilings with mirror lines (Heesch and Kienzle 1963; Kaplan and Schattschneider 2025).

Branko Grünbaum and G. C. Shephard gave the complete classification, with “incidence symbols”, in “The eighty-one types of isohedral tilings in the plane” (1977) and a polygonal version in 1978: 93 types, of which twelve are marked (Grünbaum and Shephard 1977; 1978; 1987). Nearly all of M. C. Escher’s regular divisions of the plane can be read as isohedral tilings (Kaplan and Schattschneider 2025); Doris Schattschneider’s Visions of Symmetry is the standard catalogue of Escher’s periodic drawings (Schattschneider 1990). Tom McLean’s online catalogue gives a template for each of the 93 types (McLean).

Craig S. Kaplan brought the types into computer graphics. Kaplan’s thesis and work with David Salesin on “Escherization” derive Escher-like tilings from shapes a user supplies (Kaplan 2002; Kaplan and Salesin 2000), and Kaplan’s book explains the types for programmers (Kaplan 2009). Kaplan’s Tactile library, in C++ and JavaScript, represents all 81 non-trivial types and lets their tiles be reshaped (Tactile; TactileJS).

How JETCARP runs it

JETCARP’s isohedral families ih01 to ih93 (81 of them) are converted from TactileJS’s tables, used under Kaplan’s BSD 3-Clause licence. Each type has Tactile’s parameters (from none to six) and its edge shapes: free curves, curves mirrored about their midpoint, half-turn symmetric curves, and straight lines. Tactile’s description of each type gives the unit cell, so the usual periodic storage, wrapped or dead edges, drawing and automata all apply. In a scene: "tiling": {"family": "ih28", "params": {"p": [0.45, 0.5]}}; without p, Tactile’s default shape is used.

In the app, pick Isohedral IH01–IH93 in the family list, then the type and its parameter sliders; Edit tile… lets you drag corners and reshape edges, and the editor keeps the tile within its type. jetcarp isohedral lists the types with their symmetry groups and neighbour counts, and jetcarp isohedral --png sheet.png draws them all, as above.

Eleven graphs: the Laves tilings

Every isohedral tiling is combinatorially one of the eleven Laves tilings, the duals of the eleven uniform tilings: count the tiles meeting at each corner of a tile, and the sequence (written in brackets, such as [3².4.3.4] for the Cairo tiling) is one of eleven (Grünbaum and Shephard 1987). An isohedral tiling and its Laves tiling are the same tiling topologically, with the same edge and touch neighbour graphs, so a rule that only counts neighbours behaves on the one exactly as on the other. JETCARP’s survey of neighbour graphs sorted the 81 types as follows (Findings):