The Workshop · Formats, engines, and the counts they were checked against
We take old software apart.
Games from 2001 and 2002, with no source code and no manual. We worked out their file formats from the files they shipped with, and rebuilt one engine by measuring what the original drew. Every claim below carries the number of files it was tested on — 1,063 of 1,063 in the first row — so you can check it instead of taking it on trust.
The method is the same every time: measure the original, validate against it, write it down.
The public record
Each repository, with what it was checked against.
| Repository | What it is | Evidence |
|---|---|---|
| granny1-parser | A parser and converter for RAD Granny 1 (.grn) — the file a game keeps its characters and their animations in, and the one Granny generation that never had a public reader. It writes glTF, the format every current 3D tool opens. One file, Python 3, standard library only. | 1,063 / 1,063 files |
| grn-re | The written .grn specification the parser follows — one claim per line, each with the number of files it was checked on. We compared the mesh section corner by corner against what the original runtime draws. | 674 + 389 files, 2 games |
| jn-engine | A rebuild of a Direct3D 7-era game engine, written clean-room (from captures of what the original drew, never from its code) and compared against those captures frame by frame. One body of C that builds for Linux, 64-bit Windows, and the browser. | frame-by-frame against captures |
| SB2-RE | How a 2002 adventure game actually behaves — its file formats, movement, scripts, scenes and menus — worked out from its own executable and data files, and written down so someone can rebuild it without reading the original code. Checked by an oracle: 48 fixed points where the rebuild has to match the original. | 48-checkpoint oracle |
| mechanix-re | The same treatment for a 2001 game: 47 class sheets with inheritance, sizes, and vtables; file formats; level markers; asset bindings; and the oracle that checks them. | 47 class sheets |
| mechanix-baseline | A working implementation built from that specification — and SPEC-GAPS.md, the list of what the spec turned out not to say. The spec is tested by building from it. | spec gaps, published |
→ git.exentt.com · specifications and measurements, not game code or game assets · wrong turns published alongside findings
Running proof
Live in your browser. Nothing to install.
Granny 1, decoded
Every character, item, and animation of two 2002 games — 215 models, 862 clips — decoded by the published parser from the games' own files. Pick a model, pick an animation, drag to orbit.
Open the asset viewer → /jnvsjn/ · ENGINE REBUILDPlay a 2002 game in a tab
The rebuilt engine running the original game's levels in a browser tab. The same code builds for Linux and Windows; the browser build is here so you do not have to install anything to check it.
Play the levels → /sp2/ · ASSET LAYERInside Employee of the Month
Open the game's own data files and walk through them — the archives it ships its scenes in, the scenes, and each object inside, with the specification's name for it alongside. This is what a recovered format looks like from the inside.
Explore the assets →The discipline is the same on every project: find out what the thing actually does, compare the rebuilt against the original, write it down, hand it over. The workshop is where that is practiced at full difficulty, on systems nobody is paying to save.
The repositories hold measurements, formats and tables — none of the games' code or art, no branded screenshots, no private capture material — and each states its clean-room rules: you may measure the original, you may not copy from it.
I’m Alex Scott. Exentt is one person, and every measurement on this page is mine, so if a count is wrong the correction comes to me.
If you have a file only one program can open, tell me what it is.