Data and publishing

Publishing data from GameBoyGhost is like publishing logs from a production system. They are valuable, but you scrub them first. You keep what helps others verify and learn. You remove what you don’t have the right to share, or what nobody needs.

The planned pipeline

The PLANNED path from a campaign to a public dataset. The validator is the gate: nothing uploads unless every fingerprint checks out and nothing excluded slipped through.

What a public shard would contain (PLANNED)

According to the author’s notes, public shard exports would include:

Part	What it is
Features	The values the student saw at each decision, meaning its fixed 909-value view.
Labels	The oracle’s answer for each of those views.
Actions	What was actually done (the move class) and how it went.
Outcomes	How each run ended: success, budget exhausted, refusal, and so on.
Manifests	The frozen job list, with machine-specific details removed.
Ledger hashes	The fingerprint chain, so anyone can check the data matches what was recorded.
Replay proofs	Evidence that the runs reproduce, such as import proofs and comparison results.

Hugging Face (a popular host for machine-learning datasets) and GitHub are the planned destinations.

What is left out, and why

The author’s notes state what is excluded. The “why” column is an editorial reading based on the project’s own rules, not a quote.

Left out	Why (editorial)
Raw game memory	The student learns only from its fixed 909-value view. That view is the documented subset that matters for the data. Raw memory is the game’s own internal state.
Screen frames	Not needed to learn from the data. Short, verified clips on this site are the exception: chosen moments only, from the author’s capture pipeline.
The game file, saved states, the start point	Never shared, anywhere. The project rules treat them as private files that never enter git or any upload.

what the existing files contain, and what an exporter must strip

From the current campaign format, each shard’s detail files include:

Frame log: one row per game frame, with the move, button masks, modes and fingerprints. It also includes a small peek of raw memory bytes at a few fixed addresses, which an export must remove.
Decisions: the move class, status, reason, frames used and observations, plus the oracle’s labels for oracle runs. This is the natural source of actions, labels and outcomes.
Records: typed refusals, interruptions and failures. These are never training labels (rule R6).
Result file: checks, outcome, counts and fingerprints.

Some bound inputs must never be exported. The large route-scoping frame log contains full raw memory dumps. Manifests bind the game file and the start point. Older manifests and some replay notes contain machine-specific absolute paths that would need scrubbing.

How the footage is made

This section describes the clips and stills that are on the site now. It is not a plan.

Every clip and still on this site is rebuilt from a recorded run and checked as it is rebuilt. Think of a chain of custody for evidence. A copy is not trusted on its own; it is checked, piece by piece, against the original case log.

One boot. The emulator (software that imitates the Game Boy hardware) loads the project’s fixed starting point once. No saved game positions are loaded after that.
Replay the recorded inputs. The emulator is fed the exact button presses recorded during the original run. Nothing new is decided; the program that made the run is not asked again.
Compare on every frame. A frame is one still picture of the game; the Game Boy draws about 60 a second. After each frame, a hash of the game’s state is compared with the hash recorded during the original run. A hash is a short fingerprint computed from data: change one byte and the fingerprint changes completely.
Any mismatch means no clip. A mismatch stops the render before any picture is written, so a failed check produces no footage at all.

The “Verified replay” badge under each clip or still means that all four steps passed for every frame from the start of the run to the last frame shown.

The badge certifies the game state, not individual pixels. The pictures are then encoded into WebM, a compressed video format for the web. Compression shifts colors very slightly: in the capture report, no color value in any decoded clip was more than 12 steps away (out of 255) from the emulator’s own picture. The pixel art is enlarged 4 times by copying pixels, never by blending them.

Screen-off frames are shown white. During some room transitions the Game Boy switches its screen off for a few frames. The emulator draws those frames black. On real Game Boy Color hardware a switched-off screen is blank white, so the site shows them white. This also avoids rapid black flashes. Only the picture changes; the game state check is unaffected. The clips with such frames are:

The oracle plays S3 on its own (hero-s3-full): 7 frames
The oracle plays S3 (real time) (hero-s3-realtime): 9 frames
Assigning an item in the menu (menu-assign): 7 frames

Each item has a “Provenance” detail. Open it under any clip or still to see the source run, the exact frame range, the playback speed, and the item’s verified range digest: one fingerprint that covers the per-frame records of exactly the frames in that item. It also lists the SHA-256 fingerprint of every file, so a downloaded copy can be checked against it. (SHA-256 is a standard hash.)

Playback speed. Most clips play in real time. Two long stretches are sped up by skipping frames: at 3× speed the clip shows every third frame, and at 6× every sixth. The speed is shown next to the badge whenever it isn’t 1×.

One planned clip is missing on purpose. Part of that run was not recorded frame by frame. Rebuilding it would mean running the program again rather than replaying a recording, and that would not be evidence of what actually happened. Its slot says “Coming soon”.

the exact verification rules

Every render loads the start point once and makes zero memory writes and zero saved-state loads. A read-only wrapper around the emulator refuses a second load and any save.
Frames 1 to 6 are settle frames after the start-up load. The recorded log starts at frame 7, so they cannot be checked, and no clip includes them. The earliest frame shown anywhere is 12917.
Frames from a teacher run (the teacher is the project’s earlier expert program) are compared with its frozen frame log, row by row. Frames from an oracle run (the oracle is the newer expert program built for S3) are compared with the recorded ticks, one record per frame: the frame number, the record’s fingerprint, 15 bytes read from game memory, and the fingerprint after the tracker (the running summary of the game) was updated.
Verified range digest: the SHA-256 of one line per frame in the range, each line being the frame number and that frame’s recorded digest.
Picture: enlarged 4 times by nearest neighbor (each pixel copied into a 4 by 4 block) to 640 by 576, encoded as VP9 video in WebM at 59.7275 frames per second. The site then shows it at 3 or 2 times the native 160 by 144 size, with pixel blending turned off.
The first frame after the screen comes back on has its top line of pixels black (1 of 144 lines). It is left as the emulator drew it.
The first clip was rendered and encoded twice, in separate processes. The two video files are byte-identical.

The premiere plan (decided Oct 4, 2026)

The public premiere is a full chain: from power-on, through the dungeon Tail Cave, to collecting an item called the Full Moon Cello.

The current design runs to the boss door (segment S18).
Segments for the boss (Moldorm), the Heart Container and the Cello will be designed later. Moldorm is planned as a dedicated effort, possibly with a “practice range” for overnight batches (see the cookbook).
Datasets and this website will be published incrementally, before the premiere, not all at once at the end.

Gameplay footage from The Legend of Zelda: Link’s Awakening DX, captured from the author’s own emulator runs for technical commentary. The game and its imagery are © Nintendo. This project is not affiliated with or endorsed by Nintendo. How the footage is made.