Add selectable touch input mode (one-tap auto-move vs. tap-to-select) #70

New Issue

2026-05-28T19:46:20Z

funman300 commented

2026-05-28 19:46:20 +00:00

On touch/Android, the game currently uses single-tap auto-move: tapping a card immediately sends it to the best valid destination. Playtest feedback found this occasionally makes unintended moves. This issue adds a second input mode and a setting to switch between them.

One-tap (auto-move): current behavior. Unchanged.
Tap-to-select: first tap selects a card/stack and highlights it; second tap on a valid destination performs the move. Tapping the selection again, or an invalid target, cancels.

Scope

In scope:

A persisted setting with two values: OneTap (default) and TapToSelect.
Tap-to-select logic: select → highlight → move-on-valid-destination → cancel-on-invalid/re-tap.
Visual highlight for the selected source.
Wire the setting into the existing settings UI and persistence.

Out of scope:

Drag-to-move.
Any change to one-tap behavior or to the move-validation rules themselves.
Desktop/mouse input changes.

Acceptance criteria

Setting exists, defaults to OneTap, and persists across sessions.
In OneTap mode, behavior is identical to current.
In TapToSelect mode: first tap highlights a valid source; tapping a valid destination moves it; tapping an invalid target or the source again cancels with no move.
No move is ever made in TapToSelect mode without an explicit destination tap.
cargo build and existing tests pass; new logic has at least basic test coverage.

Notes

Bevy ECS project. Reuse existing move-validation; this is an input/state-machine layer on top, not new game rules.
Source: Android playtest feedback (Rhys), 2026-05-27.

On touch/Android, the game currently uses single-tap auto-move: tapping a card immediately sends it to the best valid destination. Playtest feedback found this occasionally makes unintended moves. This issue adds a second input mode and a setting to switch between them. **One-tap (auto-move):** current behavior. Unchanged. **Tap-to-select:** first tap selects a card/stack and highlights it; second tap on a valid destination performs the move. Tapping the selection again, or an invalid target, cancels. ## Scope In scope: - A persisted setting with two values: `OneTap` (default) and `TapToSelect`. - Tap-to-select logic: select → highlight → move-on-valid-destination → cancel-on-invalid/re-tap. - Visual highlight for the selected source. - Wire the setting into the existing settings UI and persistence. Out of scope: - Drag-to-move. - Any change to one-tap behavior or to the move-validation rules themselves. - Desktop/mouse input changes. ## Acceptance criteria - [ ] Setting exists, defaults to `OneTap`, and persists across sessions. - [ ] In `OneTap` mode, behavior is identical to current. - [ ] In `TapToSelect` mode: first tap highlights a valid source; tapping a valid destination moves it; tapping an invalid target or the source again cancels with no move. - [ ] No move is ever made in `TapToSelect` mode without an explicit destination tap. - [ ] `cargo build` and existing tests pass; new logic has at least basic test coverage. ## Notes - Bevy ECS project. Reuse existing move-validation; this is an input/state-machine layer on top, not new game rules. - Source: Android playtest feedback (Rhys), 2026-05-27.

funman300 referenced this issue from a commit

2026-05-28 21:04:55 +00:00

feat(engine,data): add tap-to-select touch input mode (#70)

funman300 closed this issue

2026-05-28 21:05:02 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: funman300/Ferrous-Solitaire#70