EL ÚLTIMO ZARPE — All that survives the loop is what you understand

A roguelike without meta-progression, where only understanding accumulates · Own video game · Preparation roguelike

Client

Side project — my own game

Role

Game design, development and art direction

Timeline

July 2026 – ongoing

Stack

Godot 4.7, GDScript, JSON as the rules layer, HTML/SVG prototype as oracle, Art direction

The modern roguelike teaches you to memorise builds: you die, you earn permanent coins, you come back stronger. The player doesn’t solve the difficulty; unlocks erode it. El Último Zarpe (The Last Sail) does the opposite — no persistent coins, no upgrade tree. A port called Grisal, numbered days, a ship that sails with or without you. You prepare the voyage with limited money, contradictory information and a hold that can’t fit everything. You usually die. What you learn by dying is all you take with you.

The problem: A game that kills constantly has a very narrow margin for error

If a death feels arbitrary, the player doesn’t learn: they leave. On top of that, an uncomfortable measurement after the port revealed that the supposedly replayable game had only 6 possible puzzles in long mode — memorisable in an afternoon. Three difficulty parameters did absolutely nothing.

How it was approached

1. The real problem wasn’t the loop, it was unfairness. A game that kills the player constantly has a very narrow margin for error: if a death feels arbitrary, the player doesn’t learn, they leave. The first design decision wasn’t about content but about a contract — never lie to the player about the rules; do lie about the facts. And “fair” here isn’t a statement of intent: every generated voyage is proven solvable before you are allowed to start. A verifier proves by brute force that at least one combination of purchases survives, with an economic margin. If it can’t find one, that voyage never reaches the player.
2. Retrying is the same puzzle, not a new one. The most counterintuitive decision in the project: going back to Grisal repeats the same seed on purpose. The roguelike temptation is to give a new run after every death, but that turns failure into noise — if the next voyage is a different one, what you learned about this one is worth nothing. By repeating the seed, the second attempt is the same enemy with more light: the player returns to port knowing the water runs out on day 3, and this time spends their questions on something else.
3. The prototype first, in HTML. Before touching Godot I built the entire game as an HTML page with SVG and JS — playable from start to finish — so the design could be discussed by playing it rather than imagining it. Once the mechanics were clear, that prototype became something more useful than documentation: the executable specification of the port. The Godot engine wasn’t considered correct until it generated exactly the same voyage as the prototype for the same seed.
4. We measured that the game was boring, and fixed it with numbers. After the port, an uncomfortable measurement: in long mode only 6 puzzles were possible, and three difficulty parameters did nothing at all. The game that was in theory infinitely replayable was, in practice, memorisable in an afternoon. The answer was to widen the repertoire — from 6 to 12 hazards, from 13 to 18 items — and, above all, to take the rules out of the code and put them into data. Today difficulty lives in a JSON file that gets tuned between playtest runs without recompiling.
5. The port map is a variable too. The port has eleven locations and not all of them open every run: the same seed that generates the voyage draws which ones are open today, so the optimal route stops being memorisable. Two safeguards stop the rotation from degenerating into frustration. There is an information floor — if the draw leaves the port too poor, extra locations open — and a harder rule, learned by breaking it: whatever switches a mechanic off doesn’t rotate. At first the alley, home to the only informant able to point out that a clue is false, was part of the draw. It cost variety (from 126 possible maps to 56) and it was worth it.

seed → crossing: Seed + difficulty + length → Voyage generation → Solvability verifier → Port location rotation → Information floor → Preparation · daily actions → Cascading crossing → Logbook · what killed you

Solution: Proven solvability and rules outside the code

A verifier proves by brute force that every generated voyage has at least one combination of purchases that survives with an economic margin; if it can’t find one, that voyage never reaches the player. The repertoire went from 6 to 12 hazards and from 13 to 18 items, and difficulty now lives in a JSON file that gets tuned between playtest runs without recompiling.

Product decisions

• my role: Game design, development and art direction
• the contract with the player: Never lie about the rules; do lie about the facts. Clues can be false and people lie in the tavern, but the system is fair — and that is proven, not promised.
• most counterintuitive decision: Going back to Grisal repeats the same seed on purpose. If the next voyage were a different one, what was learned about this one would be worth nothing. The second attempt is the same enemy with more light.
• status: Playable from start to finish. Self-contained Windows executable, verified in a clean directory. No store or date.

Results

The game is playable from start to finish and ships as a self-contained Windows executable, verified in a clean directory. Everything measurable today is about the system, not the players: there are no external playtests yet, no retention metrics, no store and no date. Any figure here speaks to the soundness of the system, not to anyone having liked it. That is the next step, not a result already achieved.

• 405/405 — combinations with exact parity against the prototype, across two oracles
• 792 — possible puzzles in long mode — there used to be 6
• 56 — distinct port maps through location rotation

"What rotates are voices, never mechanics. In ~44% of runs the player lost the ability to detect lies without anything telling them: exactly the kind of difficulty you can’t learn from."

What was learned

1. Measure variety before you believe in it. The infinitely replayable game had six puzzles. It wasn’t a design hunch that caught it: it was counting. If a generative system isn’t instrumented, it’s assumed to work because it’s generative.
2. A playable prototype is worth more as an oracle than as a document. Writing the game twice — first in HTML to play it, then in the engine — gave a definition of correct that admits no opinion: same result for the same seed, or the port is wrong.
3. What’s missing, and I know it. The preparation days are still decorative, mandatory water turns one purchase into a non-decision, and there’s almost never a hazard without an honest clue — which is exactly what would give the logbook between loops its full meaning.

In development. Working Windows build; no store or date yet.