clawbot cb7ddfdb67 test: drive the autosave race test to a condition, not a turn count (closes #36)
TestAutoSaveOnSignalRacesTurnLoop failed intermittently under load. The
captured failure text settles what it was: driveUntilDone's

    t.Fatal("the turn loop ran out of turns before the saves were taken")

with no WARNING: DATA RACE anywhere in the log. The handoff is fine; the
test's own drive loop ran out of its fixed 1000-turn budget first.

Confirmed by instrumenting the loop to report the turns it actually
used. The count tracks scheduling pressure and nothing else: about
60-120 turns at host load ~57 with the whole machine to spread over, 418
at GOMAXPROCS=4, 539 and 655 at 2 and 1, and past 1000 under the doubled
load of the verbose rerun the test target performs after a failure. The
turns spent between one save being answered and the next request
arriving are not work, they are the saving goroutine's wake-up latency,
so a fixed turn count is a wall-clock assumption in disguise. Raising it
would hide the flake, not fix it.

So the budget is gone rather than larger. driveUntilDone drives until
the saving goroutine finishes and nothing else. Termination still holds,
it just belongs to the code under test: every AutoSaveOnSignal returns
within the timeout it is handed, and g.sigSave is one deep, so an
unserviced request stays in the channel and every later call finds it
full and fails at once. A dead handoff therefore releases the saving
goroutine after one autoSaveWait however many saves were asked for, and
what fails is the real assertion - "saves taken = 0, want 25" - rather
than "out of turns".

Removing the cap exposed a second assumption underneath it. testTerm
answers space and newline for ever once its script is exhausted, and
neither key takes a turn, so command(), which loops until the player
consumes one, never returns; the old cap was silently sized to the
script. An uncapped drive wedged inside a single command() call. The two
drive tests now use driveTerm, a headless terminal whose script repeats,
so every key it hands out takes a turn.

The guard is undiminished, shown by mutation and reverted afterwards.
Reverting the fix from the earlier signal-autosave work - AutoSaveOnSignal
replaced by a direct g.autoSave(), encoding on the calling goroutine -
still fails the test with 139 DATA RACE reports, snapshotHeader reading
what executeCommand writes. Removing serviceAutoSaveRequest from
command() still fails it too, now in 10s with "saves taken = 0, want 25"
instead of by hanging.

Under load: at GOMAXPROCS=2 on a 48-core host at load ~150, with an
unrelated deliberate failure in the tree so every run took the verbose
rerun, the old code failed 8 of 8 runs and the new code 0 of 8. Also
green across 24 concurrent unconstrained runs at load ~120, 10 runs
alongside a spinner load, and 5 runs each at GOMAXPROCS 1, 2 and 4.

No non-test code changed. make check green, lint 0 issues, .golangci.yml
byte-identical.
2026-08-09 16:45:34 +00:00
2016-07-23 03:24:54 +01:00
2016-07-23 03:24:54 +01:00
2016-07-23 03:24:54 +01:00

Rogue: Exploring the Dungeons of Doom (Go port)

License

Rogue is the original dungeon-crawling adventure game that spawned an entire genre. This branch is a faithful Go port of Rogue 5.4.4: explore procedurally generated dungeons, fight monsters, collect treasure, and attempt to retrieve the Amulet of Yendor.

Original authors: Michael Toy, Ken Arnold, and Glenn Wichman (19801983, 1985, 1999).

The port is function-by-function faithful to the classic C sources — same dungeon generation (seed-compatible RNG), same combat math, same item tables, same messages. The C reference implementation lives on the master and modern-rogue branches; ARCHITECTURE.md documents both the original program structure and the design of this port.

Building and running

Requires Go 1.25 or later and a terminal at least 80x24.

go build ./cmd/rogue
./rogue
# Restore a saved game
./rogue ~/rogue.save

# View high scores
./rogue -s

# Test the death screen (demo mode)
./rogue -d

In-game commands

Press ? in game for the full list.

  • arrows or h/j/k/l/y/u/b/n — move (shift to run, ctrl to run until adjacent)
  • . rest, s search for hidden doors and traps
  • i inventory, , pick up, d drop
  • q quaff potion, r read scroll, e eat food
  • w wield weapon, W wear armor, P/R put on / remove ring
  • t throw, z zap a wand, f/F fight
  • >/< take the stairs
  • S save, Q quit

Environment

# Game options, as in the original
export ROGUEOPTS="name=YourName,terse,jump,fruit=mango"

# Wizard (debug) mode, with a reproducible dungeon
ROGUE_WIZARD=1 SEED=12345 ./rogue

The scoreboard is kept in ~/.rogue.scores. Save files are Go gob snapshots and, as in the original, are deleted when restored.

Code layout

game/        the game engine: one Go file per original C file,
             function-by-function (see ARCHITECTURE.md for the mapping)
term/        tcell-backed terminal, replacing curses
cmd/rogue/   the executable

The engine package is fully headless-testable: make test runs scripted command sequences, dungeon-generation golden checks, and an RNG compatibility test against the original C generator.

For development, the Makefile wraps the toolchain: make fmt (gofmt + prettier), make lint (golangci-lint), make test (the suite, under the race detector with coverage and a timeout), and make check (all three). Use the targets rather than invoking go test directly — they carry the flags the project relies on.

License

BSD-style; see LICENSE.TXT.

Copyright (C) 1980-1983, 1985, 1999 Michael Toy, Ken Arnold and Glenn Wichman. All rights reserved.

Description
No description provided
Readme 3.4 MiB
Languages
Go 99.3%
Makefile 0.5%
Shell 0.2%