AI agents built OneGame, a C# game engine that can be developed and tested from a terminal, using playable games to check whether its parts work together. At v1.18.0, it ships 31 stable packages and a separate physics preview. Its saved automated checks show matching final game states on Linux and Windows for 15 Solitaire scenarios, 8 Lanterns scenarios, an animated-character example and an exported game.
This case study follows the build from October 24 through the v1.18.0 release on November 9, 2026. It covers that released version, not unfinished development after it. Matching state means the tested game logic agreed; it does not mean the pictures were identical or every supported device was tested.
Findings
| Evidence at v1.18.0 | Result | What it establishes |
|---|---|---|
| Released packages | 31 at 1.18.0; Physics at 1.18.0-preview.1 | The stable engine and optional physics preview are released separately. |
| Sample games in the tagged source | 3 | Solitaire, Bricks and Lanterns exercise different parts of the engine. |
| Game-state comparisons | 15 Solitaire; 8 Lanterns; 1 character scenario matched | The tested runs ended in the same state on Linux and Windows. |
| Exported game | Same final state | The tested Linux and Windows standalone builds agreed. |
The automated checks for the release commit passed. Running the tagged comparison script over their saved outputs reproduced the results above. The release workflow also passed, and the public release includes the packages.
The problem: an engine agents can operate
OneGame lets a developer make a game from C# and text assets without an editor. A command line and a live-control interface let agents build a game, run it, inspect its state, capture it and replay scripted actions. Clients and servers use the same game-logic code.
A game object keeps its synchronized state, commands, game logic and drawing code in a C# class. Generated code handles state updates between machines. Compiler checks prevent drawing code from changing synchronized state directly. Fixed-point numbers and repeatable random streams help the same inputs produce the same game state.
Each part of a networked world has an authoritative copy. Other machines subscribe to the parts they need. The engine supports predicting changes on a client, moving authority between servers and coordinating trades. A custom design is not a claim of invention. The source establishes an implemented programming model, not a research first or superiority to another engine.
How the work was organized
An agent project manager commissioned a coordinating agent, which divided implementation among engineering agents. The public source contains written agreements between engine parts, including the game-object model, synchronization, platform services and rendering.
According to the agents, work progressed from a local game to networking, rendering and platform exports. The public evidence is more concrete: source code, sample games, test definitions and saved automated results show which parts were implemented and checked.
Split work at boundaries that can be tested. Written interfaces and runnable games made integration visible. This study did not compare parallel agents with a single agent and makes no productivity claim about that choice.
What the human did
According to the agents, Kurtis Welch set the main product constraints: no editor, shared game logic for clients and servers, and keeping an object’s game logic and drawing code together by default. Agents proposed the details and implemented the engine within those constraints. This division of responsibility is described by the agents.
The evidence supports an agent-built engine under human direction, not a wholly agent-invented one. This report does not estimate Kurtis’s working time or count his messages.
Games as the fitness test
| Public sample | What it exercises | Release evidence |
|---|---|---|
| Solitaire | Menus, buttons, scripted input, undo and save/continue | 15 final-state comparisons matched across Linux and Windows. |
| Bricks | A real-time brick-breaker with text-file levels, power-ups and saved high scores | The tagged source includes automated tests for the game’s rules. |
| Lanterns | Networked islands, moving between servers and trading | 8 final-state comparisons matched across Linux and Windows. |
The animated-character example adds a state comparison for movement taken from an animation. The exported-game comparison checks a standalone program rather than only code running inside the engine checkout. These checks answer specific questions about repeatable game logic; they are not a test of multiplayer at production scale.
Name what each game checks. A passing sample is evidence for the paths it exercises, not proof that every proposed game will work. The tagged source also includes small feature examples for input, particles, saving, navigation and physics.
Verification: independent references and mechanical checks
Khronos references
The rendering tests compare engine output with reference images described by their authors as captures from the Khronos glTF Sample Viewer, a separate renderer. A committed script captures that viewer with specified camera and lighting settings, and the tests allow numerical differences rather than requiring identical pixels.
The limitation in the earlier release remains: a reference test returns early when its model, lighting file or image is missing. A successful overall test run therefore does not establish that every image comparison ran. This audit does not claim a verified count of those comparisons or Khronos certification.
Vulkan validation
The Linux automated checks install a software Vulkan driver and a validation layer that checks graphics calls for errors. Windows also uses a software driver; its setup permits running without the validation layer if the layer is unavailable. These checks help find graphics-API mistakes. They do not establish behavior on every graphics card.
Cross-platform hashes and native exports
The release checks compare fingerprints of the final game state. The retained Linux and Windows outputs agree for the Solitaire and Lanterns scenarios, the character example and the exported game. This audit reran the comparison script, not the engine itself.
Package-based jobs also passed for Windows, Linux, web, Android, iOS and a dedicated server. The workflow and scripts show their different scopes: Android builds exports, while the web and iOS Simulator checks also run games and compare their state with desktop runs. These are not interchangeable with playing on physical devices.
Match the claim to the check. Equal state fingerprints support agreement in game logic for those runs, not identical rendering, equal performance or complete input-device coverage.
Models used
The agents used Claude Opus 5.5, Claude Sonnet 5.5 and GPT-6.1 Sol for the completed engine work covered here. Work still underway at release and separate game and shared-library teams are outside this model list.
What went wrong, and what the release did not settle
Recent release notes record concrete integration fixes. A Wayland window waiting on its display system could block game logic and networking; a fix keeps them running when the window is covered or minimized. Screens with more images than the shared texture pages could hold showed magenta boxes; overflow images now get separate textures within the existing memory limit. At v1.18.0, damaged save slots are treated as missing rather than offered as usable saves.
A new game can now be created, run, tested and exported using published packages without an engine checkout. The release also adds commands for other subscribed parts of a networked world, state comparisons specific to each client’s view, views rendered inside other views, runtime material changes and frame-timing tools. Those are documented features, not measured performance gains.
Physics remains optional and is explicitly a preview. Its documentation warns that the API may change, and the release history records a change that invalidates older physics saves and replays. Successful release checks do not establish production-scale multiplayer, complete device coverage or compatibility of preview data across versions.
Results and recommendations
The result is a publicly released engine with package-based setup, sample games and inspectable checks. Agents implemented it under human architectural direction. The evidence supports those delivered capabilities and the specific state-agreement results, not a claim that the engine is independently certified or proven for every game and device.
For another build, keep written interfaces, runnable samples, saved outputs and explicit release conditions. Make missing reference files visible rather than allowing them to disappear into a passing summary. Keep physical-device checks separate from software-driver checks. These are recommendations from the audit, not measured productivity gains.
Sources
Public release and packages · Release history · Setup and samples · Interface agreements · Reference tests · Viewer capture script · Automated checks and saved outputs.