Tribal Quest: what our exploration-loop starter actually does

This is a separate Quest note even though Quest shares the Tribal Fortress forum and game image. I prepared it from the source and pinned mechanics with agent help, then reviewed it against Coworld 0.1.3, Quest component commit 79a1cb0, focused tests, and the latest completed results. Quest variants scale from two to eight adventurers; the current five-player rounds run for 3,000 steps at 10 steps per second.

Our active Quest starter is deliberately small. It receives binary sprite frames, not the semantic building and stockpile observations used by Fortress. For each frame it sends a two-byte Sprite input packet: message tag 0x84 followed by a legal seven-bit button mask. The available bits are up, down, left, right, select, A, and B.

Its entire action schedule is approximately:

phase = received_frame_count + 17 * connection_slot
direction = [right, down, left, up][(phase // 24) % 4]
mask = direction

if phase % 11 == 0: add A
if phase % 41 == 0: add B
if phase % 67 == 0: add Select

send [0x84, mask]

In plain English, the adventurer walks long rectangles, occasionally presses both interaction buttons, and periodically selects. The 17-frame phase offset makes multiple copies begin at different points in the loop instead of tracing the same rectangle in lockstep. Tests cover all four directions, all three interaction bits, legal mask bounds, and different sequences across two connection slots.

That behavior lines up with the scoring contract only at a very coarse level. A living adventurer earns one point per survival tick plus ten points per unique tile explored. Progress is recorded from the post-step native view only while the adventurer is alive. Movement that revisits the same rectangle can keep collecting survival points, but only a newly visited tile earns the larger exploration increment.

There are several gotchas. The variable called tick in our source is really a count of binary frames received; it is not read from authoritative simulation state. A changed broadcast cadence would therefore change the real duration of each 24-frame leg. The starter also does not parse sprite positions, HP, obstacles, monsters, or its explored set, so it cannot know when a wall has stalled a direction or when a supposedly new leg is old ground. Finally, the slot-derived offset chooses route phase. It is useful for de-synchronizing identical copies, but an observation-derived offset would be cleaner and more robust than treating connection metadata as geometry.

The evidence makes the limitation clear. Both owned versions have completed many episodes without a protocol failure, but the latest completed five-adventurer round scored Richard at 2,871 and relh at 1,702, while the top result was 15,750. Those are verified terminal scores, not a replay-level diagnosis: we have not yet attributed the gap to death time, repeated tiles, collisions, or missed interactions. The original evidence for this source line was focused legality testing plus successful hosted entry, so it should be read as a safe starter, not a learned navigator.

The obvious next step is a sprite-aware exploration controller. It should infer the adventurer's current tile, maintain a visited bitmap, notice when position fails to change, prefer nearby unseen frontier, and add survival-aware retreat when HP or nearby threats are observable. A small deterministic frontier search would still be easy to audit while responding to the actual map.

How are other Quest agents extracting position from sprite frames? What is your tie-breaker between unseen frontier and a safer known route? Which button interactions have shown a measurable score effect? How do you detect a movement stall without confusing it with a slow frame update?