Timestamp (Europe/London): 19 Feb 2026 — Draft post (AI draft, human edit).

What We Want a Turn to Feel Like

In the last post (the “5 laws” one), I laid out the principles I’m using to stop GALSOV becoming one of those games where the rules live in a haunted basement and occasionally throw bricks at you.

This post is the practical translation: not “what a turn feels like” (that would be an overconfident promise), but what we want a turn to feel like — and how the current v0.1 engine is trying to deliver that.

The vibe we’re aiming for

A good GALSOV turn (in my head) should feel like this:

Commit — you make choices that cost something.
Resolve — the simulation runs deterministically (same inputs, same outputs).
Explain — outcomes are deterministic and auditable via TurnTrace (a debug-style “receipt”), even when the UI only reveals what your empire actually knows.
Put Simply — the mystery should be in the universe, not under the hood.

If that sounds like “strategy with receipts”, yes. That’s the point.

Blog reminder: capture this as your one-line mantra: “Commit → Resolve → Explain.”

A micro-story: one colony ship, one decision

You control a small fleet in deep space. Supplies are tight. You’ve found a promising world — not perfect, but viable. Another faction’s scout has been seen nearby.

This is where GALSOV wants to be interesting: not “click colonise and forget”, but “commit resources, expose yourself for a few turns, and accept trade-offs.”

Orders Phase: the player commits

In the Orders phase, the player does a few simple things that represent a much bigger commitment:

Issue a Founding Order to the colony ship (targeting a planet or moon).
Set escort posture (defensive stance, conserve supplies, or push speed).
Set intel priority (scan for threats vs focus on local survey).

From the player side, it’s a few clicks. Under the hood, those become explicit orders queued for deterministic resolution. No “real-time mush”. No “it probably worked”. Just: orders in, outcomes out.

Blog reminder: screenshot the Orders UI/placeholder panel once it exists — it’s the clearest “player intent → engine input” proof.

Resolution Phase: the machine runs (in stages)

Now the engine resolves the turn in stable stages. The stage numbers don’t matter to a player — but the predictability does.

Movement resolves first (ships arrive or don’t).
Projects tick (founding progresses, construction advances).
End-of-turn events fire (new nodes appear, states change).

If founding has prerequisites, the machine checks them here: location, ship availability, supply constraints, and any hard rules from the Paper Rules pack.

And crucially: founding isn’t “free”. When founding begins, the colony ship is consumed immediately (cannibalised into the settlement). You don’t get to change your mind later without paying for it.

Founding also isn’t instant. In v0.1, the colony only becomes a true Settlement Node after 3 turns of progress — which means you’re exposed, trackable, and potentially interruptible while it happens.

Blog reminder: call out the design intent here: “Colonisation is a multi-turn vulnerability window, not a button.”

TurnTrace: the receipts you can actually read

After resolution, GALSOV produces TurnTrace — a log designed to answer one question: why did that happen?

Here’s what a simplified TurnTrace excerpt could look like for founding:

Turn 18 (Seed: SEED_2026_02)
Orders:
  FoundingOrderIssued  Fleet=FLEET_03  Target=Harrow-IV (Moon A)

Stage 70 (Founding):
  FoundingStarted      Project=FOUND_001  Site=Harrow-IV / Moon A
  ColonyShipConsumed   Fleet=FLEET_03  Ship=CS-01

EndOfTurn:
  FoundingProgressed   Project=FOUND_001  Progress=+1 (1/3)
  ThreatPingDetected   Source=Unknown  Range=2

Even if you’re not a programmer, you can read that and understand: the order was issued, the founding project started, the ship was consumed, founding progressed, and you detected something suspicious nearby.

That “(1/3)” is doing a lot of work. It turns colonisation into a strategic commitment instead of an admin chore.

Blog reminder: keep one TurnTrace snippet per devlog post as a “public-safe proof nugget”.

What we want the player to see (and what v0.1 currently shows)

In v0.1 the map stays intentionally simple (stars first). The detail lives in the right panel when you select a system.

For this founding example, the “player-facing truth” should be something like:

Founding status: “Harrow-IV / Moon A — Founding (Turn 1/3)”
Fleet change: colony ship removed (used up in the colony)
Intel hook: a new “threat ping” indicator with uncertainty (not full knowledge).

That’s the loop: commit → resolve → explain. Strategy lives in the gap between what you know and what you can afford to do.

Why build it this way?

A lot of strategy games have hidden rules that only make sense after you’ve been burned by them. I want the opposite: outcomes can be complex, but they should be legible.

TurnTrace is my answer to “complex but understandable.” Also, selfishly: it lets me prove progress publicly. If I claim founding works, I can show the receipts.

Next up

I’m going to do more of these “turn slices”, each tied to a real milestone card. The goal is to keep the devlog balanced: some posts for builders (engine/process), and some for players (feel/choice/why).

Devlog prompt: after each system lands, write one small “what we want the player to feel” section, and one small “TurnTrace proof” section.

What a turn feels like