| Filename | Latest commit message | Latest commit date |
|---|---|---|
scotty
64b36c73bc
The minigames were listed for the whole project as needing a human at the controls. That was true of validating them and got quietly read as being true of specifying them. It is not. Nobody had read a single one of the seven entry points I attributed weeks ago. All four share one 92-byte manager whose entire state is a 20-field map, and the two biggest findings are couplings rather than rules: - THE SLOT MACHINE AND THE MAZE ARE ONE PUZZLE. The three words the slots use as reels are the same three the maze reads as its combination. A winning spin writes symbols 5-8 and sets an "armed" flag; `maze n` then wants n+5 to equal each in turn, so the four symbols map exactly onto the four directions the junction scene c2l5s4 wires to smaze0-smaze3. Unarmed, every step resets you to the entrance -- and the direct route past the maze is the trigger whose condition is `xxxx`, which is never true. That soft-block was already documented; this is what it was for. - THE FOURTH SPIN ALWAYS WINS. One spin in three wins by chance and a counter guarantees it by the fourth. A losing spin re-rolls until all three reels differ, so a loss can never accidentally look like a win. - THE PHONE NUMBER IS 555-4444, seven digits with a cosmetic dash after the third, and the phone is dead until the script `sphone1` has run. - Darts places the dart at the mouse cursor, offset by a fixed calibration and scattered uniformly +/-25 pixels per axis, three throws to a round. The +/-25 window is the entire difficulty model. Its SCORING is not read and is the one real gap left. Confirmed from the data side where possible: c2l5s4's four exits are exactly smaze0-3, each script a single `maze n` line; c2l5s3 is the slot machine scene and the only one in the game carrying ANIM v27, its elements named slotarm, slotspin, slotwin and 253light1-3, which `slots spin` drives by name. Every rule here is READ, not observed. Nobody has spun the machine to check that the fourth spin wins. That is now the only thing on this page that needs a human, and it is a much smaller ask than specifying the games was. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
| DATA | ||
| ORACLE | ||
| PROCESS | ||
| SPEC | ||
| .gitignore | ||
| CONTRIBUTING.md | ||
| README.md | ||
| REBUILD.md | ||
| START-HERE.md | ||
SpongeBob SquarePants: Employee of the Month — reimplementation specification
A behavioural and structural specification of SpongeBob SquarePants: Employee of the Month (AWE Games / THQ, 2002), recovered from the shipped binaries and data files, published so it can be reimplemented cleanly.
This repository contains no game code and no game assets. It contains measurements, formats, and tables — see the clean-room note for why that boundary exists and what it means for contributors.
Start here
| If you want to… | Read |
|---|---|
| Understand what's known and how solid it is | SPEC/README.md |
| Load the game's data files | SPEC/formats/ |
| Make a character walk correctly | SPEC/MOVEMENT.md |
| Understand where a character may stand | SPEC/WALK-GRID.md |
| Wire up scenes, triggers and progression | SPEC/SCENE-EVENT-MODEL.md |
| Run the game's scripts | SPEC/SCRIPT-LANGUAGE.md |
| Build the menus and presentation | SPEC/UI-AND-PRESENTATION.md |
| Draw a frame | SPEC/RENDERING.md |
| Consume the data programmatically | DATA/ — TSV |
| Know how any of this was established | PROCESS/FINDINGS.md |
| See what was got wrong, and what caught it | PROCESS/WRONG-TURNS.md |
| Understand validation | ORACLE/README.md |
| Know what you'd still have to work out | SPEC/IMPLEMENTATION-GAP.md |
What the engine is
Employee of the Month runs on Open Media Toolkit (OMT) by Yves Schmid / GarageCube — a
cross-platform C++ 2D/3D framework released under LGPL. The game ships OMT.dll, which exports
1,703 symbols with full MSVC C++ decoration across 182 OMedia* classes, out of 1,728 exports in total.
That decoration is not an obstacle, it is documentation: it encodes the class, the method, the access level, whether the method is virtual, the calling convention and every parameter type. And 49 of those 182 classes have published LGPL source, so a third of the engine is cited rather than guessed.
The other two thirds are not. OMT.dll here is a later or AWE-modified OMT than the published
v2.5, and the movement code alone turned up two methods — OMediaElement::update_abs_position and
getabsolutepos{x,y,z} — that exist in the shipped build and in no published header. Where this
spec relies on those, it says so.
Character rendering is RAD Game Tools' Granny 1.2b (granny.dll), which the executable calls
directly. Movies are Bink (binkw32.dll).
The Granny 1 file format is now specified too, in a separate project — https://git.exentt.com/scotty/grn-re —
because it is not specific to this game. Granny 2 had community parsers; Granny 1 had none, so the
character meshes, skeletons and animations of every game that shipped on it were unreadable without
the vendor runtime. All 674 .grn files here read, as do 389 of 389 from Jimmy Neutron vs. Jimmy
Negatron.
The executable is sb2.exe, 364 KB. Internally the project was called Bob2 — two original
source paths survive in the binary, C:\THQ\Bob2\GAME\Awe.cpp and
C:\THQ\Bob2\GAME\ObjectFactory.cpp.
If you are here to build it
REBUILD.md is the brief: the one rule, the build order stage by stage, and what to do
when a page cannot be implemented as written. SPEC/ACCEPTANCE.md is how you
know a stage worked — 42 numbers reproducible from a retail install alone, no executable and no
disassembler, currently 42 for 42.
Status, stated plainly
Asset layer: complete. Five previously-undocumented formats read end to end — 1,332 files,
zero parse failures (123 .scn, 315 .omt, 168 scripts, 52 dialogue, 674 .grn) — including the Granny 1 character assets, which had no public parser in any
game until now. See SPEC/formats/.
Walk grid: solid, and validated against the running game. World coordinates map to .scn GRID
cells with 99.8–100 % of sampled character positions landing on walkable cells across two
independently generated captures, p < 10⁻⁵. Every click destination lands exactly on a cell centre.
See SPEC/WALK-GRID.md.
Movement pipeline: solid, path-finder included. Every stage from mouse click to rendered
position has an observed address and a measured behaviour. The route is an 8-connected least-cost
grid search with integer costs 64 orthogonal / 90 diagonal, then collinear points removed to leave
turning points — validated against deliberately-chosen detour captures, 6 of 6 exact. See
SPEC/MOVEMENT.md §6.
Scene and event model: solid. All 123 scenes, 356 scene links (of 440 distinct targets — the
rest start scripts, play a movie or say a line), every hotspot/trigger/animation/item
under the game's own English labels, the save format that records progress, and the gating language
as implemented — an expression is a conjunction unless it contains " or ", and a term resolves by
its first letter into script / scene / item, or by length into a thread flag. See
SPEC/SCENE-EVENT-MODEL.md.
Script language: solid for structure, partial for semantics. Not bytecode — tab-separated text
dispatched by case-insensitive string comparison. The runtime form is an array of 128-byte line
records, four 32-byte fields each, capped at 50 lines; both limits were derived from the
interpreter and then confirmed against the shipped scripts. The interpreter understands three verbs
no shipped script uses. See SPEC/SCRIPT-LANGUAGE.md.
Class structure: first pass. 1,001 functions recovered, four AWE subclass vtables resolved slot
by slot into "inherits OMT" vs "AWE override", and an object factory that instantiates 27 OMT
classes by decorated constructor name. See SPEC/ENTITY-OBJECT-MODEL.md.
UI and presentation: partial. The menu structure, the 2D-backdrop-plus-3D-character model, and
the game's own in-engine documentation of its movement rules. See
SPEC/UI-AND-PRESENTATION.md.
Dialogue: solid. How a line is identified, how rows group into conversation records that
double as the save file's progression threads, which records a talk can reach, what happens when
one runs out, and how a line's voice clip is named — with each of those checked against the shipped
data rather than only read. See SPEC/DIALOGUE.md and
DATA/dialogue_rows.tsv.
Rendering: partial, and the engine side is read. A 2D painted backdrop per scene with Granny
1.2b characters composited over it, fixed camera, 640×480, RGB565. All 33 Granny entry points
enumerated and grouped. OMT.dll was disassembled, so the 2D sort key, both rasteriser paths and
the per-polygon lighting model are specified — see SPEC/OMT-ENGINE.md and
SPEC/RENDERING.md.
Audio: probable. How a clip is named and found, the two banks, the mixer's channel array and its
bounds-checked play, how a wait knows a clip has finished — and the fact that each channel has
a fixed job: 3 music, 4 dialogue voice, 5 cutscene scripts, 8 character movement, 9 per-character
scripts, so the categories cannot cut each other off.
Minigames: solid for the slot machine, the maze and the phone; partial for darts, whose
aiming model is specified and whose scoring is not. All four share one 92-byte manager, and the
slot machine and the maze turn out to be one puzzle — the winning reels are the maze
combination. See SPEC/MINIGAMES.md.
Not started: nothing, as a category. What remains is listed page by page in
SPEC/IMPLEMENTATION-GAP.md.
How this was established
Two independent instruments, which is why the numbers can be trusted:
- Runtime capture. Forwarding-DLL proxies around
granny.dllandOMT.dll— 1,728 forwarders, plus constructor hooks, vtable patching, a 25 Hz object sampler and x86 hardware data-write breakpoints. This measures what the game does. - Static analysis. The shipped binaries, their export and import tables, and a disassembler. This establishes what the game is.
Where the two disagree, that disagreement is recorded rather than smoothed over — see
PROCESS/WRONG-TURNS.md, which exists because several confident
conclusions in this project turned out to be wrong and the reasons were instructive.
Credits
The .omt container work builds directly on awefan's Open Media Toolkit asset parser. See
CONTRIBUTING.md.
Employee of the Month is © THQ / Nickelodeon. This specification is an independent work of interoperability research and ships none of the game's content.