The Fixed Tick

// cmd/worldd/main.go — a throwaway main: one walker, three machines
package main

import "fmt"

// byFrame moves a walker east at 3 cells per second, once per frame,
// on a machine that produces a frame every dt seconds.
func byFrame(name string, dt float64, frames int) {
	pos := 0.0
	for i := 0; i < frames; i++ {
		pos += 3.0 * dt
	}
	fmt.Printf("%-13s %3d frames of %.4fs -> x = %.4f\n", name, frames, dt, pos)
}

// byTick moves the same walker 0.3 cells per tick, ticks being the
// only unit it knows about.
func byTick(name string, ticks int) {
	pos := 0.0
	for i := 0; i < ticks; i++ {
		pos += 0.3
	}
	fmt.Printf("%-13s %3d ticks            -> x = %.4f\n", name, ticks, pos)
}

func main() {
	fmt.Println("motion measured in frames:")
	byFrame("fast machine", 1.0/144, 100)
	byFrame("normal", 1.0/60, 100)
	byFrame("busy laptop", 1.0/48, 100)

	fmt.Println("motion measured in ticks:")
	byTick("fast machine", 100)
	byTick("normal", 100)
	byTick("busy laptop", 100)
}

$ go run ./cmd/worldd
motion measured in frames:
fast machine  100 frames of 0.0069s -> x = 2.0833
normal        100 frames of 0.0167s -> x = 5.0000
busy laptop   100 frames of 0.0208s -> x = 6.2500
motion measured in ticks:
fast machine  100 ticks            -> x = 30.0000
normal        100 ticks            -> x = 30.0000
busy laptop   100 ticks            -> x = 30.0000

The top three lines are three different worlds. Same code, same walker, same hundred passes around the loop, and the walker lands on column 2.08, column 5, or column 6.25 depending on nothing but who ran it.

Nobody wrote a bug; the loop was asked the wrong question. The damage also compounds: put a wall at column 6 and the busy laptop's walker is through it while the fast machine's walker is nowhere near, so the runs disagree about events and not merely positions.

The bottom three lines are one world described three times. Ticks do not know what a second is, so there is nothing in them for hardware to change.

// internal/sim/world.go — World gains one field and one reader
type World struct {
	Ground *Grid

	tick   uint64 // sim time: how many ticks this world has taken
	ents   map[EntityID]*Entity
	nextID EntityID
}

// Tick is how many ticks of sim time this world has taken.
func (w *World) Tick() uint64 { return w.tick }

// internal/sim/tick.go
package sim

import (
	"errors"
	"fmt"
	"time"
)

// TickRate is how many ticks of sim time one second of wall time is
// meant to hold.
const TickRate = 10

// TickDuration is the wall-clock budget for one tick.
const TickDuration = time.Second / TickRate

// Step advances the world by exactly one tick.
func (w *World) Step() error {
	w.tick++
	if err := w.spreadWater(); err != nil {
		return fmt.Errorf("tick %d: spread water: %w", w.tick, err)
	}
	if err := w.driftWalkers(); err != nil {
		return fmt.Errorf("tick %d: drift walkers: %w", w.tick, err)
	}
	return nil
}

// driftWalkers steps every walker one cell west, in ID order. A
// walker the ground refuses stays where it is.
func (w *World) driftWalkers() error {
	for _, e := range w.Roster() {
		if e.Kind != Walker {
			continue
		}
		err := w.Move(e.ID, e.At.Offset(-1, 0))
		switch {
		case err == nil:
		case errors.Is(err, ErrBlocked), errors.Is(err, ErrOutOfBounds):
			// nowhere to go this tick; the walker stays
		default:
			return err
		}
	}
	return nil
}

Three decisions are packed into that small file. TickRate is a constant declared once, in the package that owns the world's laws, so no caller can hand the simulation a different one and get a different history.

TickDuration is derived from it instead of typed out as 100 * time.Millisecond. It is the only time value in the file, existing for the loop's benefit and not the world's.

Step increments the counter first, before any law runs, so a law reading w.tick sees the number of the tick it is computing. The world's first step is tick 1, and nothing that happens in it gets stamped with the 0 the world sat at before it began.

The field is lowercase and the reader is the method Tick(), for the reason chapter 5 made the entity map private: a counter anyone outside the package can assign to is a counter that can be made to disagree with the history it labels.

driftWalkers walks Roster, not the entity map, which cashes in chapter 5's lesson: map order is randomized, roster order is by ID.

