SYSCALL: RING ZERO is out!
SYSCALL: RING ZERO is out now on Steam for Windows and macOS.
This is a game about reading small programs carefully. You dial into a private 1990s BBS, open a job from the network map, inspect the code in front of you, and work out what will make it accept. Sometimes that means recovering an input. Sometimes it means replacing a broken instruction, routing values through a rack of tiny processors, or writing firmware until a waveform matches the trace on an oscilloscope.
The full game has more than 200 authored puzzles across four modes: CRACK, PATCH, WORM, and SCOPE. It is fully offline. There are no accounts or servers. The programs and machines are part of the game, and the same code shown on screen is used when the player presses VERIFY.
CRACK starts with a small listing and a visible acceptance condition. The highlighted line is not decoration. It is part of the program that runs.
What the game became
The first version of the project was much narrower. It started as a Windows reverse-engineering puzzle built around reading disassembly and finding the check. That basic loop was already the part I cared about: inspect a short routine, form a theory, enter an answer, and see the actual routine decide whether it is correct.
The presentation around that loop grew into a private board. The BBS was useful because it gave every system a natural place. Puzzles became posted releases and tickets. Reference material became PHILES. Progress appeared as access levels, records, and new nodes on the map. Mail could introduce mechanics and carry a small story without stopping the player for long scenes.
The game also moved away from depending on a real processor instruction set. I built the SYSCALL CORE instead: a compact fantasy CPU with eight byte-sized registers, a small readable instruction set, and a clear contract. The registers are r0 through r7, writes wrap at 255, and r0 carries the final verdict. That let me design listings for puzzle readability rather than for the accidents of one real architecture.
From there, the project expanded in layers. PATCH turned the same listings into constrained code surgery. WORM added a 3 by 3 rack of processors and message-passing programs. SCOPE reused the CPU for timing-sensitive firmware and signal matching. The network map eventually became the single front door for all of them, rather than presenting four unrelated game modes on a menu.
A Windows demo was ready by June 19. The full Steam release followed on July 3, 2026. I kept working on the SCOPE bench and controller navigation after release, particularly the waveform layout, cursor inspection, and gamepad camera controls. The current game is the result of that short, concentrated sequence of changes rather than a large framework designed before the puzzles existed.
The board is the hub. The network map contains every puzzle mode, while notes, tools, mail, setup, and progress stay part of the same machine.
Four different ways to solve a machine
CRACK is the on-ramp. Each release contains a small SYSCALL CORE program. The player reads the listing, traces constants and branches, then enters the value that satisfies its final check. Early releases teach direct comparisons and simple arithmetic. Later ones move into checksums, rotations, serial formats, table walks, state, and small key generators.
PATCH uses the same general language but changes the question. The input is not the problem. The routine is broken or trapped, and only marked slots may be changed. A solution has to pass the test battery, then the DROP BOARD records how many moves it took. It is deliberately constrained because the interesting part is deciding which operation changes the control flow with the smallest edit.
PATCH keeps the listing visible, limits where edits can be made, and scores the size of the repair.
WORM is a different kind of programming puzzle. Nine line cores sit in a 3 by 3 rack. Each has an accumulator, a backup register, a LAST port, and a program of no more than ten lines. Values enter through input rails, move between neighboring cores, and leave through output rails. A correct solution is only the beginning. The records screen keeps the pressure on lines, active cores, and cycle count.
WORM exposes the machine while it runs. A blocked transfer is visible as a WAIT state, and every live core advances under the same cycle model.
SCOPE asks for firmware rather than an answer. The program drives an 8-bit DAC, and slp advances scope time. The target is the dim green ghost trace. A solution locks only when the live output matches that visible reference at every tick. The mode begins with simple levels and ramps, then builds toward counters, timing patterns, and shaped signals.
SCOPE runs the player's firmware and the reference firmware through the same simulator, then compares the visible trace tick by tick.
The listing really runs
The most important technical rule in SYSCALL is that the code on the screen must be the code that gets judged.
A CRACK challenge is stored as metadata plus a SYSCALL CORE assembly file. When the game loads the challenge, it parses that assembly into a cpu_program. The disassembly panel reads from that program. When the player presses VERIFY, App::VerifyInput() passes the typed bytes and the loaded program to cpu_check().
cpu_check() resets a cpu_machine, copies in the player input, and runs instructions until the program returns, reaches its end, faults, or crosses the cycle ceiling. The final acceptance rule is applied to r0, but only a clean return or end may pass. An infinite loop or bad instruction cannot accidentally succeed because it happened to leave a nonzero byte in the verdict register.
TRACE uses the same cpu_step() function one instruction at a time while recording snapshots of the program counter, registers, and flags. It is not a second explanatory model layered over the answer. The stepping view and the final verifier share the same machine.
That shared execution path made the teaching side of the game much easier to trust. A note can explain a compare or jump, the player can inspect it in TRACE, and VERIFY reaches the verdict by executing those exact operations.
Making WORM deterministic
WORM has a different problem. If nine processors are simulated one after another, the order of the loop can change the result. Core 0 might write a value before core 1 gets its turn, while a reversed iteration order could make core 1 wait for another cycle. That would make the rack depend on an implementation detail rather than on the programs the player wrote.
The WORM simulator therefore splits each cycle into two phases.
First, every live core computes an intent from its current state. Reads, writes, arithmetic, jumps, and port choices are resolved without mutating the machine. Port-to-port moves can block until both neighboring instructions agree on a transfer. ANY and LAST have stable polling rules so that ambiguous choices still produce the same result every time.
After the handshakes are resolved, the commit phase applies all completed instructions together. Input positions advance, output values are written, accumulators change, program counters move, and blocked cores retain a reason that the interface can show as a WAIT badge.
This is what allows the visual rack, the single-step controls, the record calculation, and the headless content verifier to agree. A ticket is judged against the same cycle model whether it is being watched in the game or checked during the build.
SCOPE compares what the player can see
SCOPE shares the SYSCALL CORE CPU, but it adds a clocked environment around it. The simulator runs instructions until the firmware yields with slp or wait, applies pending pin changes, advances the scope tick, and samples the channels.
For verification, the player's program and the board's reference firmware are run through the same scope_run() path. The judge compares every visible channel at every visible tick. If the traces differ, it records the first channel, tick, expected value, and actual value. If the reference itself stalls, the board is treated as broken instead of blaming the player.
I made the visible waveform the complete contract. A board does not fail on a hidden test case that the player could never inspect. If the live trace matches the ghost across the displayed window, the line locks.
That rule sounds small, but it affected the whole mode. The renderer, probe cursor, error messages, authoring checks, and scoring all had to describe the same time domain.
Shipping the content as one unit
The project has hundreds of small text assets: challenge metadata, assembly listings, WORM solutions, SCOPE boards, and reference firmware. Loose files are convenient during development, but they are fragile in a retail package.
The release build collects them into challenges.pak. It is a compact little-endian archive with a CPAK header and a table of bare filenames and byte payloads. Windows embeds that pack as a resource in the executable. The Apple builds place the same pack in the application resources. The runtime loads it through a small platform resource interface and indexes it in memory.
CRACK, PATCH, WORM, and SCOPE all ask the same content layer for files. Development builds can fall back to the source tree, but the shipped game does not depend on a working directory full of puzzle folders. A smoke test also checks the expected counts by extension and looks for representative files before packaging.
Keeping the BBS readable on different screens
The game draws into a fixed 16:9 virtual canvas. On Windows, the active renderer uses Direct2D over a Direct3D device. The whole scene is rendered to an offscreen bitmap first. A uniform scale then fits that canvas to the actual window without stretching it. A 16:10 Steam Deck display gets letterboxing rather than distorted text and panels.
The second pass applies the CRT chain: curve, chromatic separation, glow, scanlines, brightness, and the final composite. Reduced motion and CRT settings can remove the more aggressive movement and distortion. Static decorative layers are cached, and the heavier demoscene backdrop freezes after an idle interval so it does not keep spending GPU time while nothing is changing.
The macOS version keeps most of the game drawing code intact through a compatibility layer that maps the Direct2D-shaped interface onto Core Graphics and Metal resources. Input follows the same split. Windows uses XInput, while the Apple shell supplies the platform controller events. The game logic and puzzle simulators remain portable C.
This separation also made the screenshot and trailer pipeline practical. The renderer can run headless, draw the normal scene into its offscreen target, and save that target without opening a window. The store screenshots in this post came from the same game rendering path.
It is out
SYSCALL: RING ZERO launched on Steam on July 3, 2026. It includes more than 200 authored puzzles across CRACK, PATCH, WORM, and SCOPE, along with the BBS, PHILES, mail, records, achievements, controller support, CANVAS, and the four-channel TRACKER.
The game is available here:
I wanted to make a puzzle game where reading the machine is the game. The listing, trace, rack, and waveform are not set dressing around a hidden answer. They are the systems that decide it.