הדמות עוזבת את הקרקע חצי פריים לפני שנלחץ כפתור הקפיצה — והשחקן מרגיש זאת כבקרות 'עיסתיות'. כאן מתחילה העבודה שלנו: אנחנו לא בוחרים את Rigidbody.mass באקראי אלא מגדירים את התחושה באמצעות מספרים ספציפיים והחלטות ארכיטקטוניות. עם למעלה מ-10 שנות ניסיון בפיתוח משחקים, יישמנו מערכות תנועה ביותר מ-50 פרויקטים — מפלטפורמות מובייל ועד יריות קונסולה. צרו קשר — נגדיר בקרות מגיבות תוך 2–5 ימים.
למה CharacterController נכשל בפלטפורמות
Unity מציעה שתי דרכים: Rigidbody הפיזיקלי + collider ו-CharacterController הקינמטי. בפלטפורמות, Rigidbody הוא לרוב הבחירה הטובה יותר: הוא מספק פיזיקה מדויקת על פלטפורמות נעות, בעוד ש-CharacterController דורש טיפול ידני. עם Rigidbody, מקבלים פי שניים פחות באגים עם אובייקטים נעים.
CharacterController.Move() אינו מתקשר ישירות עם מנוע הפיזיקה — הדמות חותכת דרך פלטפורמות נעות אלא אם מיישמים מנגנון רכיבה מותאם אישית. דגל isGrounded הסטנדרטי מחזיר false בפריים אחד בעת ירידה במדרון — מה שגורם לדמות 'לקפץ' ללא סוף עקב כוח משיכה מצטבר במאגר המהירות האנכית.
דמות עם Rigidbody עמידה יותר לאינטראקציות פיזיקליות אך דורשת שליטה ידנית בחיכוך: ללא PhysicMaterial עם dynamicFriction אפס על הקפסולה, הדמות נתקעת בפינות גיאומטריה. בנוסף, Rigidbody.AddForce() ב-ForceMode.VelocityChange מתנהג בצורה צפויה רק עם fixedDeltaTime 0.02. אם משנים את צעד הפיזיקה, כל התחושה המכווננת 'נסחפת'. יש לנו סט מוכן של תצורות לז'אנרים שונים שמבטיח התנהגות יציבה בכל צעד קבוע.
איך אנחנו בונים ארכיטקטורת מערכת תנועה
מערכת תנועה מתוכננת היטב מפרידה בין שלושה תחומי אחריות: קלט, מצב ופיזיקה/תנועה. הקלט נקרא ב-Update() ונכתב למבנה MovementInput. מצבים (Idle, Running, Jumping, Falling, Crouching, WallRunning) מנוהלים על ידי מכונת מצבים — בדרך כלל מחלקה מותאמת אישית על גבי MonoBehaviour, לא Animator State Machine, כי לוגיקת המעברים היא לרוב לא לינארית וקשורה לתנאי משחק. שינוי המיקום בפועל מתרחש ב-FixedUpdate() דרך Rigidbody.MovePosition() או ישירות דרך velocity.
לפלטפורמות עם שליטה אווירית, airControlCurve הוא קריטי: תאוצה אופקית באוויר צריכה להיות פחותה מאשר על הקרקע, אבל לא אפס. מיושם דרך AnimationCurve בהגדרות דמות ב-ScriptableObject — מעצבים מכווננים את העקומה באינספקטור מבלי לגעת בקוד. אנחנו מבטיחים שהמעצבים שלכם יוכלו להתאים פרמטרים ללא מעורבות שלנו.
איך ליישם שליטה אווירית?
זמן קויוטי ו-buffering לקפיצה הם רכיבים חובה לבקרות מגיבות. זמן קויוטי מאפשר קפיצה בתוך coyoteTimeDuration (בדרך כלל 0.1–0.15 שניות) לאחר עזיבת פלטפורמה. Buffering לקפיצה שומר את לחיצת הקפיצה למשך jumpBufferDuration (0.1–0.2 שניות) ומבצע אותה בהזדמנות הראשונה. ללא שתי המכניקות הללו, שחקנים 'מפספסים' קפיצות באופן עקבי בקצוות פלטפורמות. גובה קפיצה משתנה הוא נקודה נוספת: אם כפתור הקפיצה משוחרר באמצע העלייה, המהירות האנכית נחתכת ל-minJumpVelocity. זה מיושם דרך בדיקה פשוטה ב-Update().
| פרמטר | ערך מומלץ | תיאור |
|---|---|---|
| זמן קויוטי | 0.1–0.15 שניות | מאגר לקפיצה לאחר עזיבת פלטפורמה |
| Buffering לקפיצה | 0.1–0.2 שניות | מאגר לקלט קפיצה לפני ביצוע |
| יחס שליטה אווירית | 0.3–0.5 | יחס התאוצה האופקית באוויר לעומת הקרקע |
| מהירות קפיצה מינימלית | 2–4 יחידות/שנייה | מהירות אנכית בעת שחרור הקפיצה |
מה כלול בעבודת מערכת תנועה
- ניתוח GDD והפניות — אנחנו מחלצים מספרים קונקרטיים (מהירות ריצה ביחידות/שנייה, גובה קפיצה, זמן dash).
- עיצוב MovementSettings ScriptableObject — כל הפרמטרים במקום אחד, נגיש למעצבים.
- אב טיפוס על פרימיטיבים — רק colliders ולוגיקה לכיוונון תחושה מהיר (1–2 ימים).
- אינטגרציה של Animator Controller — חיבור Blend Tree לתנועה ו-colliders סופיים.
- בדיקת מקרי קצה — קפיצה לרווח של יחידה אחת, פלטפורמות נעות עם סיבוב, מעבר בין משטחי NavMesh של סצנות שונות.
- תיעוד והדרכה — מסירה עם הערות והגדרות, הדגמה לצוות.
טבלת ציר זמן אינדיקטיבית
| היקף | תיאור | ציר זמן |
|---|---|---|
| בסיסי | דמות 2D/3D, קרקע, קפיצה, זמן קויוטי | 2–5 ימים |
| בינוני | + קפיצה כפולה, dash, קפיצת קיר, כריעה | 1–2 שבועות |
| מתקדם | + שחייה, טיפוס, מעבר ragdoll, פלטפורמות נעות | 2–4 שבועות |
| מערכת מלאה | + IK צעדים פרוצדורלי, הטיה, שכפול רשת | 4–8 שבועות |
תהליך עבודת הפרויקט
אנחנו מתחילים בניתוח ה-GDD שלכם ומשחקי ייחוס — אנחנו כותבים מספרים קונקרטיים מהמכניקות. לאחר מכן אנחנו מעצבים MovementSettings ScriptableObject עם כל הפרמטרים ו-PlayerMovement MonoBehaviour עם אזורי אחריות מתועדים.
אב הטיפוס בנוי על פרימיטיבים ללא אנימציות — רק colliders ולוגיקה. זה מאפשר לקבע את התחושה ביום או יומיים מבלי לבזבז זמן על אינטגרציית Animator. לאחר שהתחושה מאושרת, אנחנו מחברים את Animator Controller עם Blend Tree לתנועה ו-colliders סופיים המבוססים על גיאומטריית הרשת.
הבדיקות כוללות מקרי קצה: קפיצה לרווח של יחידה אחת, פלטפורמות נעות עם סיבוב, מעבר בין משטחי NavMesh של סצנות שונות תחת טעינה אדיטיבית. מצבים אלה חושפים לרוב בעיות בזיהוי קרקע והצטברות מהירות.
רשימת בדיקה של טעויות נפוצות בעיצוב תנועה
- חוסר זמן קויוטי — השחקן לא יכול לקפוץ מיד לאחר עזיבת פלטפורמה.
- אין buffering לקפיצה — קלטים 'נאכלים' אם הדמות לא על הקרקע.
- שימוש ב-isGrounded ללא SphereCast — false במדרונות, קפיצה אינסופית.
- סיבוב ידני עם NavMeshAgent.updateRotation — רעידות בסיבוב.
- fixedDeltaTime קבוע לכל הפלטפורמות — באנדרואיד ב-30 fps הפיזיקה 'נסחפת'.
- אין LayerMask על גלאי הקרקע — SphereCast פוגע ב-collider של הדמות.
הפתרון שלנו חוסך עד 40% מזמן הדיבוג, ומפחית את תקציב הפרויקט. הזמינו פיתוח מערכת תנועה — נבחר את הארכיטקטורה לפרויקט ולתקציב שלכם. נעריך צירי זמן לפי ה-GDD שלכם תוך יום עסקים אחד.