Case file 05 Multiplayer game Alpha

The interesting part is
what we refused to ship. Real places wait behind legal gates.

Shaderon is a real-time multiplayer game: players are agents in a spy world, take on missions alone or in cells, reach checkpoints, solve tasks, collect evidence and build standing. Social deduction sits on top — somebody is not who they claim to be.

It is in alpha and we are publishing it as a case file anyway, because the decisions worth showing were all made before the fun part. A game that sends real people to real places carries obligations that a game does not usually think about at prototype stage.

At a glance
Status
Alpha
Kind
Multiplayer game
Phase
Indoor, synthetic points
Stack
PWA-first
Hosting
Own isolated server
Real world
Behind legal gates
Gates what is open, what is deliberately not
  1. phase 0 indoor, synthetic checkpoints openNo GPS requirement. Prove the loop is worth playing before it has a duty of care.
  2. hosting isolated server doneSeparate from every revenue product. A game with photo uploads and location data does not share a host with the plugins that pay the bills.
  3. branches stagingwhere we actually test ruleStaging is the test system, not a rehearsal of production. It can be redeployed at any time.
  4. branches main onlyproduction ruleExactly one branch may reach production, and nothing reaches it by accident.
  5. real world physical checkpoints blockedBlocked until the legal review is done. This is the gate most likely to be argued away, so it is the one written down hardest.
  6. trademark name clearance pendingOutstanding. Listed here rather than forgotten until launch week.

A staged rollout is only real if the later stages can actually be blocked. These are written down so that enthusiasm cannot quietly reorder them.

Brief Why an alpha is worth publishing § 01

The obvious first version was the one we did not build.

The pitch writes itself: send players to real locations, verify they got there, let them photograph what they found. That is the version that demos well and the version everyone wants to build first.

It is also the version that collects location traces and user-submitted photographs, that sends strangers to physical places on instructions from an application, and that inherits a duty of care the moment it works. Building it first would have meant answering those questions under deadline pressure, after the code existed and the launch date was set.

So phase zero runs indoors with synthetic checkpoints and no GPS requirement. It tests the only thing that actually needs testing this early: whether the loop is worth playing at all.

Ledger What exists § 02

3 environments
1 isolated server
1 branch that may reach production
0 real-world checkpoints yet

Decisions What we chose, and what it cost § 03

Three calls made before the fun part.

Decision 01 · Risk

Synthetic checkpoints before real ones.

Phase zero has no GPS requirement at all. Checkpoints are synthetic and the whole thing runs indoors. If the mission loop is not compelling without real-world novelty, it will not be compelling with it — and finding that out costs nothing at this stage.

Cost: the alpha is less impressive than it could be, and demos worse.
Bought: the legal and safety questions get answered on their own timetable, not against a launch date.

Decision 02 · Isolation

A game is a different risk class. Give it its own server.

Shaderon runs on separate infrastructure from everything that earns money. User-generated photo uploads, location data and an unproven multiplayer surface are simply a different exposure profile than a WordPress plugin with paying subscribers.

Isolation means a compromise or a runaway process in the experiment cannot reach the products that fund it.

Cost: a second server to maintain, patch and pay for.
Bought: the experiment is allowed to be risky, because its blast radius ends at its own host.

Decision 03 · Deployment

Exactly one branch may reach production.

Three trees: a development checkout where commits happen, a staging system that is the real test environment and can be redeployed whenever it is useful, and production which only ever takes the main branch.

The important word is only. A staging environment that is treated as a rehearsal becomes a second production nobody admits to running.

Cost: a change has to travel further before anyone sees it live.
Bought: nothing reaches players by accident, which matters more in a game with real-world ambitions than in a website.

Correction What we got wrong on the way § 04

We had the deployment map wrong, and only wrote it down after fixing it.

Documentation

Which folder was the test system was not what we thought.

The mapping between working directories, branches and environments had drifted from what people believed it was. Somebody testing on what they assumed was staging was not necessarily testing the thing that would ship.

What we had assumed: that a setup obvious to the person who built it is documented by existing. It is not. It is documented when it is written down and corrected in public.

Fix → the mapping was corrected and recorded explicitly — which folder, which branch, which URL, which purpose. Boring to write, and the single cheapest defence against deploying the wrong tree.

Transfer What this means where you are § 05

Staged risk only works if the stages can actually hold.

Sequence the risky capability last

Build the version that answers the product question first, even when it demos worse. The capability that carries legal or safety weight should arrive when you already know the thing is worth defending.

Isolate experiments from revenue

An experiment sharing a host with the products that fund you is not an experiment, it is a shared fate. Separate infrastructure is what makes it acceptable for the experiment to fail badly.

Write down the environment map

Which directory, which branch, which URL, which purpose. It is the least interesting document in any project and the one whose absence causes the stupidest outages.

Greenfield is where the expensive mistakes are cheap.

Early architecture decisions are the ones you live with longest and revisit least. If you are starting something and want the risky parts sequenced properly, that is a good moment to bring us in.