hrxdev

How it’s built

One person, an AI coding assistant, and a lot of machine-checked rules.

Prison Life is written by me together with Claude Code (Anthropic’s coding agent). I decide what the game is and which options we take; the assistant does most of the typing. Because nobody reviews the code but me and a review AI agent, I lean on automation: rules are enforced by automated checks and by the build, not by good intentions.

Delegation

The main Claude Code session plans the work and keeps the task tracker, the written record of design choices and the commits. It does not write code: it hands every change, even a tiny one, to a specialised AI agent. Each one has its own file that fixes its role and its model.

RoleModel tierJob
ArchitectureOpusdata model, tick, threads, pathfinding, decisions
Simulation codeOpussimulation systems, character AI, hot loops
PerformanceOpusprofiling, benchmark regressions
Review (read-only)Opusreviews a diff; cannot edit files
Client and toolsSonnetGodot client, UI, tools
TestsSonnettests from acceptance criteria
Content dataSonnetJSON definitions from a schema
Search, running checksHaikucode search; running checks and summarising failures

Hard work goes to the strongest model, routine work to cheaper ones. If a cheaper AI agent fails the checks twice, the task moves up a tier; if the top tier fails twice, it stops and asks me.

Hooks that say no

Claude Code hooks are scripts that run around the assistant’s actions. Mine enforce three rules:

These protect against mistakes, not against deliberate bypass: a determined shell trick can get around them, and one of the hooks sees a red check in an AI agent but cannot hold it back (the main session’s stop hook still catches it). I would rather say that plainly.

Written decisions and checks

The deterministic core

The simulation lives in a plain .NET library with no Godot references; the Godot client only reads its state and sends commands. The core follows fixed rules: the world changes only through commands, time is integer ticks, randomness comes only from the world’s seeded generators. The same seed and the same command log must give the same world. These rules are checked by the compiler and by tests, not by review alone; see devlog #1 for how.

Simulation core architectureCommands enter a queue. Each tick runs phase 0 (commands, written to the command log), phase 1 (systems in a fixed order) and phase 2 (end of tick). The command log and the world state with its seeded random streams feed the state hash. Commands in player, tests, scenarios Command queue Enqueue is thread-safe Tick T (one thread, integer time) Phase 0: commands serialize, stamp (tick, seq) Validate, write to log, Apply rejected commands are logged too Phase 1: systems run in a fixed order set in code (none registered yet) Phase 2: end of tick structural changes (not used yet) then tick counter + 1 Command log every command, with its result wire bytes + digest replay = seed + log World state seed, tick 4 RNG streams: Commands, Needs, Ai, Events all derived from seed State hash seed, tick, RNG streams, log digest
The simulation core as it exists today. Systems and world data (tiles, floors, characters) are not there yet, so the hash covers only what is drawn.

The design target is up to 1,000 inmates and staff at 20 ticks per second. It is a target: there are no characters yet and nothing has been measured at that scale.