פיתוח Unity מקצועי: אופטימיזציה, מולטיפלייר, ECS

פיתוח משחקי Unity

אנחנו צוות מהנדסים עם 8 שנות ניסיון בפיתוח משחקים, לאחר שהשלמנו למעלה מ-20 פרויקטי Unity. הפרויקט שלך חצי גמור, אבל הסצנות לא נבנות ללא שגיאות קומפילציה, מטמון ה-AssetBundle תפח ל-4 GB, ובמכשירי Android יעד URP מרנדר ב-8 FPS במקום 30. נשמע מוכר? אנחנו יודעים לפתור את הבעיות האלה. המשימה שלנו היא להפוך כאוס לארכיטקטורה יציבה, לייעל ביצועים, ולהביא את הפרויקט להשקה. צור קשר כדי להעריך את הפרויקט שלך.

למה פיתוח משחקי Unity דורש ניסיון?

הבעיה הנפוצה ביותר היא ניהול מחזור חיים לא תקין של אובייקטים. MonoBehaviour.Update() על 400 אובייקטים פעילים, כל אחד קורא GetComponent<Rigidbody>() בכל פריים — זו לא ארכיטקטורה, זה אסון. על PC זה לא מורגש. על iOS A14 זה 12 ms תקורה רק על רפלקציה.

המלכודת הקלאסית השנייה היא AddressableAssets ללא אסטרטגיית פריקה. הפרויקט טוען מיקומים דרך Addressables.LoadAssetAsync אבל שוכח לקרוא ל-Addressables.Release(). אחרי שעת משחק, ה-RSS של התהליך גדל מ-800 MB ל-2.4 GB, ו-iOS הורגת את האפליקציה. זה לא באג של Unity — זה באג ארכיטקטוני.

הכאב השלישי הוא ערבוב לוגיקה בסצנות וב-ScriptableObjects. הצוות מתחיל עם סינגלטונים של MonoBehaviour, אחר כך עובר ל-EventSystem מבוסס ScriptableObject, אבל בסופו של דבר מערכת האירועים חיה בשלושה מקומות בו-זמנית. כל מפתח חדש מוסיף שכבה נוספת, ואחרי שישה חודשים אף אחד לא יודע מאיפה מגיע OnPlayerDied.

בעיה פחות ברורה אבל קבועה: Physics.Raycast ב-Update() ללא LayerMask. כל קריאה בודקת את כל הקולידרים בסצנה. עם 50 סוכנים וגיאומטריה מורכבת, זה 1-2 ms לכל פריים רק על פיזיקה.

איך אנחנו בונים פרויקטי Unity?

ארכיטקטורה וטכנולוגיות

