Metaverse: Origins, sandbox survival built granular by design.
An open-world sandbox survival game in pre-alpha early access on Steam since May 2021, published under the Penumbra.tech studio name. Voxel terrain you can dig and build, a medical and metabolism simulation, AI companions on skill trees, save/load that has to survive years of schema changes — a studio-sized codebase being run on indie headcount. The interesting story isn't the game; it's the pipeline I built around it to make that possible.
It says pre-alpha for a reason.
Metaverse: Origins is on Steam, but it's on Steam in early access pre-alpha. Functionality is limited, systems are partial, and the bigger pieces of the design — the multi-character AI skill trees, the cooperative civilisation loop, the multiplayer hosting — are in active development, not finished features.
That's exactly the right way to read it for the portfolio: this isn't a shippable retail title; it's a long-arc Steam project where the store presence, the public roadmap, and the customer relationship have been live since 2021. If you want to know what it looks like when I ship a game-shaped commercial product through Steam, this is the longer of the two examples on this site (Trigonometry Tools is the shorter one, fully released).
A studio-sized codebase, run on an indie headcount.
Origins is bigger than it looks from the store page. Voxel terrain you can dig and build, a medical and metabolism simulation, AI companions on skill trees, save/load that has to survive years of schema changes — that adds up to more than 150,000 lines across 500-plus files and fifteen interlocking subsystems. The honest problem for a solo developer isn't writing any one feature. It's that the infrastructure a studio takes for granted — a QA team, an automation engineer, a tools team, a release process — doesn't exist when there's one of you.
So I built that part too. Not just the game's features — the apparatus around them. Over the last stretch I've been using Claude Code less as an autocomplete and more as an engineering org I direct: a fleet of agents pointed at the work that normally needs headcount, wrapped in tooling I wrote myself to make their output trustworthy, not merely fast. The game is the visible artefact. The pipeline that builds it is the real one.
What “agents as engineering org” actually looks like.
An agent that drives the live engine.
Most game bugs only exist at runtime — in the editor, with the game actually playing — so verifying a fix usually means a human booting the build and clicking through it. I built a file-driven bridge that lets an agent drive the running engine directly: boot a fresh save in about ten seconds, open and close menus, fire game events, read live state straight out of the simulation's components, and run multi-frame UI test sequences that report pass or fail. No human in the loop, no screenshots. It turns “I think this fixes it” into “here's the green verification run,” at one-person speed. That change-build-boot-verify-commit loop is precisely what a studio hires an automation engineer to own.
A standing audit pipeline.
Every so often I fan a fleet of agents across the entire codebase hunting the bugs that don't announce themselves: memory-safety crashes, use-after-frees, save/load data-loss holes, places where the server trusts a client it shouldn't. The catch with machine-found bugs is false positives — so nothing is trusted on the first pass. Each finding is handed to independent agents whose only job is to try to refute it, and only the survivors get filed, with a severity code and a test plan attached. The last full pass was seventeen agents plus forty adversarial verifications across 500-plus files; it surfaced nine critical and forty-eight high-severity defects. A studio calls that QA plus a security review plus a tools team. Here it's a repeatable afternoon — and every critical it found has since been fixed and verified through the harness above.
The unglamorous tooling underneath.
The same instinct shows up in the boring places. Game data — a couple of hundred items, recipes, skill curves — lives in spreadsheet-shaped tables that are miserable to hand-edit safely, so I built a SQLite-backed utility that queries, transforms, validates and round-trips them with schema migration and drift detection. Project knowledge — engineering standards, architecture decisions, the running list of known defects — lives in a structured memory the agents read every session, so the reasoning behind a decision survives across months and the work stays coherent instead of drifting. None of it is glamorous. All of it is the difference between a project that compounds and one that rots.
Tools make you fast. Judgement is still the job.
It's worth being precise about where the automation stops, because that line is the whole point. The agents don't decide anything. Architecture, scope, the call on whether a reported bug is even real, the gate where nothing gets committed until it builds and verifies — that's mine, and it has to be.
The clearest example from recent work: one audit finding was a key-rebinding bug I could have “fixed” in five minutes, and I deliberately didn't. The only honest way to verify a rebinding change is to exercise the live input system; my test harness can't reach that path; and shipping an unverified change to something that could break all input is exactly the AI-assisted carelessness that earns the skepticism. So it's flagged and deferred to a session where it can be done properly. Anyone can prompt a model into producing code. The discipline worth paying for is knowing which output you're not yet allowed to trust — and building the verification that decides.
Same instincts on your codebase.
If your team is interested in agent-assisted development but wary — for good reason — about the carelessness it can produce, this is the engagement to ask about. The harness, the audit pipeline, the verification discipline all generalise; they aren't game-specific. The Steam page is the canonical source of truth for the game's current state — roadmap, patch notes, reviews — and a useful reference for how long this project has actually been live in public.