Black Magic Dev Journal
EP 1·July 2026·Written before the code·5 min read

Space Chess

♚The Thesis

Chess has endured for 1,500 years. StarCraft: Brood War is still played professionally 28 years after release. Same reason: each is an inherently fair test of skill between opponents.

Most of what we call video games are really simulators with game elements sprinkled in. Nothing on the other side of the screen is actively trying to thwart you. A game in the purest sense is defined pieces, defined moves, one win condition, and another player following the same rulebook, seeking checkmate. That is why I call StarCraft Space Chess. Nothing has replaced it, and the genre has drifted toward hero units, roguelike layers, and monetization loops.

Black Magic is my bet that the original formula still has an audience: a modern RTS with the fairness of chess and the complexity of StarCraft 2, still satisfying ten years after release because of its fundamental architecture.

For the record: I have been playing RTS games since Command and Conquer, and SC2 since the week Wings of Liberty launched. I am a Diamond 4v4 Random player who grew up on LAN games with five-minute no-rush house rules. I say that to be clear about what this game is not.

It is not built for my comfort. It is built for the purist.

♛The Other Game

There is a second experiment running inside the first. I am a product owner, not a programmer, and Black Magic is being built by an AI staff with me steering. Ten years of product work taught me to ration engineering hours. That constraint just evaporated: implementation is nearly free now, and the scarce resource is my attention. Every planning habit built around the old constraint is up for review.

This journal documents both games: the RTS, and the way it gets built. What a one-person product org with an AI staff actually looks like, decision by decision, with the receipts public in the repo.

♞Three Decisions Before Any Code

The tempting first answer was a web game, because this journal could then embed playable prototypes in every episode. But the vision is a true native successor with real 3D production values, and the journal's job is to document the project, not bend it.

Then the engine. Rust plus Bevy is the most AI-native workflow there is, all code and no editor, and it still lost for a human reason: I will be steering and approving code I did not write, and I cannot review Rust I cannot read. Unity 6 won on the two inputs that mattered, C# being the most readable serious language on the list and a mature 3D pipeline one person can actually leverage. A custom C++ engine was scope suicide and died fast.

DECISION 1 · WHERE DOES IT RUN? ✗ Web game · TS + WebGL embeddable demos, but not the vision ✓ Native build a true successor, 3D production values DECISION 2 · WHICH ENGINE? ✗ Rust + Bevy can't review what I can't read ✗ Custom C++ years of plumbing first ✓ Unity 6 + C# readable, mature 3D pipeline DECISION 3 · WHERE DOES THE GAME LIVE? ✓ A pure C# simulation, rendered by Unity deterministic lockstep · fixed-point math · replays are command logs · runs headless M0: prove determinism, or change course while it's cheap
Three forks, one path. The full decision records live in the repo: decisions/0001 through 0004.

♜The Architecture That Fell Out

What made StarCraft 2 work on 2008 internet connections still holds today: a deterministic lockstep simulation. Only player commands travel the wire. Every client computes the identical game, and a replay is nothing but the command log.

So the simulation is a pure C# library with zero Unity dependencies: fixed-point math, a tick loop fed by a command queue, state that can be hashed. Unity renders what the sim says and converts clicks into commands. It never reaches inside. The payoff goes beyond multiplayer: the AI staff can run the sim headless, simulate thousands of battles, and verify its own work without ever opening an editor. The workflow advantage that made Bevy tempting got rebuilt inside a Unity project.

the one-way boundary Simulation · sim/ pure C#, zero Unity references Fix64 fixed-point math, no floats ever tick loop fed by a command queue SHA-256 hash of full state, every tick runs headless: dotnet test, no editor Unity 6 · game/ captures input renders snapshots interpolates ticks never writes state commands state snapshots a replay is the command log played back · a multiplayer game is the command log shared live
game/ depends on sim/. sim/ never knows Unity exists. The dependency arrow points one way, enforced by project structure.

♝The Rules

No off-the-shelf methodology fits a team of one human and an AI staff, because they all assume the scarce resource is developer hours. Here it is my attention. The methodology is assembled from four borrowed parts, each chosen because it rations attention or kills risk:

  • Vertical slices. Every milestone cuts sim to screen and ends in a showable artifact. No "80% done" layers.
  • Appetites, not estimates. Each milestone gets a time budget. Blowing it means cutting scope, not extending, and the cuts get journaled.
  • Risk first. The unknowns that could kill the project die first, cheaply.
  • A WIP limit on me, not the code. The staff generates work faster than I can review it. My queue is capped at three items; when it is full, the staff works the backlog instead of my inbox.

And one engineering rule held sacred: acceptance tests before implementation on all simulation work. I approve the contract, the staff verifies against it, and my review shifts from reading every line to approving behavior.

♟Next

First milestone: M0, Foundations. One question: can C# produce a bit-identical simulation across machines and runtimes? If not, the architecture is wrong, and I want to find out for a week of evenings, not a year. Episode 2 has the answer.