Touch controls are the most critical component of a mobile game's gameplay. Mistakes in touch recognition immediately lead to player churn. Our experience: over 5 years in the industry, 30+ implemented projects with gesture recognition accuracy guaranteed at 94%+. Contact us to discuss your project.
Why Standard Solutions Fall Short with Touch Controls
Unity on mobile devices handles touches via Input.GetTouch() or the newer InputSystem—and there is a gap between them. The old API does not distinguish between a tap and the start of a swipe until the finger is lifted. For games that require instant reaction to touches, this is unacceptable. The most common mistake is gesture recognition based on TouchPhase.Ended. The developer compares the Began and Ended positions, calculates a vector—and gets a swipe. It works on a device at 60 FPS. At 30 FPS with thermal throttling (typical for budget Android devices), the delta between frames grows, and a short tap is classified as a swipe.
The correct approach is to track movement in Stationary and Moved phases, add a distance threshold (sqrMagnitude > threshold) and a time threshold (Time.time - touchStartTime < tapMaxDuration). Unity does not provide this out of the box—you need a custom GestureRecognizer. In Godot 4 with InputEventScreenTouch and InputEventScreenDrag, the situation is slightly better: the engine separates events at the API level. But multi-touch is another story. The index of InputEventScreenTouch gives the sequential number of the finger, and when one finger is quickly lifted, the indices may remap, breaking two-finger gesture logic.
How We Build a Gesture System
For Unity, we write a TouchInputManager as a singleton MonoBehaviour that iterates Input.touches every frame in Update() and assigns touches to finite state machines—one FSM per active fingerId. States: Idle → Pressing → Tapping/Swiping/Holding. Transitions are based on distance and time. Output: events such as OnTap(Vector2 position), OnSwipe(Vector2 direction, float velocity), OnHold(Vector2 position, float duration), OnPinch(float delta). Game systems subscribe to these events via C# delegates or UnityEvent, without knowing anything about Input.GetTouch.
For Flutter games on the Flame engine, we use TapDetector, PanDetector, ScaleDetector from the flame package. These work correctly on top of Flutter GestureArena—each detector participates in the gesture contest, and the winner is determined by priority. Important: ScaleDetector and PanDetector conflict if behavior: HitTestBehavior.opaque is not set on the parent widget.
Example FSM implementation for a single touch in Unity
public class TouchFSM : MonoBehaviour { private enum State { Idle, Pressing, Tapping, Swiping, Holding } private State currentState = State.Idle; private Vector2 startPos; private float startTime; public void UpdateTouch(Touch touch) { switch (currentState) { case State.Idle: if (touch.phase == TouchPhase.Began) { startPos = touch.position; startTime = Time.time; currentState = State.Pressing; } break; case State.Pressing: if (touch.phase == TouchPhase.Ended) { float dist = (touch.position - startPos).sqrMagnitude; float duration = Time.time - startTime; if (dist < tapDistanceThreshold && duration < tapMaxDuration) currentState = State.Tapping; else if (dist >= swipeDistanceThreshold) currentState = State.Swiping; else currentState = State.Holding; } break; // ... remaining states } } } Case Study: Swipe Attacks in an RPG
From our practice: in one project (top-down RPG, current LTS version of Unity) we needed directional swipe attacks with eight directions. Simple vector normalization gave unstable results—diagonal directions triggered less often because users rarely swipe exactly at 45°. Solution: tolerance zones of ±30° instead of standard ±22.5°, plus weighting by swipe speed—fast swipes are less accurate, slow ones are more accurate. After that, correct recognition rate increased from 78% to 94%—a custom GestureRecognizer provides a 16% accuracy improvement over the built-in API (by Firebase Analytics). Additionally, visual feedback via LineRenderer draws a fading trail. Without it, the player doesn't know the game registered their gesture.
Comparison of Approaches in Popular Engines
| Engine | Touch Input API | Built-in Gesture Recognition | Multi-touch (2+ fingers) | Notes |
|---|---|---|---|---|
| Unity | Input.GetTouch / InputSystem | No (needs custom GestureRecognizer) | Yes, with FSM per fingerId | Industry standard, flexible but requires a lot of code |
| Godot | InputEventScreenTouch/Drag | Partial (separates tap and swipe) | Yes, but indices may remap | Higher-level API, less low-level control |
| Flutter (flame) | TapDetector, PanDetector, ScaleDetector | Full (GestureArena) | Yes, but detector conflicts | Excellent abstraction, limited customization |
What Is Included in the Work?
- Gesture system architecture: FSM per fingerId, custom GestureRecognizer.
- Integration with game mechanics: binding events to animations, shooting, movement.
- Optimization for low-end devices: thresholds, anti-throttling.
- Visual feedback: trails, indicators, pulsations.
- Testing on a fleet of 50+ real devices (Android, iOS).
- Documentation and team training.
How We Guarantee Results
We guarantee gesture recognition accuracy of at least 90% on devices with 30 FPS or higher. Our experience shows that a properly designed system reduces user complaints about controls by an average of 60%. Get a consultation for your project—contact us, we will assess the task and propose the optimal solution.
Timelines and Cost
Basic system (tap, swipe, hold) for one platform: 2–4 days. Full system with multi-touch, pinch, custom gestures, and integration with game mechanics: 1–2 weeks. Cost is calculated individually after project requirements analysis.