With walkers that only drift west, the order looks harmless. When two entities want the same cell, order decides who gets it, and a world whose outcomes follow map iteration order disagrees with itself between runs.

The two tolerated error kinds are a decision too. An entity that cannot move is ordinary, so those are absorbed here; anything else is a bug and goes up to whoever runs the loop.

// internal/sim/tick.go — the fix: collect, then apply

// spreadWater floods every soil cell that touched water at the start
// of this tick, and no cell that only touches water because of it.
func (w *World) spreadWater() error {
	g := w.Ground
	flooding := make([]Coord, 0, 16)
	for y := 0; y < g.H; y++ {
		for x := 0; x < g.W; x++ {
			c := Coord{X: x, Y: y}
			t, err := g.At(c)
			if err != nil {
				return err
			}
			if t != Soil {
				continue
			}
			for _, d := range neighbours {
				n, err := g.At(c.Offset(d.X, d.Y))
				if err != nil {
					continue // off the grid holds no water
				}
				if n == Water {
					flooding = append(flooding, c)
					break
				}
			}
		}
	}
	for _, c := range flooding {
		if err := g.Set(c, Water); err != nil {
			return err
		}
	}
	return nil
}

// cmd/worldd/main.go — one shrub, one walker, six ticks by hand
	w := sim.NewWorld(sim.Generate(12, 8, 5))
	w.Spawn(sim.Shrub, sim.Coord{X: 9, Y: 1})
	w.Spawn(sim.Walker, sim.Coord{X: 10, Y: 6})
	for i := 0; i < 6; i++ {
		fmt.Printf("tick %d\n%s", w.Tick(), w.Render())
		if err := w.Step(); err != nil {
			fmt.Println("step:", err)
			return
		}
	}
	fmt.Printf("tick %d\n%s", w.Tick(), w.Render())

$ go run ./cmd/worldd   (ticks 0 through 3 of 6)
tick 0
############
#........o.#
#..........#
#.~~~~~....#
#.~~~~~~...#
#...~~~~...#
#...~.....@#
############
tick 1
############
#........o.#
#.~~~~~....#
#~~~~~~~...#
#~~~~~~~~..#
#.~~~~~~~..#
#..~~~~~.@.#
############
tick 2
############
#.~~~~~..o.#
#~~~~~~~...#
#~~~~~~~~..#
#~~~~~~~~~.#
#~~~~~~~~~.#
#.~~~~~~~@.#
############
tick 3
############
#~~~~~~~.o.#
#~~~~~~~~..#
#~~~~~~~~~.#
#~~~~~~~~~~#
#~~~~~~~~~~#
#~~~~~~~~@.#
############

Now the water moves like water: one cell in every direction, once per tick, the front advancing evenly out of the pond chapter 4's seed drew, north rim on the same schedule as south.

Two costs bought that. The scan visits every cell whether or not anything near it is wet, fine at 96 cells and ruinous at a million. The slice of pending changes is a second copy of part of the world, the standard price of simultaneity.

Watch the walker too, the first thing in this book stopped by an event and not by an argument. It starts at column 10 and drifts to column 9 on tick 1.

On tick 2 its step west would enter water that arrived this tick, Move returns ErrBlocked, driftWalkers absorbs it, and it stands at column 9 while the flood closes around it. Nothing coordinated the two. They met because they share a tick.

The shrub is the honest wart. It stands at tick 6 with water on every side, because nothing re-checks an entity's ground after that ground changes: allows runs when a request is made, and the shrub never made one.

That is a real gap, and it is the sort a world can only see once it has a tick to see things in.

// cmd/worldd/main.go — the sleeping loop, timed
// load stands in for the work later volumes will do inside a tick.
const load = 30 * time.Millisecond

func main() {
	w := sim.NewWorld(sim.Generate(40, 20, 5))
	start := time.Now()
	for w.Tick() < 30 {
		if err := w.Step(); err != nil {
			fmt.Println("step:", err)
			return
		}
		time.Sleep(load)
		time.Sleep(sim.TickDuration)
	}
	fmt.Printf("%d ticks at %d/s should take %.2fs\n", w.Tick(), sim.TickRate,
		float64(w.Tick())/sim.TickRate)
	fmt.Printf("wall time actually spent: %.2fs\n", time.Since(start).Seconds())
}

