Player, Controls, and Platform

No avatar Decided

The player has no character on the map. You aren’t a soldier, a driver, or a drone. You are an unseen architect who can look anywhere you have explored and build there (not into fog of war).

The three advisors also have no physical presence in the simulation (see narrative.md).
Factory games usually use an avatar for exploration and for carrying building materials. This game replaces those jobs with Scout Drones (exploration) and Engineering Crews / trucks (carrying materials). See units-and-missions.md.

Building-owned units Decided

Everything that moves belongs to a building:

Trucks and Harvesters belong to a Depot. Robots belong to a Barracks. The first drone, Harvester and crew belong to the Crashed Ship.
You give missions to the building, never orders to the unit: patrol here, gather there, run depot A → depot B, a one-time out-and-back trip, recall.
Tapping a unit only shows its contents and status. A unit has no controls Decided.
Tapping any unit selects it and opens its building’s panel Decided (Nov 2026, after the first playtest). It’s the same for every unit in the game. The camera doesn’t move. If the building has several unit slots, the panel highlights the tapped unit’s slot, so it’s clear which one it is.
A building’s panel lists its units, each with what it carries, all the time Tentative (Nov 2026). Picking a unit’s row selects it, moves the camera to it, and readies the slot’s default mission, so the next tap on the map sets it. Most default missions are about where to go: a Harvester’s is where to mine, the Scout’s where to fly. A unit whose jobs come by themselves, such as the Engineering Crew, has none, so picking it only selects it and shows it. The mission still goes to the building’s slot, so a unit still has no controls of its own.
A building has a fixed number of unit slots. One Barracks can’t swarm the map. To get more units you build more buildings, which caps how big your forces get.

On a phone, an instruction is: scroll the map, tap a building, tap a destination. You never steer a drone.

Micro budget Decided

