Engine Capabilities
Everything below is project data — no engine code, no forks. The faithful Kanto build holds every one of these at its Gen-1 value, byte-for-byte.
Projects can declare per-individual fields (mon_fields) — a grade, a variant tag, a mark — and produce them three ways: authored on any individual-producing surface (gifts, scripted encounters, encounter-group entries, trainer party members), written by story scripts (set_mon_ext/get_mon_ext — appraisal, fusion, grading economies), or rolled at birth by an on_mon_created kernel from a dedicated deterministic stream (Per-Individual Fields walks all three). Battle, types, catching, and progression sit behind a ruleset interface; the built-in gen1 module is asm-faithful. A project can turn documented knobs (stat-stage tables, badge boosts) or bind any of ten formula kernels — damage, crits, accuracy, catch, experience curves — to a HatchScript replacement. Bramblewick's catch and experience math are scripts; re-expressing all ten Gen-1 kernels as scripts reproduces the reference battles byte-identically, which is the regression gate. Bound stat kernels are verifiable in-engine: --statread=<fixture.json> prints a pinned individual's per-stat base / prescale / final through the real pipeline, so your own oracle's vectors become acceptance fixtures (Modern Individuals has the walkthrough). Kernels, sim config, and the stat vocabulary can also be bundled as named rulesets a save binds in-story — exactly once, before its first owned individual — so a faithful mode and a modern mode coexist in one project, and link peers on different modes refuse at the handshake instead of desyncing (Per-Save Rulesets).
The entire overworld story layer is event records interpreted by a VM — triggers, branches, gifts, battles, choreography. In the faithful project, every gym, guard, and story beat is authored data; your game uses the same grammar.
HatchScript can't touch the filesystem, network, or engine internals — the grammar has no words for them. Runaway loops hit a step budget; failures report line/column and fall back loudly.
Declare new record families (Bramblewick adds a charm type) and custom fields with real editor controls. Per-individual extension fields ride the trade/battle wire format and join the link-identity handshake, so modified games can't silently desync against each other.
A project can select its logical frame — here Meadowbrook at the canonical 16:9 (256×144) next to the classic 160×144:
The engine's own menu words are knobs: the samples say MONSTER and MONDEX where Kanto says its own names:
The distributable engine carries a complete set of original default textures — fonts, frames, battle HUD, title art — so a fresh project looks coherent before you've drawn anything, and the shipped binary contains zero extracted material:
Cable-Club-style trades and lockstep link battles between two copies of a game, with a content-hash handshake that refuses mismatched projects instead of desyncing, disconnect grace, and session resume.
Anyone can run a thin lobby server for their game — a headless mode of the same engine binary that checks the content-hash gate at the door, authenticates handles, and introduces matches; sessions stay peer-to-peer (with a content-blind relay fallback), so battles and trades remain lockstep between the players. Run one · Join one.
Battles emit deterministic event streams (replays hash byte-identically across Windows/Linux/macOS). Your game inherits that: reproducible battles, meaningful replays, and automated end-to-end bots as release gates — both samples are beaten start-to-finish by bots in CI fashion.