הבסיס הוא הפרדה לשלוש שכבות: GameplayCore (לוגיקת C# טהורה ללא תלות ב-Unity API), UnityGlue (עטיפות MonoBehaviour), ו-Infrastructure (שירותים: שמירה, אנליטיקה, רשת). זה מאפשר לבדוק משחקיות ללא הפעלת העורך דרך NUnit + Unity Test Framework.

אנחנו בוחרים את צינור העיבוד (render pipeline) לפי הפלטפורמה:

אנחנו כותבים shaders דרך ShaderGraph כשנדרשת איטרציה ויזואלית עם האמן. אפקטים קריטיים לביצועים ברמה נמוכה נעשים ידנית ב-HLSL עם Custom Function Node. אנחנו משתמשים ב-Amplify Shader Editor רק אם הפרויקט כבר עליו.

איך להפחית Draw Calls?

בפרויקטים למובייל היעד הסטנדרטי הוא לא יותר מ-100-150 draw calls לפריים. מושג באמצעות:

• GPU Instancing על גיאומטריה חוזרת (עצים, אביזרים). MaterialPropertyBlock לנתונים לכל מופע מבלי לשבור את ה-batch.
• SRP Batcher — עובד אוטומטית עם URP, אבל דורש שכל ה-shaders יהיו תואמי SRP. חומר אחד לא תואם שובר את כל ה-batch. לפי תיעוד Unity, קונפיגורציה נכונה מפחיתה draw calls בעד 80%.
• Sprite Atlas ל-UI — קריטי. Canvas של UI במצב Overlay עם 60+ ספרייטים נפרדים מביא ל-60+ draw calls רק לממשק.
• Occlusion Culling לסצנות תלת-ממדיות — נאפה דרך Window → Rendering → Occlusion Culling. ברמות עם גיאומטריה אטומה, זה מפחית draw calls ב-40-60%.

אנחנו עושים profiling עם Unity Profiler + Frame Debugger + RenderDoc (לניתוח GPU מפורט). על Android בנוסף — Android GPU Inspector ל-Mali/Adreno.

ריבוי-תהליכים ו-ECS

לפרויקטים עם מספר גדול של סוכנים או סימולציות, אנחנו שוקלים DOTS (Unity ECS + Burst Compiler + Jobs System). Burst מהדר C# לקוד SIMD טבעי — במשימות כמו pathfinding ל-1000 סוכנים, ההבדל הוא 16 ms לעומת 0.8 ms על ה-thread הראשי. זה חוסך עד 40% מזמן האופטימיזציה.

לפרויקטים רגילים ללא DOTS — UniTask במקום coroutines. Coroutines רצות על ה-thread הראשי ולא מתבטלות נכון כשהאובייקט נהרס. UniTask עם CancellationToken פותר את שתי הבעיות.

Multiplayer

לזמן אמת: Photon Fusion 2 (server-authoritative, rollback netcode) או Mirror (self-hosted, קוד פתוח). הבחירה תלויה בדרישות השהיה ובתקציב התשתית. למשחקים מבוססי תורות ואינטראקציות אסינכרוניות — PlayFab CloudScript + Azure Functions.

שמירה וסנכרון ענן — Firebase Realtime Database למקרים פשוטים, PlayFab לקצה אחורי מלא של משחק (לוחות מובילים, matchmaking, כלכלה).

איך להבטיח איכות בפרויקט Unity?

תהליך עבודה

פרה-פרודקשן (1-2 שבועות). אנחנו מנתחים את הדרישות, קובעים פלטפורמות יעד ומגבלות טכניות. יוצרים vertical slice — מכניקה מינימלית שעובדת בבידוד. זה חשוב יותר ממסמך עיצוב מלא: עדיף להשקיע שבוע בפרוטוטייפ מאשר שלושה חודשים בפיתוח מכניקה שלא עובדת על החומרה המיועדת. ארכיטקטורה נכונה חוסכת עד 30% מתקציב הפיתוח.

פרודקשן. ספרינטים של 1-2 שבועות. כל ספרינט מסתיים ב-build עובד. אנחנו משתמשים ב-Git עם LFS לנכסים, Jira או Linear למשימות. בדיקת קוד היא חובה — במיוחד במערכות שמשפיעות על מספר סצנות.

בדיקות. בדיקות יחידה על לוגיקת משחקיות (Unity Test Framework, Play Mode). בדיקות אינטגרציה דרך Playwright ל-WebGL. בדיקות ידניות על מכשירים אמיתיים — סימולטור iOS לא משחזר צריכת זיכרון אמיתית.

השקה. Builds אוטומטיים דרך Unity Cloud Build או GitHub Actions עם fastlane ל-iOS. Android — Google Play Internal Testing, iOS — TestFlight.

מה כלול

• ניתוח הפרויקט הנוכחי והגדרת משימות
• עיצוב ארכיטקטוני ובדיקות benchmark
• פיתוח משחקיות ומערכות (UI, רשת, אנליטיקה)
• בדיקת קוד ואופטימיזציית ביצועים
• תיעוד קוד וארכיטקטורה
• חודש תמיכה לאחר השקה

לוחות זמנים לפי סוג פרויקט

העלות מחושבת בנפרד לאחר ניתוח המפרט הטכני ופלטפורמות היעד. צור קשר כדי להעריך את הפרויקט שלך.

טעויות נפוצות בהשקת פרויקט Unity?

• התעלמות מה-Profiler עד לשלב הליטוש. "נגרום לזה לעבוד קודם, נבצע אופטימיזציה אחר כך" עובד עד שמגלים שהחלטה ארכיטקטונית שהתקבלה בחודש הראשון לא ניתנת לאופטימיזציה בלי לשכתב חצי מהמשחק.
• אחסון כל הנכסים בתיקיית Resources/. תיקיית Resources נטענת כולה לזיכרון בעת הפעלת האפליקציה. 500 MB של טקסטורות ב-Resources משמעותם 500 MB RAM לפני אפילו טעינת הסצנה הראשונה. Addressables פותרים את זה אבל דורשים תכנון מההתחלה.
• Canvas אחד ענק לכל ה-UI. Unity מציירת מחדש את כל ה-Canvas כשכל רכיב ילד משתנה. חלקו את ה-UI לרכיבי Canvas סטטיים ודינמיים.
• פיזיקה על triggers במקום חישובים. OnTriggerEnter אמין במהירויות נמוכות. קליע שנע ב-200 יחידות/שנייה עובר דרך קולידרים דקים בין פריימים. למקרים כאלה, צריך Physics.SphereCast או Rigidbody עם Continuous Collision Detection.

אנחנו בודקים מדדי E-A-T: אנחנו מבטיחים את האיכות של כל פרויקט ומספקים תמיכה לאחר השקה. הזמינו ייעוץ לפרויקט שלכם.