Rework the movement preview for touch #23

New issue

Closed

opened 2026-09-13 17:06:07 +00:00 by icub3d · 0 comments

icub3d commented

2026-09-13 17:06:07 +00:00

Owner

Implements ADR 0003.

MovementPreview holds "the route to whatever the cursor is over", fed by HoveredTile,
and the overlay draws a line from the selected unit to the cursor ending in an arrowhead.
A touchscreen has no cursor, so the tile is never hovered and the line is never drawn.
The flood fill and the reachable diamonds survive; the half of the overlay that answers
where am I going does not.

Rework it as a two-stage commit: tap a unit to select, tap a tile to choose a
destination, confirm to act. The chosen tile stays chosen until the player picks another
or cancels — a preview that exists only while a finger is down is one the player cannot
read, because their hand is on top of it.

Do this before #6 and #8 build on the current shape, which is the entire reason ADR 0003
was written now rather than later.

Constraints

One flood fill still answers both halves. A separate search for the route could return
an equal-cost rival to the one the overlay was built from, and a unit that walks a
different way than the line promised is a bug the player sees and cannot explain.
Hover may still enrich the desktop build — brightening the tile under the cursor —
but nothing it shows may be unavailable without it.
A two-stage commit has a state the player can be stuck in, so it needs a visible
cancel affordance, not just Escape.

Done when

A unit can be selected, a destination chosen, and the choice cancelled, using only taps;
the desktop mouse path still works; and the route drawn is the route the flood fill
found.

Implements [ADR 0003](../src/branch/main/docs/adr/0003-touch-first-input.md). `MovementPreview` holds "the route to whatever the cursor is over", fed by `HoveredTile`, and the overlay draws a line from the selected unit to the cursor ending in an arrowhead. A touchscreen has no cursor, so the tile is never hovered and the line is never drawn. The flood fill and the reachable diamonds survive; the half of the overlay that answers *where am I going* does not. Rework it as a two-stage commit: tap a unit to select, tap a tile to choose a destination, confirm to act. The chosen tile stays chosen until the player picks another or cancels — a preview that exists only while a finger is down is one the player cannot read, because their hand is on top of it. Do this before #6 and #8 build on the current shape, which is the entire reason ADR 0003 was written now rather than later. ## Constraints - One flood fill still answers both halves. A separate search for the route could return an equal-cost rival to the one the overlay was built from, and a unit that walks a different way than the line promised is a bug the player sees and cannot explain. - Hover may still *enrich* the desktop build — brightening the tile under the cursor — but nothing it shows may be unavailable without it. - A two-stage commit has a state the player can be stuck in, so it needs a visible cancel affordance, not just Escape. ## Done when A unit can be selected, a destination chosen, and the choice cancelled, using only taps; the desktop mouse path still works; and the route drawn is the route the flood fill found.

icub3d added the

labels

2026-09-13 17:06:14 +00:00

icub3d added this to the M1 — Playable Vertical Slice milestone

2026-09-13 17:06:15 +00:00

icub3d referenced this issue from a pull request that will close it,

2026-09-13 18:03:56 +00:00

Choose a destination by tapping, not by hovering #36