The outer VM, Gate proof, and gem pickup are parts of one system. This map shows how they connect. Use the links to find each example and its code in this guide. You do not need the repository.
First, identify which part of the system owns the term. The bot calculates, the host can approve power, and the game records EXP.
The two middle cards operate together. Power can help an action, but the game adds EXP only after the knight picks up a gem. Select a box or engine link to open its chapter.
Use this page to find an explanation
Most terms describe one part of the path from bot to world to EXP.
The vocabulary, in the order the pieces connect
On a phone, each term has a separate card. Read its meaning first. Then read how it connects to the game.
| Term | Meaning in this challenge | Concrete connection |
|---|---|---|
| Source | The bot code a person writes | diver.bot says how to choose a target and move |
| Compiler | The translator that turns source into VM instructions | Turns x + 1 into small steps the VM can run |
| Image | The instruction bytes the VM will run | Loaded into the outer VM's memory |
| Artifact / upload | The entire file sent to the runner | Its wrapper can choose ABYSS before the instruction bytes begin |
| Engine | The selected way to earn extra power | The runner fixes CLASSIC or ABYSS before the match |
| VM | A small software computer for the bot | Reads one instruction at a time from its own memory |
| Guest | The bot running inside that VM | Can calculate and ask the game to act |
| Host | The game code outside the bot's VM | Owns the real knight, enemies, rules, and score |
| Snapshot | A copy of the world at one moment, like a photo | my_x() reads the last copy, which can grow old |
| Tick | One game step, lasting 1/60 second | The VM runs for a while, then the world moves on |
| Slice | The VM's work time within one tick | May fit several main calls or only part of one |
| Operand stack | A pile of temporary numbers; the newest is used first | ADD takes the top two numbers and puts their sum back |
| Call frame | One function call's saved return spot and local values | Lets main call a helper and return to the right place |
| Fixed point | Storing a fractional number as a scaled whole number | Q16.16 stores 3.5 as 229,376 |
| Pilot | The bot's steering rules | Chooses where to aim, move, escape, and collect |
| Wedge / disc | A cone-shaped or circular hit area | Aim and position decide which enemies are inside |
| Sustain meter | CLASSIC's fading record of a chain passing recently | Goes up on passing ticks and down when that behavior stops |
| Chain / family | A named check of one or more VM behaviors / its group | Both the number and spread of active chains affect the bonus limit |
CLASSIC chain ABYSS |
One named CLASSIC stack-behavior check | It is not the separate ABYSS engine |
| Gate | ABYSS's smaller machine and host checks | A GATECALL can request inner work; it cannot directly add EXP |
| Request frame | The 128-byte form the bot gives Gate | Names an operation and where its input and output sit in bot memory |
| Bank | A public Entry challenge number from HELLO |
The Entry bot picks one of 16 matching sets of body bytes |
| Session | The host's saved place for one line of ABYSS work | Keeps owner, track, and progress between Gate calls |
| Scheduler | The host part that decides which inner work may run | Checks the request's owner, object, and work allowance |
| Executor | The part that actually runs approved inner instructions | Changes Gate registers and stacks, then reports what happened |
| Fibre | A host record for work kept between Gate calls | Entry keeps a first-call report; threaded Gate keeps the next cell and work spent |
| Fuel | The number of inner work steps still allowed | A call, a game tick, and a fibre each have a limit |
| Capability / handle | A bot-visible ID for an object the host controls | Host checks its owner, version, kind, and rights before use |
| Slot | A numbered place in the host's object table | Slot 3 can hold an old Scratch page and later a new Dispatch page |
| Generation | The version number of the object in a slot | Slot 3 at version 1 is not slot 3 at version 257 |
| Scratch / Dispatch | A temporary writable page / a page meant to run code | Chasm's stale queue write reaches a new Dispatch page |
| Root | A 12-byte number tied to this ABYSS run | Rift's 32 hidden work costs let the bot recover it |
| Class | One of eight labels for a hidden SYNC cost |
Class 0 costs 72 steps; class 7 costs 240 |
| Lineage | The code's name for one of three ABYSS power tracks | Sword proof does not become gem-collection proof |
| Entry / Rift / Chasm | The first three ABYSS proof steps, in order | Each can support a higher power limit after host checks |
| Module stage | The last ABYSS proof step, called Apex in this guide | Can support 16 only if the audit and other limits pass |
| Certificate | A receipt the host makes when one check passes | Different receipt kinds can raise the allowed power limit |
| Proof node | The host's saved record joining receipts to earlier work | A later proof step must point to the right earlier proof |
| Provenance | The history showing where accepted proof came from | A copied final answer lacks that earlier-work history |
| Counterfactual | A second run with one input deliberately removed | Shows whether the program really used that input |
| Authority | The highest level saved proof can support for a Drive request | A bot cannot grant itself level 16 by writing “16” |
| Drive / latch | A requested power boost / its short active window | The boost can expire while the proof stays saved |
| HEAT | Extra danger that rises with power | More power can also make survival harder |
| Supply | The value of gems the game has created | Some gems may expire or never get collected |
| Ablation | A test that switches off one part of a bot | Shows how much movement, aim, or gem routing helped |
| Median | The fourth-ranked result among seven complete runs | Its score, statistics, and replay come from that same run |
| Keyframe | A full saved replay picture | Lets seeking start near the requested tick |
| Delta | A saved change after a replay keyframe | Rebuilds later pictures without running the bot again |
The chapters follow the same path: source becomes instructions, instructions produce requests, and requests plus engine power affect the shared game world. The knight then collects gems, and the game adds EXP.
The runner selects and records one complete result. ABYSS can add power, but it does not write EXP directly.
Edition and reading method
This guide describes the default branch master at commit d9e324b77db97cb304c3ffe350dc9ee367995458, retrieved on 1 October 2026. Every code excerpt comes from that version. File and line captions identify the source inside this guide.
This guide uses CLASSIC engine and ABYSS engine, while the code calls them ClassicLegacy and DeviceV4. Prose, navigation, diagrams, and charts use the guide names. Code excerpts keep the original names.
The review followed the upload, parser, outer VM, compiler, game engine, ABYSS Gate, grading, ranking, and replay. It also examined example pilots, reference-bot notes, reward tables, and release tests.
For large modules, this guide examines the code sections and calls that affect the behavior it explains. It does not examine every line of every old file, generated output, test, or dashboard component.
The repository provides the score and timing results shown here, while interactive calculations and diagrams explain the behavior. They do not rerun the reference exploits, simulate the full arena, or independently certify the release.
Find the missing connection
| If your question is… | Read this part of the guide | What it connects |
|---|---|---|
| Where does EXP come from? | The scoring loop | Death → drop → movement → collection → bank |
| How does a bot choose an action? | Build the pilot | Snapshot → target score → aim and movement |
| How does readable code become executable? | The compiler | Expression tree → instructions → frames |
| What persists while the world advances? | VM state | Memory, instruction pointer, stack, and execution budget |
| What is one CLASSIC chain worth? | Meters and family coverage | Passed check → meter → bonus factor → limited game effect |
| Why are there so many named chains? | The 41-chain catalog | Machine behavior → family → reward axis |
| What does ABYSS keep between requests? | ABYSS state owners | Session, resource identity, pending work, proof, and latch |
| Where can ABYSS contracts diverge? | ABYSS surface map | Guest bytes → admission → identity → execution → evidence → effect |
| What actually executes inner work? | The Gate | Cells → registers and stacks → continuation → outcome |
| Why does a successful calculation not grant unlimited power? | The two power limits | Different receipt kinds and proof step → allowed level |
| What does a permitted level do in combat? | The reward curves | Three levels → local engine fields → ordinary interactions |
| Why does the apex need a pilot? | The reference bots | Allowed power, movement, aim, gem routes, and tests with a part turned off |
| Which run becomes the result I see? | Ranking and replay | Seven seed runs → selected median → stored replay |
Rebuild the outer loop in five steps
- In the architecture chapter, distinguish a copied observation from the live world.
- In the pilot chapter, follow one target through its distance and priority calculation.
- In the compiler chapter, lower an expression into pushes and arithmetic.
- In the VM chapter, step those instructions and inspect the resulting stack.
- In the world chapter, trace the action through combat and gem collection.
Attach ABYSS without losing that loop
- ABYSS copies a request and owns persistent state.
- ABYSS surface map traces each contract boundary and its failure model.
- The Gate runs only the work the host has allowed, within time and space limits.
- Proof saves accepted checks and limits the allowed power level.
- The economy converts permitted levels into gameplay fields.
- The reference bots combine those fields with the pilot you already understand.
Implementation corrections to keep in mind
Use this table to check common misunderstandings. If a row is not clear, use the chapter link above. That chapter gives an example and code.
| Tempting interpretation | What the current source supports |
|---|---|
| The root README's old apex score is the current release target | Use the current CLASSIC and ABYSS score vectors, frozen at release, and label historical calibration separately |
DeviceV4 means every older Device mechanic is active |
Follow current production dispatch; retained modules are not automatically reachable |
Returning from main ends the simulation tick |
The compiler trampoline calls main repeatedly until the VM budget stops execution |
| Recursive source functions are allowed | The compiler rejects cycles in the call graph |
| Generated code and frame memory are hardware-isolated regions | The VM has one flat guest array; layout is a compiler convention |
| The engine consumes no RNG during live ticks | Live spawn and gem behavior uses the deterministic stream |
| More certificate-shaped records always mean more power | Only different host-accepted kinds count, with valid bindings and earlier proof |
| A module-stage label alone grants level 16 | The number of accepted certificate kinds can set a lower limit |
| Device magnet speed is added to the honest speed | It is a selected device speed in the relevant path |
bonus_dmg is necessarily an additive knight field |
Its historical consumer treats it as replacement-valued; ABYSS combines values before assignment |
| Time and kills break current leaderboard EXP ties | Earlier creation time breaks ties; time and kills are display statistics |
| Every replay is either always public or always private | Owner-only is the default; authenticated leaderboard replay access can be enabled |
| The Stage 7 report is the newest timing directory | The current tree also includes the later v15 closed evidence set |
| The 10–20× modeling-time ratio passed | That requirement was withdrawn as a gate and remains unmeasured |
Code excerpts and visual models
Code excerpts come from the source version named above, and they show syntax color, monospace text, and source line numbers. Diagrams show how parts of the code connect; they are teaching diagrams, not formal models. Flow diagrams show who owns each step and when it occurs. They omit error paths unless a chapter explains them.
The memory widget lets you inspect numbers, and the arithmetic stepper runs one fixed, harmless program. The pilot diagram shows the public diver's regions, while the proof widget shows upper limits with simplified approved ceilings. The economy widget calculates reward curves. It uses an honest cooldown of 34 for comparison.
The charts show recorded scores, including middle scores from tests with blocked pilot inputs. They do not show made-up scores for missing seeds. The map uses the game's arena arrays and marks the knight's start. It shows terrain, but it does not calculate a route or draw every collision shape exactly.
Credits and portable use
The visual theme uses the repository's sword graphic, blue warrior sprite, and fonts. Headings use Pirata One, body text uses Archivo, and code and number labels use Ioskeley Mono.
The repository credits the Tiny Swords art and audio collection, and identifies Archivo and Ioskeley Mono as OFL fonts. This guide includes these files to keep the challenge's appearance. It does not independently audit or change their licenses.
The download contains static HTML, CSS, JavaScript, images, and fonts. Extract the archive and open index.html. Chapter links and interactive examples work without a build step or external JavaScript service. The guide does not load navigation, scripts, fonts, or images from an external site. Code excerpts remain readable offline.
The private website shows the same guide. Its password does not protect files after you download and extract them. You control who receives your extracted copy.