אב-טיפוס ו-UX/UI למשחקים: ארכיטקטורה, ביצועים, לוקליזציה
אתה פותח פרויקט Unity של מישהו אחר — ורואה: Canvas אחד לכל המשחק, מאות פאנלים מקוננים, Layout Groups בתוך Layout Groups, והפרופיילר מראה 4 אלפיות שנייה רק על חישוב מחדש של UI בכל פריים. זה לא נדיר. עם ניסיון של למעלה מ-10 שנים, ניתחנו מאות מערכות UI — כמעט כולן סבלו מחוסר ארכיטקטורה מההתחלה. כתוצאה מכך, באמצע הפיתוח, ה-UI הופך לצוואר בקבוק: כל מסך חדש מכניס באגים, הביצועים צונחים, והתיקונים לוקחים שעות. אנו מתכננים ומיישמים UI למשחקים: מאב-טיפוס ועד רכיבי מנוע מוכנים, עם דגש על ביצועים ותחזוקה. גישת אב-הטיפוס שלנו לממשקי משחק מזהה 80% מבעיות ה-UX לפני כתיבת קוד. צור קשר לייעוץ — נעריך את הפרויקט שלך.
אב-טיפוס ועיצוב
כל UI מתחיל בהבנת זרימת מידע: מה השחקן צריך לראות בכל רגע, אילו פעולות זמינות, כיצד לנווט בין מסכים. ללא זה, הפיתוח הופך לסדרה של איטרציות "עשינו — טעינו — עשינו שוב". כלי אב-הטיפוס שלנו הוא Figma. הבחירה אינה על טרנדים אלא על יכולות ספציפיות:
- מערכת רכיבים עם וריאנטים — בדיקת מצבי כפתור (רגיל/ריחוף/לחוץ/מושבת)
- Auto Layout — סימולציה אמיתית של התנהגות UI בגדלי טקסט שונים (קריטי למשחקים רב-לשוניים)
- אבות-טיפוס עם מעברים — בדיקת זרימת ניווט לפני השורה הראשונה של קוד
בשלב אב-הטיפוס מתגלות רוב בעיות ה-UX: מעברים לא ברורים, מסכים עמוסים, היררכיית מידע שגויה. תיקונם ב-Figma לוקח 15 דקות. תיקונם בפרויקט מוגמר לוקח חצי יום. אנו מבטיחים שכל אב-טיפוס מלווה במפרט טכני למפתחים — זה מבטל אי-בהירות בעת ההעברה למנוע.
uGUI לעומת UI Toolkit: מה לבחור לפרויקט חדש
ל-Unity יש כיום שתי מסגרות UI, והבחירה ביניהן אינה מובנת מאליה. uGUI (מבוסס Canvas) היא מערכת בוגרת, קיימת מאז גרסאות מוקדמות של Unity. היא עובדת עם RectTransform ויש לה מערכת אקוסיסטם עשירה של נכסים. כמעט כל ה-UI הקיים במשחקים בנוי על uGUI.
UI Toolkit היא מערכת המבוססת על XML (UXML) וסגנונות דמויי CSS (USS). נוצרה במקור לכלי עריכה, והיא נתמכת רשמית ל-UI בזמן ריצה מאז Unity 2021. מבחינה ארכיטקטונית, היא קרובה יותר לפיתוח web.
UI Toolkit מתאימה לתרחישים הבאים:
- פרויקט חדש, צוות שמוכן ללמוד
- צורך במערכת ערכת נושא וסקין מורכבת
- פיתוח פעיל של כלי עריכה מותאמים אישית
uGUI נשארת עדיפה אם:
- תמיכה בפרויקט קיים
- צורך בתאימות מקסימלית לנכסי Asset Store
- הצוות כבר מכיר uGUI, לוחות זמנים צפופים
כיצד להשיג UI בעל ביצועים גבוהים ב-Unity?
כאן ה-UI של משחקים שונה באופן דרמטי מ-UI ביישומים רגילים. במשחקים, ה-UI מתעדכן בכל פריים, ויישום לא יעיל יכול לאכול 3–5 אלפיות שנייה מתקציב הפריים — מה שמשפיע ישירות על FPS.
כיצד פועל Batching ב-Canvas
Unity משלב אלמנטים של אותו Canvas לקריאת ציור אחת אם הם משתמשים באותו חומר ובאותו אטלס טקסטורות. שבירת ה-batch פירושה קריאת ציור נוספת, מה שפוגע בביצועים.
ה-batching נשבר על ידי:
- טקסטורות שונות על אלמנטים סמוכים (פתרון: אטלס ספרייטים באמצעות Sprite Atlas)
- רכיב Mask יוצר stencil ושובר את ה-batch (חלופה: RectMask2D — זול יותר)
- Canvases עם Render Modes שונים — batching עובד רק בתוך Canvas אחד
- כל Graphic Raycaster מוסיף תקורה — מקם אותו רק על Canvases אינטראקטיביים
פיצול Canvas לפי סוג תוכן
ההמלצה המרכזית: הפרד בין תוכן סטטי לדינמי. כאשר כל אלמנט ב-Canvas משתנה, Unity בונה מחדש את הגיאומטריה של כל ה-Canvas. אם מסגרת HUD סטטית ופס חיים מונפש חיים על אותו Canvas, ה-Canvas נבנה מחדש לחלוטין כל שנייה. זה יכול להפחית FPS ב-15–20%.
מבנה נכון:
Canvas (Screen Space - Overlay) ├── Canvas_Static — фоны, рамки, иконки без анимации ├── Canvas_Dynamic — HP-бары, таймеры, счётчик ресурсов └── Canvas_Popup — модальные окна, уведомления כל Canvas ילד מבודד את הבנייה מחדש מההורה. שינויים ב-Canvas_Dynamic אינם משפיעים על Canvas_Static.
הגדרה שלב אחר שלב ל-Canvases נפרדים:
- צור Canvas ראשי עם Render Mode = Screen Space Overlay
- בפנים, צור GameObjects ריקים, כל אחד עם רכיב Canvas
- תן להם שמות Static, Dynamic, Popup
- העבר אלמנטי UI קיימים לקבוצות המתאימות
- ודא שרכיב Canvas Scaler מוגדר רק על Canvas הראשי (ילדים יורשים הגדרות)
תוצאה: הפחתה של עד 60% בזמן צביעה מחדש של UI בסצנות עם HUD דינמי.
TextMeshPro ו-Batching של טקסט
TextMeshPro הוא התקן לטקסט ב-Unity. בניגוד ל-Text הישן, הוא משתמש בעיבוד SDF — טקסט נשאר חד בכל קנה מידה. עם זאת, ל-TMP יש ניואנס: כל אטלס גופן ייחודי הוא חומר נפרד, כלומר קריאת ציור נפרדת. אם המשחק משתמש בשלושה וריאנטים של גופן (ראשי, כותרת, מספרים) בתוספת גרסאות לכל שפה, ה-batching של הטקסט נשבר. פתרון: TMP Font Asset Creator עם מיזוג גליפים לשפות הנדרשות לאטלס אחד. עבור קירילית + לטינית + ספרות, אטלס אחד של 2048×2048 בדרך כלל מספיק — הפחתת קריאות ציור טקסט ל-1-2.
כיצד להתאים UI למסכים שונים?
פלטפורמות ניידות מוסיפות אתגר שאינו קיים במחשב: UI חייב לעבוד כראוי על יחסי 16:9, 18:9, 19.5:9, 4:3 ו-iPad בו-זמנית. שגיאות התאמה הן סיבה נפוצה לעבודה חוזרת, הצורכת עד 30% מהתקציב.
כלים:
- Canvas Scaler עם מצב Scale With Screen Size — הגדרה בסיסית. Reference Resolution 1080×1920 לנייד, פרמטר Match 0.5 (איזון בין רוחב לגובה)
- Anchor Presets — כל אלמנט חייב להיות מעוגן לקצה או למרכז הנכון
- Safe Area — במכשירים עם חריצים ופינות מעוגלות, כפתורים לא חייבים ליפול לאזור הלא נגיש. פתרון: Screen.safeArea בקוד, מתאים את ה-RectTransform של האלמנט הראשי
בדיקות צריכות להתבצע לא רק ב-Game View — יש צורך בבדיקה פיזית על מכשירים או באמצעות Device Simulator (מובנה ב-Unity). הזמן ביקורת UI — נזהה צווארי בקבוק תוך 2-3 ימים.
לוקליזציה של UI
זו אינה משימה נפרדת אלא דרישה מהיום הראשון. בעיה אופיינית: UI שתוכנן לטקסט רוסי התופס N תווים. התרגום לגרמנית ארוך פי אחד וחצי. כפתורים נשברים, טקסט עולה על גדותיו. בשלב העיצוב, אנו מבצעים:
- כל שדות הטקסט עם Auto Size ב-TMP או גדלים מינימליים/מקסימליים מוגדרים במפורש
- כפתורים עם Horizontal Layout Group + Content Size Fitter במקום רוחב קבוע
- אייקונים ואלמנטים דקורטיביים אינם משורשרים למחרוזות טקסט
ליישום, אנו משתמשים ב-Unity Localization Package (רשמי) או I2 Localization (נכס, גמיש יותר למקרים מורכבים). חיסכון בזמן על עבודה חוזרת בגישה זו — עד 40%.
מה נבדוק ב-UI שלך ביום אחד
- ניתוח Draw Call ו-Batching (באמצעות Frame Debugger)
- בנייה מחדש של Canvas (באמצעות Profiler, מציאת rebatches מיותרים)
- פעולת Raycaster (הסרת עודפים)
- רספונסיביות (Safe Area, Anchor Presets)
- לוקליזציה (בדיקה עם מחרוזות ארוכות במיוחד)
- איכות גופן (אטלסי TMP, שגיאות חפיפה)
מה כלול
- עיצוב מבנה ניווט וזרימת מסכים
- אב-טיפוס ממשק משחק ב-Figma עם העברה לפיתוח
- יישום רכיבי UI ב-Unity (uGUI או UI Toolkit)
- ביקורת ביצועים של UI קיים: Draw Calls, Canvas Rebatch, Raycasters עודפים
- הקמת מערכת לוקליזציה ובדיקה עם תרגומים ארוכים
- התאמה ליחסי מסך ניידים ו-Safe Area
לוחות זמנים: מ-5 ימי עבודה לביקורת ועד 4 שבועות למחזור מלא. התמחור מחושב באופן אישי — צור קשר להצעה מסחרית. למעלה מ-10 שנים בפיתוח משחקים, יותר מ-200 פרויקטים שנמסרו מבטיחים תוצאות.





