Game of Life JavaScript: Commit a Whole Generation

Updating one cell before counting its neighbor makes the answer depend on traversal order. Read one unchanged grid and commit another so the generation is simultaneous.

The five-by-five finite-board inspector steps a horizontal three-cell blinker into a vertical one and back. A stable block and isolated corner preset expose survival and boundary handling without wraparound.

Game of Life JavaScript: Commit a Whole Generation
Game of Life JavaScript: Commit a Whole Generation
Open the full example ↗

Use the worked example

Load Blinker, press Step twice, and compare the live-coordinate lists. To inspect without changing a pattern, read the Last committed transition table after a step. Clicking a cell while paused both reports its pre-edit neighbor decision and toggles that cell; the edited grid becomes the generation-zero reset seed.

Trace the result step by step

Simultaneous updating is explained in the Game of Life tutorial. A neighbor count must describe one complete starting grid. If cells change while other counts are still being calculated, reversing the loop order can change the result even though the rule itself is unchanged.

The board has five rows and five columns, indexed 0–4. Cells hold Alive or Dead. Each cell counts its eight surrounding positions, excluding itself; any position outside the board contributes zero. There is no wrapping from column 4 to column 0 or between top and bottom.

The rule is B3/S23: a dead cell becomes alive with exactly three live neighbors; a live cell survives with two or three. Other cells are dead in the next generation. This is a cellular-automaton rule, not a biological forecast.

The initial seed has live cells (2, 1), (2, 2) and (2, 3). All other cells are dead. The starting display shows generation 0 and population 3 beside the board.

A Step reads the complete current grid and calculates all 25 neighbor counts and next states from that snapshot. No current cell changes while another count still depends on it.

For (2, 2), the two adjacent live cells count; its own Alive state does not add a third neighbor. For (1, 2), all three original live cells are neighbors.

A dead cell with two neighbors remains dead. The survival number two applies to an already-live cell; it is not a birth rule. Keep current state and count together when explaining the decision.

The next grid contains every cell’s result. Once all decisions are complete, it replaces the current grid and the generation increases by one.

The center (2, 2) remains alive with two neighbors. The other 20 cells remain dead. Step 1 therefore has exactly (1, 2), (2, 2) and (3, 2) alive, population 3.

Step 2 restores the horizontal blinker, with the same population of three but different coordinates from Step 1. Compare that with Block, which remains at its four original coordinates, and Isolated corner, whose only live cell dies on its first step. Each preset answers a different rule question.

The Last committed transition table retains all 25 cells with the source generation, before state, neighbor count, and next state. It includes unchanged cells so the complete simultaneous decision remains inspectable after the board advances.

Read a transition count with its source generation. After Step 1, the stored counts describe the original horizontal blinker, while the board shows the new vertical one. Keep those two moments separate when explaining why a cell was born or died. Editing clears that transition because the edited pattern becomes a new seed. Focus returns to the cell you toggled, so keyboard editing can continue from the same position. Reset restores the seed and clears both the transition and the old pre-edit explanation.

Copy a prompt for this example

Create one HTML cellular-automaton explorer with a finite five-by-five grid. Coordinates are zero-based. Each cell counts its eight surrounding positions, excludes itself, and treats positions outside the board as dead. There is no wraparound.

Use B3/S23: a dead cell is born with exactly three neighbors; a live cell survives with two or three. Compute all next states from the same unchanged current grid, then replace the grid and increment generation once.

Start with a horizontal blinker alive at (2,1), (2,2), (2,3). One Step gives (1,2), (2,2), (3,2), and another returns to the initial pattern. Add Block with live cells (1,1), (1,2), (2,1), (2,2), and Isolated corner with only (0,0) alive.

Show generation, population, and live coordinates. A Last committed transition table must retain all twenty-five cells with source generation, before state, neighbor count, and after state. Keep that historical transition distinct from the new board.

Provide Step, Run, Pause, pattern buttons, and Reset seed. Run advances one generation every 500 milliseconds. While paused, clicking a cell both reports its pre-edit neighbor decision and toggles it; the edited grid becomes the new generation-zero reset seed. Make that combined behavior explicit. Ignore edits while running and pause when hidden.

Use labeled cell buttons and a board that fits a narrow screen. Return all HTML, styles, and logic in one file.

Keep the starting pattern and boundary rule with your source when reviewing the transition. You can preview the prepared HTML inspector in NOS and compare each whole-grid commit with the cell explanation. Use the block and corner cases as separate checks rather than assuming every pattern has period two.

Keep reading