Editorial illustration: Button feedback without touching game rules

Button feedback without touching game rules

The problem I needed to solve

A button should respond visually to touch, but its small motion should not own purchasing or launching a game. I separated those responsibilities.

Implementation in this snapshot

ButtonPressFeedback handles PointerDown, PointerUp and PointerExit by changing scale. PointerClick only plays feedback audio; the button’s actual action stays in its own listener.

The design decision and its cost

With USE_DOTWEEN it uses a tween, otherwise a coroutine provides the fallback. Unscaled timing allows interface feedback to continue when gameplay time is paused.

Current boundaries

OnDisable stops active motion and restores the original scale. Touch feel, overlapping targets and sound still need device testing; two implementation paths do not automatically establish equal quality.

Review scenarios and contract meaning

A simple acceptance scenario is pressing the button and moving the finger away before release. The player expects the normal scale to return even when no final click occurs. Separating PointerExit from PointerClick makes that distinction explicit. Another scenario is closing a panel during the motion: leaving the smaller scale on the object would make the next opening look broken. Restoring the original value in OnDisable matters for that cycle. This behavior controls appearance; it does not authorize an economic operation or a scene change.

The two motion paths are a project dependency choice. A project with DOTween can use its existing tool, while one without it still has the coroutine fallback. The cost is that changes to duration, easing or cancellation need checking in both paths. Watching one mouse click is not enough to assess the interface. Rapid repeated touches, panel changes, paused gameplay and a finger leaving the target pose different questions. My criterion here is feedback that responds and reaches a defined end without making the button’s actual listener depend on animation timing.

The motion amount should be reviewed in the button’s actual surroundings. Scaling near another target may feel pleasant, but layering and touch bounds remain separate concerns. I also keep click audio distinct from the primary action so disabling sound or lacking an audio component does not change the button’s meaning.

What this stage taught me

For me, one reusable component beats copying animation into every page. The interface can feel more responsive while purchase and game rules retain their own homes.

Explore Dalo

Latest devlogs

Editorial illustration: Pasur launch and telemetry in the shared structure

Pasur launch and telemetry in the shared structure

Adding Pasur needs both a correct mode handoff and valid public telemetry.

Read article
Editorial illustration: Pasur bot decisions from capture options

Pasur bot decisions from capture options

My teammate’s Pasur bot chooses among legal options without inspecting hidden opposing cards.

Read article
Editorial illustration: Capturing table cards in Pasur

Capturing table cards in Pasur

In my teammate’s implementation, Pasur combines selecting a hand card with selecting table cards. Its rules must produce valid sets and prohibit ignoring an available capture.

Read article
Dalo