בקרות מגע למשחקי מובייל: יישום הקשות, החלקות ומחוות

בקרות מגע הן הרכיב הקריטי ביותר במשחקיות של משחק מובייל. טעויות בזיהוי מגע מובילות מיד לנטישת שחקנים. הניסיון שלנו: למעלה מ-5 שנים בתעשייה, יותר מ-30 פרויקטים מיושמים עם דיוק זיהוי מחוות מובטח של 94%+. צרו קשר כדי לדון בפרויקט שלכם.

מדוע פתרונות סטנדרטיים נכשלים עם בקרות מגע

Unity במכשירי מובייל מטפל במגעים באמצעות Input.GetTouch() או ה-InputSystem החדש יותר—ויש פער ביניהם. ה-API הישן אינו מבחין בין הקשה לתחילת החלקה עד שהאצבע מורמת. עבור משחקים שדורשים תגובה מיידית למגעים, זה בלתי מתקבל על הדעת. הטעות הנפוצה ביותר היא זיהוי מחוות המבוסס על TouchPhase.Ended. המפתח משווה את המיקומים של Began ו-Ended, מחשב וקטור—ומקבל החלקה. זה עובד על מכשיר ב-60 FPS. ב-30 FPS עם הגבלת תרמית (אופיינית למכשירי Android תקציביים), ההפרש בין פריימים גדל, והקשה קצרה מסווגת כהחלקה.

הגישה הנכונה היא לעקוב אחר תנועה בשלבי Stationary ו-Moved, להוסיף סף מרחק (sqrMagnitude > threshold) וסף זמן (Time.time - touchStartTime < tapMaxDuration). Unity לא מספקת זאת מובנה—יש צורך ב-GestureRecognizer מותאם אישית. ב-Godot 4 עם InputEventScreenTouch ו-InputEventScreenDrag, המצב מעט טוב יותר: המנוע מפריד אירועים ברמת ה-API. אבל ריבוי מגעים הוא סיפור אחר. ה-index של InputEventScreenTouch נותן את המספר הסידורי של האצבע, וכאשר אצבע אחת מורמת במהירות, המדדים עשויים להתמפות מחדש, מה ששובר את הלוגיקה של מחוות שתי אצבעות.

כיצד אנו בונים מערכת מחוות

עבור Unity, אנו כותבים index כ-MonoBehaviour יחידני שעובר על TouchInputManager בכל פריים ב-Update() ומקצה מגעים למכונות מצב סופיות—FSM אחד לכל Input.touches פעיל. מצבים: fingerId. מעברים מבוססים על מרחק וזמן. פלט: אירועים כגון Idle → Pressing → Tapping/Swiping/Holding, OnTap(Vector2 position), OnSwipe(Vector2 direction, float velocity), OnHold(Vector2 position, float duration). מערכות המשחק נרשמות לאירועים אלה באמצעות דלגייטים של C# או UnityEvent, מבלי לדעת דבר על OnPinch(float delta).

עבור משחקי Flutter במנוע Flame, אנו משתמשים ב-Input.GetTouch, TapDetector, PanDetector מהחבילה ScaleDetector. אלה פועלים כראוי על גבי Flutter GestureArena—כל גלאי משתתף בתחרות המחוות, והמנצח נקבע לפי עדיפות. חשוב: flame ו-ScaleDetector מתנגשים אם PanDetector לא מוגדר על הווידג'ט האב.

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;
            // ... остальные состояния
        }
    }
}

מקרה בוחן: התקפות החלקה במשחק RPG

מהניסיון שלנו: בפרויקט אחד (RPG מלמעלה למטה, גרסת LTS עדכנית של Unity) היינו צריכים התקפות החלקה כיווניות עם שמונה כיוונים. נורמליזציה פשוטה של וקטור נתנה תוצאות לא יציבות—כיוונים אלכסוניים הופעלו פחות כי משתמשים ממעטים להחליק בדיוק ב-45°. פתרון: אזורי סובלנות של ±30° במקום ±22.5° הסטנדרטי, בתוספת שקלול לפי מהירות החלקה—החלקות מהירות פחות מדויקות, איטיות יותר מדויקות. לאחר מכן, שיעור הזיהוי הנכון עלה מ-78% ל-94%—GestureRecognizer מותאם אישית מספק שיפור דיוק של 16% לעומת ה-API המובנה (לפי Firebase Analytics). בנוסף, משוב חזותי דרך behavior: HitTestBehavior.opaque מצייר שובל דועך. בלעדיו, השחקן לא יודע שהמשחק רשם את המחווה שלו.

השוואת גישות במנועים פופולריים

מה כלול בעבודה?

• ארכיטקטורת מערכת מחוות: FSM לכל fingerId, GestureRecognizer מותאם אישית.
• אינטגרציה עם מכניקות משחק: קישור אירועים לאנימציות, ירי, תנועה.
• אופטימיזציה למכשירים חלשים: ספים, אנטי-throttling.
• משוב חזותי: שובלים, מחוונים, פעימות.
• בדיקות על צי של 50+ מכשירים אמיתיים (Android, iOS).
• תיעוד והדרכת צוות.

כיצד אנו מבטיחים תוצאות

אנו מבטיחים דיוק זיהוי מחוות של לפחות 90% במכשירים עם 30 FPS ומעלה. הניסיון שלנו מראה שמערכת מתוכננת כראוי מפחיתה תלונות משתמשים על בקרות בממוצע ב-60%. קבלו ייעוץ לפרויקט שלכם—צרו קשר, נעריך את המשימה ונציע את הפתרון האופטימלי.

לוחות זמנים ועלות

מערכת בסיסית (הקשה, החלקה, לחיצה ארוכה) לפלטפורמה אחת: 2–4 ימים. מערכת מלאה עם ריבוי מגעים, צביטה, מחוות מותאמות אישית ואינטגרציה עם מכניקות משחק: 1–2 שבועות. העלות מחושבת באופן אישי לאחר ניתוח דרישות הפרויקט.