A route is not a reason
We made Lantern Ferry's couriers harder to summon. The playtest showed why that was the wrong next step.
Lantern Ferry has a shortcut: a short back-and-forth sail can bring the couriers to you, leaving them to finish the deliveries. We tried making couriers approach only when you sailed toward their lantern's destination.
That stopped our repeated-input test from clearing the harbor. The same northwest/southeast shuttle went from four completed islands to two. A separate touch-controlled test that deliberately followed destinations could still finish all four.
But stopping a shortcut is not the same as making a better game.
A fresh reviewer played full desktop and phone rounds without seeing the code or our plan. Picking up a lantern was clear; deciding where to pass it was not. The suggested recipient changed during a crossing. One successful pass reached an idle teammate and stayed there. Neither complete round finished an island, and the reviewer would not play again.
The browser checks passed, including responsive touch movement and a shared round. Those checks could not tell us whether cooperation made sense. The review used emulated touch, and tool delays consumed some round time; it was not a physical-phone or independent-human playtest.
We have shelved the route restriction. The public game keeps its previous courier behavior.
The next experiment needs to make the useful action clear: show the destination when a direct delivery helps, make the final relay easy to understand, and avoid suggesting a handoff to someone who is idle. A harbor should invite cooperation before it demands more navigation.