$ go run ./cmd/worldd   (timings measured on the author's machine; yours will differ)
30 ticks at 10/s should take 3.00s
wall time actually spent: 3.91s

Three seconds of sim time took 3.91 seconds to deliver. The loop sleeps a full tick after doing the tick's work, so every iteration costs the budget plus the work, and the error accumulates: thirty ticks, thirty helpings of 30 ms, nine tenths of a second behind.

That 30 ms is padding standing in for ecosystem, creature, and villager work inside Step. Run this for a day and the world is hours behind the wall clock, perfectly correct about its own history and useless as a place anyone can visit.

// cmd/worldd/main.go — the loop on a ticker

// step does one tick's work: the world, then the padding.
func step(w *sim.World) {
	if err := w.Step(); err != nil {
		panic(err)
	}
	time.Sleep(load)
}

func main() {
	w := sim.NewWorld(sim.Generate(40, 20, 5))

	ticker := time.NewTicker(sim.TickDuration)
	defer ticker.Stop()

	start := time.Now()
	for w.Tick() < 30 {
		<-ticker.C
		step(w)
	}
	fmt.Printf("%d ticks at %d/s should take %.2fs\n", w.Tick(), sim.TickRate,
		float64(w.Tick())/sim.TickRate)
	fmt.Printf("wall time actually spent: %.2fs\n", time.Since(start).Seconds())
}

$ go run ./cmd/worldd   (timings measured on the author's machine; yours will differ)
30 ticks at 10/s should take 3.00s
wall time actually spent: 3.03s

Same work, same padding, and the drift is gone: 3.03 seconds instead of 3.91. The difference is what each loop counts from.

The sleeping loop measures forward from whenever it happened to finish, so every delay it suffers is added to the next deadline permanently. The ticker's deadlines were laid down in advance, one every 100 ms from the moment it was made, so early work waits and long work eats slack that was already allocated.

Nothing about the world changed, only its delivery.

One property matters more than the timing. If a tick's work badly overruns its budget, the ticker does not queue the missed beats and fire them in a burst; it drops them and delivers only the most recent.

The loop then runs slower in wall time and the world falls behind real people, a capacity problem you can measure and fix. Catching up instead, by running extra ticks, would call Step at a rate set by how overloaded the machine is: the leak this chapter closes.

// internal/sim/terrain.go — a number to compare runs by

// Count is how many cells of the grid hold terrain t.
func (g *Grid) Count(t Terrain) int {
	n := 0
	for _, c := range g.cells {
		if c == t {
			n++
		}
	}
	return n
}

// cmd/worldd/main.go — one hundred ticks, twice, at two speeds
const (
	seed  = 5
	ticks = 100
	load  = 30 * time.Millisecond
)

// run advances a fresh world for n ticks, recording the water count
// after every one. If paced, it runs at TickRate; otherwise it runs
// as fast as the machine allows.
func run(n int, paced bool) ([]int, time.Duration) {
	w := sim.NewWorld(sim.Generate(40, 20, seed))
	trace := make([]int, 0, n)

	var ticker *time.Ticker
	if paced {
		ticker = time.NewTicker(sim.TickDuration)
		defer ticker.Stop()
	}

	start := time.Now()
	for w.Tick() < uint64(n) {
		if paced {
			<-ticker.C
			time.Sleep(load)
		}
		if err := w.Step(); err != nil {
			panic(err)
		}
		trace = append(trace, w.Ground.Count(sim.Water))
	}
	return trace, time.Since(start)
}

func main() {
	fast, fastWall := run(ticks, false)
	slow, slowWall := run(ticks, true)

	fmt.Printf("unpaced: %d ticks in %.1fms of wall time\n", len(fast),
		float64(fastWall.Microseconds())/1000)
	fmt.Printf("paced:   %d ticks in %.2fs of wall time\n", len(slow),
		slowWall.Seconds())
	fmt.Println("water counts identical, all", ticks, "ticks:", slices.Equal(fast, slow))
	fmt.Println("water at ticks 1, 5, 20, 100:",
		fast[0], fast[4], fast[19], fast[99])
}

$ go run ./cmd/worldd   (wall times measured on the author's machine; yours will differ)
unpaced: 100 ticks in 0.4ms of wall time
paced:   100 ticks in 10.03s of wall time
water counts identical, all 100 ticks: true
water at ticks 1, 5, 20, 100: 33 137 625 684

Twenty-five thousand times the wall time, and not one number out of place. Both runs were 33 water cells into the flood at tick 1, both had filled all 684 cells of the valley floor by tick 100, and both passed through the same counts in the same order between.

The wall-clock figures are the only lines that change on your machine.