HelpImStuckInAFractal

Walking tools

Walking follows the ground gradient design (docs/superpowers/specs/2026-10-28-ground-gradient-walking-design.md): a fan of GPU rays cast from the eye samples the ground around the player, and the player walks on its smoothed height field with a fixed down (the negative of the level’s spawn up). Production walking never evaluates the fractal on the CPU. The tools below may, as offline oracles.

Gameplay → Walk on fractals switches modes, Show ground gradient draws the overlay, and Pre-query rings sets the fan’s reach. The Walking console tab holds speed, azimuths, maximum ray angle, smoothing, slope limit, hole depth and the show-rays toggle. When the player is grounded, the overlay draws a green circle at the feet, sized by body width × player scale. Look straight down to see it, because the helmet’s field of view is narrow.

Authoring a standing spawn

godot4 --headless --path . -s tools/walking/create_ground_save.gd

This searches the default Mandelbox top for flat ground using the CPU oracle. It builds the real GroundFan from oracle rays, keeps candidates whose ring 1 is fully walkable with clear head rays, prefers fans that also contain a wall and a hole, and writes saves/walking_mandelbox_ground.json. The spawn rotation is upright, so ground up is +Z.

Native capture (windowed; needs explicit authorisation)

godot4 --headless --import --path .   # refresh the class cache first
open -g -n -a /Applications/Godot_mono.app --args --path "$PWD" --resolution 1280x720 \
  --log-file "$PWD/build/walking-validation/ground/goldKleinian.log" \
  -s tools/walking/ground_capture.gd -- --trailer --ground-save=res://saves/goldKleinian.json \
  --probe --background-window --no-link --quit-after=300

--player-scale=X overrides the level’s scale for evidence runs; the output folder gets a -scaleX suffix. The harness quits its own instance. It disables the GameplayRoom node, because the CPU oracle cannot see the room’s geometry.

It writes build/walking-validation/ground/<save>/:

• screenshots: 01 spawn, 02 each direction, 03 obstacle, 04 falling and respawn fade, 05 after the hole, 06 overview, 07 feet with the grounded circle;
• frames/ (8 fps JPEGs);
• report.json.

Encode the MP4 afterwards:

ffmpeg -framerate 8 -i build/walking-validation/ground/<save>/frames/%05d.jpg \
  -c:v libx264 -pix_fmt yuv420p build/walking-validation/ground/<save>/capture.mp4

The run fails, with a non-zero exit and failures listed in report.json, on any of these checks:

• a walkable or steep cell where more than 12 of a 5×5 oracle probe grid miss within hole depth;
• a smoothed vertex plus skin inside geometry;
• an eye DE below body_width × 0.25 × scale, or movement that reduces the eye DE while inside that bound;
• less than one cell walked in any direction;
• surface speed more than 5 % off walking_speed × scale;
• movement over unresolved ground without woozy and a visible vignette;
• walking toward a wall that neither climbs nor stops.

The harness walks into a confirmed hole cell and reports the result. It does not fail the run when a “hole” turns out to be a descent deeper than hole depth that the player walks down.

Other harnesses

load_check.gd (menu Play, loads, held keys), held_check.gd, manual_check.gd, controls_capture.gd and render_isolation.gd still run against the current controller. Their status strings are now acquiring ground, idle, walking, stopped, falling, respawning and blocked.