SaltMark

Inspiration

Most survival games drop resources onto a map that never moves, and time is just a fuel gauge ticking down. We wanted to build one where the whole world moves instead. The idea came from watching a real tidal flat empty out and fill back in: for a few hours the seabed is a place you can walk, full of things left behind, and then it is gone again. That rhythm felt like a game on its own. One number, the height of the water, could be the clock, the map, the threat and the pantry all at once, and a player could feel exactly how much danger they were in just by looking at it.

What it does

Salt Mark is a tidal survival colony game built for a phone held upright. You lead five survivors on a rock in a sea that pulls back twice a day and bares the seabed. Each tide runs through four beats: the Ebb, when the water falls and goods and stranded creatures appear on the flats; the Low, a timed window to send people out for kelp, shellfish, scrap, driftwood, fresh water and pearls; the Turn, when a horn sounds and the water visibly climbs back, taking anyone still below it; and the Flow, when everyone eats and drinks and you build or raise walls for the next cycle. Ten tides make a run, the Low gets shorter every cycle, the high water creeps upward, one storm sweeps away whatever you left loose, and the King Tide on cycle ten comes almost to the hearth. Every stranded creature offers a choice between food today and a richer sea later, because the animals you carry back to the water build a living Reef that makes every future low tide more generous.

How we built it

We started with four design documents: a game design document, a player journey map, a visual concept package and a production plan. Those went into Claude Code along with the competition rules, and the first session produced the whole vertical slice in one pass as a set of small modules: a tide engine, a world grid with pathing, survivors with needs, buildings with height and seawall rules, a Three.js renderer, a DOM HUD and procedural audio. Everything after that was a loop of playing the build, describing what felt wrong, and prompting the fix. The renderer draws all of its geometry in code and the audio is synthesized from filtered noise and simple oscillators, so the finished game has no image, model or sound files at all. A small build script assembles the source modules into a single readable index.html, copies Three.js into a vendor folder, zips the result, and refuses to build if any external URL appears in the page. Two headless tests run on every change: a smoke test over the game logic and a boot test that loads the assembled bundle under Node with a stubbed browser. We kept a running build log across twenty sessions so the AI could re-read the locked decisions and stay consistent with what we had already settled.

Challenges we ran into

The hardest problems were the ones that lived between two correct systems. Goods would spawn at the start of the Ebb and then vanish, because the wash routine removed anything under water whenever the walkable set changed, and the falling tide itself triggered it. The fix was to make the sea take goods only while it is rising, which is the honest rule anyway. Later, players reported that survivors were starving next to a full larder. The meters were fine; the meal order was wrong. Food went off in the same frame as the meal, and the drying racks delivered after everyone had eaten, so rack food was offered once and then thrown out before the next meal. Reordering the Flow so food ages, then the racks deliver, then everyone eats, fixed a bug that had looked like three different ones. Difficulty was its own fight. An early version let a colony coast through with all five survivors, so we added shorter Lows, food that spoils, buildings that only improve by being upgraded in place at doubling cost, and individual deaths from missed meals rather than a colony-wide rule that made runs binary. The competition's portrait requirement arrived after the game had been laid out for a phone on its side, and reframing the camera and every panel for a tall screen took a full session.

Accomplishments that we're proud of

The tide really is one number, and everything reads from it. The countdown is exact because the tide curve is a piecewise smoothstep rather than a sine, so the forecast never lies. Seawalls work the way a player expects: the sea floods in from the edges and spreads to any tile it can top, so a closed ring of walls keeps everything inside dry and a single gap lets the water through. The raft turns the walking rules inside out, since it can only go where the water stands deep enough, and the lone shark that hunts a crewed raft gives that boat a reason to land instead of drifting through the high water. The user interface went from six always-open panels to a rail of faces, a clock, two counts and a hint line that tells you what to do next, and the whole game ships in a zip under half a megabyte.

What we learned

For this genre the real risk is legibility, not depth. A player has to be able to look at the water and know, so every tuning number lives in one file and every event hangs off the kind of tide rather than a dice roll. We learned not to trust a test that only exercises the modules in isolation, because the worst bugs were in how two working functions were wired together. And we learned that the build log paid for itself. Re-reading the locked decisions at the start of each session stopped the AI from quietly contradicting earlier choices, and it made the honest record of what did not work as useful as the record of what did.

What's next for SaltMark

The full game becomes a campaign of coasts, each with its own tide table and its own Reef, where survivors carry their skills from one shore to the next and the sea you were kind to remembers you. Floating homes and a longer arc across many King Tides are already in the plan, and the first thing we want to validate is whether racing the water home stays tense across many more than ten cycles.

Built With

• html5