How I Architected Three Games in One Session Without Writing a Line of Code

Constitutional documents, system contracts, and the discipline of leaving questions open.

I spent a single working session building the complete architectural foundation for a multi-game ecosystem. Three games. Four system contracts. A shared mechanics layer. A PR merge gate. A design decision brief. An asset licensing contract. An ID@Xbox concept submission draft. A portfolio architecture that turns unemployment into documented production experience.

Zero lines of game code were written.

Every decision is traceable to a document. Every open question is visible and labeled. Every contract specifies what it governs and what it deliberately does not resolve. A new contributor can read four files and understand the entire system.

This post walks through how that happened and why the documents matter more than the code at this stage.

Section 1: Start with one sentence

The entire Money Game architecture is governed by a single sentence:

"Money Game simulates the movement of power, not the movement of prices."

That sentence is the architectural invariant. Everything downstream, the six ledgers, the event tiers, the cascade engine, the dual-audience rendering, is an implementation of that sentence. All of those subsystems can be rebuilt, extended, or replaced. The invariant cannot.

Why does this matter? Because game projects don't usually die from bad code. They die from architectural drift: the slow, invisible process where individual contributors make reasonable local decisions that collectively transform the system into something nobody designed. An invariant gives every contributor a single test to apply before merging anything: does this help a player decide where to commit influence before the world changes? If yes, ship it. Does it help a player perform equity research? Wrong product.

The invariant document also includes a named list of anti-patterns, things that use the right vocabulary while violating the principle. "Innovation Tokens as tradable assets" sounds like it belongs in a six-ledger power simulation. It doesn't. It transforms Influence → Coalition Formation → Power into Financial Assets → Optimization → Return. Naming the failure modes explicitly is more useful than describing the success state, because drift happens through plausible-sounding proposals.

Section 2: Three games, one mechanics layer

The ecosystem has three games that share nothing except a common set of abstract primitives:

- Money Game: a chess-based socioeconomic strategy game where real-world financial events drive world-state through six interconnected ledgers (Capital, Information, Reputation, Innovation, Governance, Labor). Players move influence, not assets.

- Veiled Dominion: a 4-player chess variant on a 14×14 board where the most powerful piece's aura disables everything near it, including your own pieces. You win through restraint, not conquest.

- The Weaver: a card-based dueling system where two incompatible decks (one built on hidden information and ritual, the other on open information and socio-economic mechanics) learn to coexist.

Each game has its own invariant, its own vocabulary, and its own unresolved design questions. The shared mechanics layer sits below all three and provides only generic primitives: State, Actors, Actions, State Transitions, Event Chains, Cascades. It does not import any game's specific rules.

The architectural test: can you instantiate any game against the shared primitives without silently importing another game's rules? The Weaver instantiation (PR #52) proved this works. A card-based dueling system maps onto the same primitives as a board-based power simulation because the primitives are abstract enough. If the shared layer had been designed around Money Game's six ledgers, the Weaver mapping would have required forcing. It didn't.

Section 3: Contracts, not specs

The Money Game architecture produced four system contracts:

1. FACTIONS.md — the canonical actor model (seven fields, each specifying data, mutability, read/write rights, valid values, and open design decisions)

2. EVENT_TRANSLATION_ENGINE.md — the seven-stage pipeline from raw financial data to game-state change

3. CASCADE_ENGINE.md — the reaction/counterreaction system that turns events into gameplay

4. PULL_REQUEST_TEMPLATE.md — the merge gate that enforces the invariant

These are contracts, not specifications. A spec tells you what to build. A contract tells you what rules your build must satisfy, what systems can read and modify each field, and where the architecture deliberately leaves decisions open.

The contracts surfaced 38 OPEN DESIGN DECISIONS across the three documents. Ledger value ranges. Faction lifecycle. Magnitude calculation. Cascade depth. AI faction behavior. Conflict resolution mechanisms. Each one is labeled, located in the document where it matters, and explicitly not resolved. They're visible so that no contributor silently assumes an answer.

The build order matters: FACTIONS.md first (because the cascade engine needs actors), EVENT_TRANSLATION_ENGINE.md second (because the cascade engine needs events), CASCADE_ENGINE.md third (because it depends on both), PR template last (because it enforces all three). Each contract declares itself subordinate to the architectural invariant.

Section 4: The discovery that changed the architecture

Midway through the session, a reconciliation emerged that reframed the entire ecosystem. The Weaver page (duet.loptrlab.com/weaver) says explicitly: "The Weaver is the human and creative layer that asks what it means for those systems to coexist."

That sentence revealed that Money Game and the Weaver aren't parallel games that happen to share mechanics. They're sequential layers of the same question:

| Layer | Function |

|---|---|

| Money Game | What things cost |

| The Ledger | Records the costs and consequences |

| The Weaver | Who gets to define value when two systems meet |

| Duet | Makes that encounter playable |

| 52 Cards of War | Turns the encounter into a larger system |

Money Game supplies the pressure. The Weaver supplies the relationship. Duet supplies the encounter. The larger game supplies the world in which consequences propagate.

This distinction protects the architecture from collapsing everything into economics. The Weaver's nine questions (fair collaboration, unequal contributions, ownership vs. authorship, jurisdictions, relationship change, legacy, independence inside collaboration) are value-allocation problems where the currency includes authorship, labor, identity, jurisdiction, legacy, access, attention, and control. That maps onto Money Game's six ledgers without being identical to them. The Weaver humanizes the ledger categories.

Section 5: What "stable" actually means

By the end of the session, the ecosystem was in a state where nothing is invented, nothing is prematurely resolved, and nothing is merged that shouldn't be:

- Shared mechanics layer: merged

- Weaver instantiation: draft PR, waiting on two open design questions

- Weaver design decision brief: draft PR, alternatives and consequences documented, no winner chosen

- Paragon asset integration contract: draft PR, licensing verified against current Fab terms

- Money Game contracts: complete documents, repo installation separate

- ID@Xbox concept draft: ready for portal entry

- Ecosystem architecture map: documented in-repo

Every draft PR is deliberately draft. Every open question is labeled OPEN. Every contract declares its authority and what it does not govern. The chat is no longer the source of truth for any of this.

That's what "stable" means at this stage: not finished, but traceable. Any contributor can enter the system, read the invariant, follow the contract chain, see every open question, and know exactly what has been decided and what hasn't.

Section 6: The portfolio reframe

The final move was recognizing that the repositories aren't a pile of personal projects. They're a documented work-experience program. Every project follows the same evidence cycle: plan → build → test → review → ship → document → portfolio receipt.

Two lead projects have real platform finish lines (Xbox for Duet, Fortnite/UEFN for Ren Rhapsody). Every other repo demonstrates a specific employable skill through the same evidence discipline: QA, accessibility engineering, game systems, AI integration, narrative design, rhythm content production, identity systems, developer training.

The shift: "I was unemployed and worked on personal projects" becomes "I ran an independent production program with verifiable evidence at every stage." The repos prove the work as it happens rather than requiring a retrospective resume.

Closing

No kicker. The architecture exists. The documents say what they say. The open questions are visible. The next person who touches any of these repos knows exactly where they are.