Progression, crews and a world worth returning to

What makes a captain come back after the first successful run? What makes joining a crew useful when its members cannot all play at the same time? And how do we make a risky route tempting without making a quieter evening feel pointless?

Those are design questions for Dead Water. They need answers that fit our boats, ports and players, followed by evidence from the actual game.

Progression should create useful choices

The direction is to give a returning captain more opportunities: useful contacts, different contracts and a history that matters when entering a port. We want progress to change the decisions available, not make every encounter a foregone conclusion based on time played.

That is a goal, not a claim that the balance is finished. The current prototype has performance refits, and their existing effects and saved purchases need to be respected. Fair shared-world progression still needs an explicit design and playtesting before we make promises about competitive equality.

The first local standing implementation gives some of that history a practical use through intel pricing, boat discounts and access. Its shared-world authority and long-term reward tuning remain work ahead.

A crew should not require a calendar invitation

Dead Water needs to remain worthwhile when a captain plays alone or when only part of a crew is available. Coordinated boat work should offer interesting choices without making the basic voyage depend on assembling a large group.

The current boat and work loops give us a place to test that. Longer-term crew systems, shared resources and contracts between players remain design work where their authority, funding and ownership rules are not yet implemented.

Large scheduled conflicts and contested ports need a population that can support them. They are not prerequisites for making an ordinary trip worth taking.

Risk needs to be readable

Cargo, fuel, visibility and the route home should give players enough information to make deliberate decisions. A higher advertised payout is not meaningful if the likely costs are hidden or a failure leaves no usable recovery path.

We need to measure earnings against time, fuel, preparation and losses in Dead Water itself. The same applies to fishing and other legitimate work: a quieter trip should be a useful choice, not an obligation that exists only to fund the next dangerous one.

No particular payout multiplier or damage formula is a commitment in this post. Those values need our own implementation checks and human playtests.

What still needs proving

Automated checks can establish that a transaction happens once, a save survives a restart or a crew member cannot operate somebody else’s boat. They cannot establish that people enjoy coordinating a voyage or want to do another one.

That means testing with players who did not build the game, watching where they hesitate, and changing the design when the evidence calls for it. The prototype is where these questions become testable, not proof that they are already solved.

Updated September 9, 2026 to focus this article on Dead Water’s design goals and current implementation boundaries. For the latest build status, see The boat has work to do now.