Idle Guilds — A server-authoritative MMO with AI-assisted development

Idle Guilds looks simple at the surface: choose an activity, leave the game, and return to progress. The difficult part is that every action also changes shared state.

Players can log out, reconnect from another device, trade with one another, and develop a character over time. The browser cannot be trusted to own progress, inventory, or currency. Those decisions belong on the server.

Why the server owns the outcome

Offline progression and a player market turn routine interface actions into distributed-systems problems. A reconnect may replay a request. Two sessions may act at once. A retried market delivery must not create or lose value.

The design follows one rule:

The client submits intent. The server decides the outcome.

Browser and desktop clients render the current view of the world and send narrow commands over a WebSocket connection. The authoritative service validates each command, advances the simulation, and commits the resulting state to PostgreSQL.

Correctness before throughput

The core progression model is an integer-only deterministic reducer. Given the same previous state and ordered commands, it produces the same next state. Keeping the reducer separate from networking and persistence makes behaviour replayable and easier to debug.

I verify it with golden-master scenarios, invariant-focused tests, and deterministic random streams. The market and currency paths use idempotent, balanced ledger entries, so retrying a request cannot quietly duplicate an economic outcome.

No connected game can be perfectly secure. The design stance is deliberately narrower:

Designed security-first, with server authority, deterministic replay, ledger invariants, and adversarial regression testing.

Finding the actual bottleneck

I started the scaling work with representative workloads instead of redesigning from instinct. Measurement showed that simulation scheduling was the meaningful CPU constraint. I changed how the work was scheduled, then checked the result against the same reconciliation and correctness properties as before.

I have left capacity numbers and infrastructure topology out of this public case study. They are environment-dependent and would say less than the method: measure, isolate the constraint, change one boundary, and confirm that the system still reconciles.

Operations affect gameplay

Readiness checks, graceful draining, observability, backups, and rollback practice are part of the player experience. When progression continues over time, recovery must preserve the same invariants as normal operation.

How I use coding agents

The repository and working agreements let coding agents take on narrow tasks without quietly expanding the scope or approving their own work. The workflow uses:

1. A written specification with explicit invariants and affected boundaries.
2. Risk-tiered implementation, with small, clearly owned tasks delegated to coding agents.
3. Independent review instead of self-approval by the implementing agent.
4. Adversarial and regression checks around state, protocol, and economy changes.
5. Human ownership of product trade-offs and release decisions.

AI assistance has increased how much of the system I can explore as a solo builder. More importantly, it has forced me to make intent, boundaries, and verification easier to understand. Those changes also make human review better.

What is live today

Idle Guilds is running as a closed alpha with 16 skills, combat, trading, character progression, and supporting progression systems. I am using the alpha to improve the product, exercise the system under realistic use, and keep public claims proportional to what has actually been observed.

The same practices help people and coding agents work safely in this codebase: explicit contracts, deterministic behaviour, independent review, and feedback that exposes mistakes early.