A vine, not a tree: how Stay With Me: Deep Sea stays shippable

Stay With Me: Deep Sea is a real-time text-narrative game: you’re the only contact for Mara, a marine biologist trapped 412 metres down, and messages arrive over real minutes and hours across a three-day playthrough. Building it meant solving the two problems that kill every real-time fiction project: the story branches into a tree nobody can sustain, and the notification engine — the core mechanic — dies the moment the app is killed.

Before writing a line of story, I went to the source: Mars Jokela (3 Minute Games, Lifeline), Dave Justus, and Emily Short’s critical analysis. Nine design rules came out of that research, and every engine decision traces back to one.

The vine, not a tree

The single most important rule, and it’s Justus’s: branch sparingly, and always fold back.

A tree grows exponentially — every choice doubles the branches, and by act three you’re writing scenes nobody will see on a budget that doesn’t exist. A vine branches when it matters and rejoins the main stem quickly: the player’s choices change how they experience the next beat — tone, information, flags — but the spine of the story holds.

In Stay With Me: Deep Sea that means: choices set flags (oxygen, power, trust), flags gate how later beats play out, and alternate lines exist where they carry moral weight — not as decoration. The three endings (Mother / Cure / Compromise) are reachable from the spine, but only via different earned routes.

Real time must be visible

Waiting is the mechanic, so the wait has to be a designed space:

• The persistent radar sits on screen even inside the thread — the ocean never stops being there.
• A surface layer HUD: live clock, depth gauge, oxygen bar. The waiting itself is visible and tense.
• Catch-up bursts: if the player closes the app for an hour, backlogged messages arrive as a tense cluster — not a dump.
• QTS sequences synced to haptics, and a comms system that audibly degrades as the station does.

The phone is the horror. Every screen element reinforces "you are her only contact".

Never punish, never fake

• No unsignalled deaths. Mara’s death — when it happens — is always earned, foreshadowed, and understood. A cheap jump-scare death is a broken promise to the player.
• Callbacks over novelty. Act I choices about oxygen, power, and who to trust resurface in Acts II–III. The Compromise ending is only reachable if the player did the research — the narrative remembers.
• Pacing variance as data. Beats carry timing rules in the content schema — advance-on-open, scheduled delays, burst windows — because "when it arrives" is as authored as "what it says".

The engine that makes it testable

All of those rules would be worthless if they couldn’t be verified. The architecture is three layers:

1. A pure reducer — advance(state, action) → {next, effects} — that never does I/O.
2. Content as typed data — the vine, flag gates, and pacing encoded as data, not code. The engine is a generic interpreter.
3. A persistence/scheduling layer bridging the pure engine to Expo’s notification and haptics APIs. Effects are directives the UI interprets — SCHEDULE_NOTIFICATION, VIBRATE, SHOW_QTS.

Because the engine is pure, TDD actually works: days of play simulate in milliseconds with controlled timestamps, and content validation tests prove every beat’s references exist and no flag is required without being set somewhere reachable. 45 tests, zero runtime deps, dead ends caught before they ship.

The craft lesson generalises past games: when the mechanic is waiting, the waiting is part of the content — design it, test it, and never fake it.