No direct unit control, ever. Even a mixed group sent from a Barracks is just several units given the same mission (see combat-and-defense.md).
Open The Scout, and maybe attack units, may be the exception: after the first playtest the designer wants to let players fly the Scout on a timed battery that brings it home on its own. Micro stays optional and never spreads to Harvesters or groups (open question #50).
Most management is setting a rule once and watching it play out.
Later tech removes the remaining repetitive chores. Fewer clicks as the game goes on is a deliberate design goal.

Mobile-first Decided

No conveyor belts. Routing belts on a touchscreen is tedious.
Everything snaps to a square grid. No sub-grid placement.
Overlays and status lights replace reading belts (see base-network-and-inventory.md).
Short sessions are supported: drop in, tweak, leave.
Nearly everything on screen has a hover tooltip saying what it is or what it does: buttons, the build list, storage slots, status lights, unit rows. Touch has no hover, so a phone reaches the same words another way, such as long-press or the selection panel Open.

Multiplayer Decided

Multiplayer cooperative by design, built around a shared long-term map on a private server, like hosted factory-game worlds.
Friends join and build together on the same world.
The world pauses when the last player leaves.
The server owns the tick. In multiplayer, the server runs the one simulation; clients send commands and receive state. Clients never each run their own copy in lockstep (the Factorio and Supreme Commander model), which avoids desyncs.
Single player runs the whole simulation on the phone. Phones are fast enough. It’s the same simulation the server runs, just hosted locally.
The simulation runs at 20 ticks per second, in the prototype too. See tier0-proposals.md for how other games compare.
Evolite is a single global balance shared by every player on the map (see resources-and-economy.md).
The story avoids making any one player “the protagonist,” which is one reason the player-as-captain framing is still debated (narrative.md).

Lockstep vs a server-owned tick

The two common ways to run a shared simulation. We chose the second.

Lockstep (Factorio, StarCraft II, Supreme Commander, Age of Empires): every client runs the whole simulation. Only commands go over the network, each scheduled for a future tick, and every device runs that tick once it has everyone’s commands. Identical start, identical commands and identical code give an identical world. A dedicated server, if there is one, is just another copy running the same simulation and relaying commands. Supreme Commander and Age of Empires had no server at all.
Server-owned tick (Minecraft, Satisfactory, most online survival games): only the server runs the simulation. Clients send commands and get back the state of what they can see, then draw it.

So the server runs the whole simulation in both models, if there is a server. The difference is whether every client runs it too.

	Lockstep	Server-owned tick
Who simulates	Every client, plus the server if there is one	Only the server
Network traffic	Tiny: only commands	State updates for what each player can see. Grows with activity in view
Desyncs	Possible. Any difference between devices splits the world and stops the game; the world needs regular hash checks	Impossible: there’s only one world
Versions	Every client must run bit-identical simulation code: same build, same mods, and math that gives the same answer on every CPU	Clients need a compatible network protocol. The simulation only runs on the server, so a client-only fix (UI, art) doesn’t force everyone to update
Determinism	Required, exactly, across iOS, Android and PC. Floating-point math is the usual trap	Optional. Still useful for replays, tests and bug reports
Slow device	Slows everyone down	Only that player’s view lags
Joining a running world	Download the whole save, then simulate to catch up	Receive the area in view. Fast
Enormous maps	Every phone simulates every base on the map, all the time, even in the background	Phones only draw what’s on screen. Better for battery and heat
Input delay	Commands wait a few ticks for everyone, including the host	One round trip to the server. About the same, and fine for giving missions to buildings
Hosting cost	Low. The server relays commands (and may also simulate)	Higher. The server simulates everything and sends state
Fog of war	Every client holds the full map, so fog can be hacked	The server only sends what each player can see
Hard part to build	Cross-platform determinism; desync bugs are notoriously hard to find	Sending state efficiently: only changes, only what’s in view, and smoothing motion between updates

Why the server-owned tick fits this game:

Lockstep exists to avoid streaming huge numbers of moving items (Factorio’s belts, an RTS’s thousands of units). We have no belts. Vehicles and creatures move, and sleeping machines rarely change state.
No avatar. Missions go to buildings, so a 100–200 ms round trip is unnoticeable. Shooters need client-side prediction; we don’t.
Persistent worlds that players drop in and out of, on maps that will get enormous.
Phones as clients, where battery and heat matter more than raw speed.

Cheating matters less in a co-op game, so the fog row is a side benefit.

Tech stack Decided

TypeScript everywhere. The client is a web game. The server is Node. The simulation is one TypeScript package that only the server side uses, and that balance tools can run with no screen. The client and the sim share only a small package of pure functions and data shapes (simulation-architecture.md).
Players on PCs open a link in their browser. On iPhone the game runs in Safari at first; an app, if wanted, is a thin native shell around the same web game Tentative.
The client and the host are separate from the first single-player build. In single player the host runs in a Web Worker in the browser. It talks to the client only through commands and state updates, exactly as a remote server would, so multiplayer later changes the transport, not the design. How the loops, commands and sync work is in runtime-and-sync.md.
The sim follows Bevy’s ECS conventions and names Tentative: entities, components and systems, a schedule of phases, a command buffer, event queues. That keeps a later move to Rust mostly mechanical. See simulation-architecture.md.
Hosting Decided:
- The game and the design site are each a Cloudflare Worker serving static files, and each links to the other. Not Cloudflare Pages. Single player needs nothing else: the whole sim runs in the player’s browser.
- The multiplayer host is the Node host on the designer’s Mac Mini. How players reach it (a Cloudflare Tunnel, Tailscale) is chosen when multiplayer is built Tentative.
- This is a trusted-testers phase: both sites are public, with no sign-in, and nothing in them is hidden.
Rendering: PixiJS v8 Tentative, with Three.js as the alternative Open (first-test.md). The world is a flat top-down grid that never rotates. Panels and overlays are HTML over the game canvas, written in React Decided.
Art starts as placeholders Tentative: colored shapes with a letter (an H for a Harvester), with one table per building and unit type holding its look, so real art replaces it in one place. The panels, numbers and status lights carry the game until then.
Later art: 3D models baked to sprites Tentative, the way Factorio’s art is made. Claude writes each model as code (simple shapes in Three.js), a browser tool previews it, and a bake step renders the needed angles and animation frames from a fixed orthographic camera into sprite sheets.

Why TypeScript and the web:

One language for client, server, simulation and tools, and Node runs almost anywhere.
Fastest loop for a prototype: save, refresh, play, including on a phone over the home network.
Best fit for coding with Claude: everything is text, and Claude can open the game in a browser and check its own work.
The scale is small. The goal is a prototype played with a few friends, not millions of players, and TypeScript is fast enough for that simulation.

Not chosen:

Native Swift. The designer knows it best and it runs fast, but it locks the client and the server to Apple platforms, has few game-development resources, and Claude writes it less well than TypeScript.
Unity. The safe default for professional game developers, but most of its editor and tooling serve 3D worlds this game doesn’t need, and editor-heavy work suits AI-assisted coding less well.
Godot. A strong engine for small 2D games and still an option if the web falls short, but it felt less familiar than the web stack [Open whether to revisit].

Rust later Open

Rust with Bevy’s ECS library is the planned path for the simulation if the TypeScript sim outgrows itself, or as a later learning step. The sim would run natively on the server and in tests, and as WebAssembly in the browser worker for single player; the client stays TypeScript.

For: a strict compiler checking Claude’s code (exhaustive enums, no nulls, real integers), enforced ECS conventions, native speed and lower memory on the server. Rust is also close to Swift.
Against, for now: two new languages at once, setup friction compiling Rust for the browser, a large dependency with frequent API changes, and slower iteration. Performance isn’t a reason yet: at Tier 1 scale both languages use a tiny share of the tick.
Why it stays cheap to switch: the client only sees commands and state, and the sim’s tests, ported from the Python sims, check a port.

The research behind this is in tech-research.md.