תחילת העבודה עם פיתוח משחקים ב-Unity

במדריך הזה מתואר מחזור פיתוח משחקים טיפוסי. אחרי שתקראו את המדריך הזה, תוכלו להשתמש בו גם כחומר עזר.

כשעובדים עם Unity, מחזור החיים של הפיתוח מורכב משלושה שלבים:

• תכנון ועיצוב
• פיתוח ובדיקה
• פרסום ותחזוקה

תכנון ועיצוב

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

קבלת משוב מכל חברי הצוות

עובדים עם צוותי האומנות, ההנדסה, העיצוב, האודיו וההפקה כדי לזהות ולתעד משימות הטמעה. לדוגמה:

• צוותי הארט עשויים ליצור תקציבים של טקסטורות ורשתות של נכסים עבור דמויות וסביבות.
• צוות ההנדסה עשוי לקבוע נקודות ביקורת של זיכרון וביצועים לצורך יצירת פרופיל בהשוואה לכל פלטפורמה.
• צוות העיצוב יכול לתכנן את מכניקת המשחק שתאפשר את החוויה.
• מומחי אודיו עשויים לבדוק את הדרישות להמשכיות הצליל בין ממשק המשתמש, צלילים מרחביים דו-ממדיים ותלת-ממדיים.
• צוות ההפקה יכול להעביר את הדרישות להשקה ולדאוג שהצוות יפעל בהתאם לתוכנית.

עיצוב לנייד

פיתוח אפליקציות לפלטפורמות לנייד כולל שיקולים ספציפיים, כמו:

• יחסי גובה-רוחב משתנים של המסך
• צריכת חשמל
• ויסות נתונים (throttle) של מעבד (CPU) ושל טמפרטורה
• קלט מגע
• פיתוח חוצה פלטפורמות
• ממשקי API גרפיים (Vulkan או OpenGL ES)

פרטים על שיקולים ייחודיים לעיצוב לנייד זמינים במאמר פיתוח ל-Android ב-Unity של Unity ובאקדמיית Google Play.

פיתוח ובדיקה

בשלב הפיתוח והבדיקה, אתם מפתחים את המשחק ומבצעים בדיקות והכנות לפני ההשקה. אתם מבצעים בדיקות פנימיות מוגבלות ב-Google Play כדי להתכונן לדרישות ההשקה. משפרים את אסטרטגיית הפריסה ומארגנים את הנכסים ב-Unity על סמך המערכות Play Asset Delivery ו-Addressables של Unity.

בקטעים הבאים מתוארים כלים וטכניקות של Unity שנועדו לעזור לכם לפתח לאנדרואיד.

עיבוד

עיבוד הוא התהליך של ציור הנכסים בתלת-ממד ובדו-ממד מהסצנה של Unity על המסך. מנוע Unity מטפל ברינדור, אבל חשוב לקחת בחשבון כמה גורמים בפלטפורמת Android.

מרקמים

קובעים אם אתם צריכים את הגדלים הכי גדולים של הטקסטורות, על סמך מכשירי היעד. כשמבצעים פרופיל של הקצאת זיכרון, כדאי לבדוק את החיסכון הפוטנציאלי שאפשר להשיג באמצעות שינוי של גודל טקסטורת היעד.

זמן רינדור פריים

כדי למנוע התחממות יתר במכשירי Android, כדאי להגדיר ערכי זמן יעד של פחות מ-21 מילי-שניות בממוצע. לפעמים, למשל בזמן טעינה או במהלך סצנות קצרות, זמני הפריימים יכולים להיות מעל 21 מילישניות, אבל חשוב לשמור על זמני פריימים מתחת לסף של 21 מילישניות במהלך חוויית המשחק העיקרית.

בפלטפורמות לנייד, אם לא מגיעים ליעד המינימלי, VSync מאולץ מצמצם את קצב הפריימים. לדוגמה, אם קצב הרענון של המסך הוא 60Hz, והמשחק לא מגיע ל-60fps, הוא מוגבל ל-30fps. אם הוא לא מגיע ל-30fps, הוא מוגבל ל-15fps.

במכשירי Android רבים, קצב הרענון של המסך הוא 60Hz ו-120Hz. כדאי לשקול את היתרונות של טירגוט זמני פריימים קצרים בהרבה (יעד של 10ms לעדכון של 60Hz ו-5ms לעדכון של 120Hz) בלי להסתכן בהגבלת מהירות המעבד עקב התחממות יתר ובריקון הסוללה בגלל שיעורי רינדור גבוהים יותר.

כדי להגדיר קצב פריימים ספציפי במשחק ב-Unity, משתמשים ב-Application.targetFrameRate.

‫Frame Pacing library (ספריית קצב הפריימים) של Android עוזרת לכם לבצע רינדור בצורה חלקה כשהאפליקציה שלכם צריכה יותר זמן כדי להציג את הפריים הבא מהזמן שנדרש לפי קצב הרענון של המסך. בגרסאות Unity 2021 ואילך, הפעלת האפשרות Android frame pacing מגדירה את קצב הרענון של התצוגה להתאמה הטובה ביותר לקצב הפריימים הרצוי. כך אפשר לוודא שהמשחק לא יבזבז את הסוללה על עדכוני תצוגה מיותרים.

כדי להפעיל את הספרייה, בProject Settings (הגדרות הפרויקט) > Player (נגן), בקטע Settings for Android (הגדרות ל-Android), מסמנים את תיבת הסימון Optimized Frame Pacing (קצב פריימים אופטימלי).

Vulkan API

‫Vulkan הוא ממשק API לגרפיקה בתלת-ממד שפועל במספר פלטפורמות, עם ביצועים גבוהים ותקורה נמוכה בהשוואה ל-OpenGL ES. אפשר להשתמש ב-Vulkan ב-Unity בשתי דרכים שונות.

Auto Graphics API

אפשר להשתמש ב-Auto Graphics API עם Vulkan, אבל יכולות להיות התנהגויות שונות בהתאם לגרסת Unity שמותקנת. כדי לבחור את האפשרות הזו, עוברים אל Project Settings > Player > Rendering (הגדרות פרויקט > נגן > עיבוד).

כשבוחרים את הגרסה של Unity שבה רוצים להשתמש, חשוב לקחת בחשבון את הנקודות הבאות:

• גרסה Unity 2021.1 וגרסאות קודמות לא תומכות ב-Vulkan עם Auto Graphics API. מערכת Unity מנסה להשתמש ב-OpenGL ES 3.2. אם המכשיר לא תומך ב-OpenGL ES 3.2,‏ Unity חוזרת ל-OpenGL ES 3.1,‏ 3.0 או 2.0, לפי הסדר הזה.
• ב-Unity 2021.2 ובגרסאות מאוחרות יותר נעשה שימוש קודם ב-Vulkan. אם המכשיר לא תומך ב-Vulkan,‏ Unity חוזרת ל-OpenGL ES 3.2,‏ 3.1,‏ 3.0 או 2.0.

ממשקי API לגרפיקה ידנית

לחלופין, אפשר להשבית את Auto Graphics API כדי להפעיל את Vulkan באופן ידני. אם אתם משתמשים ב-Unity 2021.1 או בגרסה קודמת, זו הדרך היחידה להשתמש ב-Vulkan.

אם Vulkan מופיע במקום גבוה יותר ברשימה הזו מ-OpenGL ES, ‏ Unity מנסה קודם להשתמש ב-Vulkan. אם המכשיר לא תומך ב-Vulkan, ‏ Unity פועלת עם OpenGL ES. במאמר תחילת העבודה עם Vulkan מפורט מידע על Vulkan ב-Android, כולל הסבר על השימוש בממשקי API מודרניים של גרפיקה ועל אופטימיזציה של הביצועים במשחק.

בקשות להזזת פריט גרפי (draw calls)

כל מה שמוצג במסך משויך לקריאה אחת או יותר לציור. בפלטפורמות לנייד, כדאי לבצע אופטימיזציה ולהפחית את מספר קריאות הציור שאתם שולחים למעבד הגרפי (GPU).

אפשר לחשוב על קריאות ציור כעל מכוניות שממתינות ברמזור. אחרי שהאור הופך לירוק, מספר מסוים של מכוניות יכולות לעבור לפני שהאור משתנה. כשהאור הופך לצהוב, הגעתם לזמן האידיאלי של מסגרת היעד (21 אלפיות השנייה), וכשהאור הופך לאדום, הגעתם למגבלת הזמן של המסגרת (33 אלפיות השנייה). כל מה שמעבר לכך משפיע על פריימים של רינדור הבא, ולכן קצב הפריימים שמתקבל נמוך מ-30‎ FPS היעד.

כדי לקבל מידע על שיפור הביצועים של קריאות הציור במשחק, אפשר לעיין במאמר בנושא batching מתוך התמיכה של Unity.

אזורים כהים

קריאות ציור של הטלת צללים יכולות להיות הכי אינטנסיביות מבחינת השימוש ב-GPU, ולצרוך את רוב הזמן של ה-GPU גם בסביבות פשוטות. כדי להפחית את העלות של קריאות הציור של הטלת צללים, כדאי להתנסות בשימוש בצללים חדים במקום בצללים רכים. אם העלות עדיין גבוהה מדי ב-GPU במכשירים ברמת כניסה, כדאי להשתמש בצללי כתמים במקום בצללים חדים.

מרקם

פורמט הדחיסה המומלץ של טקסטורות RGB ו-RGBA ב-Android הוא ASTC. ב-Unity, האפשרות המינימלית לדחיסת טקסטורה שצריך להשתמש בה ב-Android היא ETC2. אפשר לחזור ל-ETC2 כגיבוי מ-ASTC בקטע Unity Build Settings.

רשימה מלאה של הפורמטים הנתמכים לפי פלטפורמה זמינה במסמכי Unity במאמר Manual: Recommended, default, and supported texture formats, by platform.

ממשק משתמש ויחסי גובה-רוחב

אתם יכולים להשתמש בכלי Device Simulator של Unity כדי לראות תצוגה מקדימה של רזולוציות מסך, אוריינטציות ויחסי גובה-רוחב שונים של מכשירים ישירות ב-Unity Editor. אפשר לעבור בין תצוגת המשחק לבין תצוגת סימולטור המכשיר.

אפשר לראות תצוגה מקדימה של הכלי במאמר סימולציה של המשחק באמצעות סימולטור המכשירים ב-Unity!.

אפשר למצוא את קוד המקור של Trivial Kart במאגר games-samples ב-GitHub.

כדי לבדוק במהירות את הפריסה והנכונות של רכיבי אזור העריכה של ממשק המשתמש בתצוגת סימולטור המכשיר, בוחרים באפשרויות המכשיר בתפריט הנפתח:

למידע נוסף על טכניקות אופטימיזציה של ממשק המשתמש ב-Unity, אפשר לעיין במדריך הבא של Unity: אופטימיזציה של ממשק המשתמש ב-Unity.

פיזיקה

מנוע Nvidia PhysX מובנה ב-Unity. הגדרות ברירת המחדל עלולות להיות יקרות בנייד, לכן חשוב לזכור את הנקודות הבאות:

• כדאי לקחת בחשבון את יעד קצב הפריימים ולהגדיר את צעד הזמן הקבוע בהתאם. ערך ברירת המחדל הוא 0.02ms או 50Hz. אפשר להגדיל את הערך ל-0.03 או יותר אם היעד הוא 30fps.
• כדאי לפשט את רכיבי ה-Collider של הרשת ולצמצם את מטריצת ההתנגשויות של השכבות כדי לקבוע אינטראקציות בין אובייקטים של משחק מסוגים ספציפיים של שכבות.

מידע על הגדרות פיזיקה ואופטימיזציות למשחקים לנייד זמין בספר האלקטרוני Optimize Your Mobile Games של Unity.

פרופיל

מפתחי אפליקציות מתעלמים לעיתים קרובות מפרופילים או לא מייחסים להם חשיבות עד שהאפליקציה מגיעה לנקודת כשל קריטית. מומלץ להקצות זמן ייעודי ליצירת פרופיל בתהליך שלכם, ולפעול לפי השיטות המומלצות הבאות:

• לזהות נקודות מרכזיות במהלך הפיתוח שבהן אפשר להקצות זמן ליצירת פרופיל, במקום להקצות זמן באופן אקראי.
• שמירת תמונות מצב של הפרופיל לשימוש בכלי לניתוח פרופילים של Unity.
• כדאי ליצור פרופיל של המשחק במכשירי היעד כדי לקבל תמונה מדויקת של הביצועים שלו בשלב הנוכחי של הפיתוח.
• ליצור פרופילים לחלקים שונים במשחק.
• ליצור פרופיל של אופן המשחק של השחקנים. (אל תבצעו פרופיל של המשחק רק כשהוא במצב לא פעיל או במסך ההשהיה).
• פרופיל במצב ממושך אחרי שהמשחק פועל במשך זמן מה, כדי לעזור לכם למצוא בעיות של הגבלת רוחב פס שאתם עלולים להיתקל בהן כשמכשירי הנייד מתחממים.

אפשר להשתמש בכלים הבאים ליצירת פרופילים בנפרד או בשילוב.

• ‫Unity Profiler הוא כלי משולב לחלוטין לניתוח ביצועים, שיכול לפעול מול הקוד שלכם ב-Unity Editor ולהתחבר למכשיר Android עצמאי שבו פועלות גרסאות build במצב פיתוח.

• ‫Android GPU Inspector בעזרת הכלי Android GPU Inspector‏ (AGI) אפשר לבצע ניפוי באגים ברמת הפריים. בנוסף, ה-AGI מנתח את שירותי המערכת, כולל GPU, מעבד, זיכרון, סוללה ומונים של GPU.

לפרטים על יצירת פרופיל של המשחק ב-Unity, אפשר לצפות בסרטון Introduction to profiling in Unity או לקרוא את המאמר Ultimate guide to profiling Unity games, שניהם מ-Unity.

ניהול זיכרון

תהליכי Android חולקים את הזיכרון הזמין במכשיר היעד. מומלץ ליצור פרופיל של השימוש בזיכרון כשבמכשיר הבדיקה יש מספיק משאבי זיכרון פנויים. כדאי לבצע בדיקות זיכרון בנקודה עקבית במשחק כדי שתוכלו להשוות בין סשנים ומגמות של שימוש בזיכרון בצורה מתאימה.

כשעובדים בסקריפטים שנכתבו ב-C#, צריך להיזהר בשימוש במחרוזות, בהשוואות בין מחרוזות ובהקצאות של אובייקטים שקשורים למחרוזות (כמו קובצי JSON להגדרות משחק). הן יוצרות הקצאות זיכרון תכופות ויכולות לתרום לפיצול.

מומלץ להשתמש במחלקה StringBuilder לרצפים ארוכים של מניפולציות על מחרוזות, במקום בשרשור מחרוזות במקום (כמו ‎ "this" + "is" + "a" + "bad" + "idea" לעומת קריאות לפונקציה StringBuilder.Concat()).

מידע נוסף על מחרוזות זמין במאמר מחרוזות וטקסט במסמכי התיעוד של Unity.

הערכת משאבי טקסט מסוג TextAsset ו-JSON בהשוואה לסוג המועדף ScriptableObject. ‫ScriptableObjects לטפל באחסון נתונים בין סצנות בצורה יעילה ולאפשר שינויים בזמן ההפעלה של Editor-to-Play.

במאמר The hidden optimization in network games באתר Hutch מוסבר איך להשתמש בחלופות לטיפול ב-JSON שמוגדר כברירת מחדל כדי לבצע אופטימיזציה לנייד.

אפשר להשתמש ב-Memory Advice API כדי לקבוע מהו השימוש בזיכרון בזמן הריצה. ממשק ה-API חושף אינדיקטור של רמזור לשימוש גבוה, רגיל ונמוך בזיכרון. אתם יכולים להירשם לקבלת עדכונים לגבי האינדיקטור או לבדוק ישירות את הסטטוס הנוכחי שלו. אם מקבלים אות אדום, כדאי לצמצם את מאגר האובייקטים או את המטמון של המשחק. חשוב לכלול את ההקשר הזה בטלמטריה של המשחק במהלך פעולות בזמן אמת ובבדיקה של מדדי הביצועים אחרי ההשקה.

כדי להבין לעומק את ארגון הזיכרון במכשירי Android ואת אופן הפעולה של Unity, אפשר לצפות בסרטון Understanding Android memory usage (from Google I/O '18). בסרטון מוסבר על סוגי בעיות הזיכרון ועל המקרים שבהם מופעלת התכונה 'השבתת תהליכים בגלל זיכרון נמוך'.

איסוף אשפה

איסוף אשפה בסביבת זיכרון מנוהלת מנקה את חלקי הזיכרון שלא נמצאים בשימוש, שאפשר למחזר עבור אפליקציה. כדי להימנע מהקצאות מיותרות של משאבי זיכרון, חשוב לפעול לפי השיטות המומלצות בנושא איסוף אשפה.

לדוגמה, כדאי ליצור מאגר של אובייקטים במשחק במקום להשתמש בהקצאות לפי דרישה (GameObject.Instantiate). במאגרים גדולים, כדאי להקצות אובייקטים על פני כמה פריימים כדי להקטין את הסיכון שהמשחק לא יגיב במכשירי Android ברמת הכניסה.

כדאי לעיין בקטע הקוד הבא של קורוטינה פשוטה שמופעלת מתחילת MonoBehaviour:

// Option 1: Bad for memory management - causes allocation each iteration
IEnumerator UpdateEnemyTarget() {
  while (enabled) {
    yield return new WaitForSeconds(1.0f);
    // Some intermittent function check
  }
}

// Option 2: Better for memory management - allocation of yield instruction once, reused each iteration
private YieldInstruction waitForSecond = new WaitForSeconds(1.0f);
IEnumerator BetterUpdateEnemyTarget() {
  while (enabled) {
    yield return waitForSecond;
    // Some other intermittent function
  }
}

אתם יכולים לערוך את קובץ התבנית MonoBehaviour כדי להסיר את פונקציות ה-stub של Start() ו-Update() שמוגדרות כברירת מחדל, וכך לא להשאיר בטעות פונקציות ריקות במהלך הפיתוח.

סקירה כללית על סדר הביצוע של אירועי MonoBehaviour זמינה במאמר סדר הביצוע של פונקציות אירועים במסמכי התיעוד של Unity. מידע נוסף על ניהול זיכרון זמין בקורס Memory Management in Unity.

לקבלת טיפים לאופטימיזציה של ביצועי משחקים לנייד, אפשר לעיין במאמר אופטימיזציה של ביצועי משחקים לנייד: טיפים בנושא פרופילים, זיכרון וארכיטקטורת קוד ממהנדסים מובילים של Unity.

איגום של מבנים טרומיים

העלייה הפתאומית בזמן הפריימים של המעבד נגרמת כמעט באופן בלעדי מהפעלת מופע של Prefab במהלך המשחק. כדאי לשקול חימום מראש של מאגרי אובייקטים של קליעים, אויבים שניתן להזעיק ואפקטים חזותיים לפני שמתחילים לשחק, כדי לצמצם או לבטל את העליות החדות בשימוש במעבד בזמן ההפעלה. אפשר לפרוס אופטימיזציות נוספות על פני כמה 'מסגרות אתחול' במהלך הטעינה או רצפי הפתיחה בסצנה.

ב-Unity Asset Store אפשר למצוא הרבה נכסי צד שלישי שקשורים לניהול של איגום אובייקטים במשחק. תוכלו גם ליצור רשימה כזו משלכם. אפשר לעיין במאמר מבוא למאגר אובייקטים ב-Unity Learn.

העברת נכסים

יש מגבלות על הגודל של האפליקציה כשמפרסמים אותה לראשונה ב-Google Play. בהתאם לגודל ולסוג המשחק, יכול להיות שתצטרכו חלק ממשאבי המשחק (מודלים של דמויות, סביבות, רכיבי ממשק משתמש וכו') או את כולם כדי שהשחקנים יוכלו ליהנות מהחוויה שרציתם ליצור.

אתם יכולים להשתמש בשירות Play Asset Delivery (PAD) כדי לנהל נכסים שהמשחק שלכם צריך בזמן ההתקנה, בשיטת fast follow או על פי דרישה. קובצי Unity Asset Bundle משולבים כדי לתמוך ב-PAD, ואפשר להשתמש בכלי כדי לציין אילו רכיבים מועברים.

כתובות שאפשר לשלוח אליהן

הגדרה של משאבים דינמיים – כמו prefabs, טקסטורות וקבצי קול – בזמן ריצה היא כבר לא פעולה מורכבת אם מכינים את מערכת השמות של Addressables ובודקים אותה. נכסים שניתן להתייחס אליהם מאפשרים להפריד בין האופן שבו מארגנים את התוכן לבין האופן שבו בונים וטוענים את התוכן. מערכת Addressables מחליפה את התיקיות Resources ואת Asset Bundles, כדי לפשט את האופן שבו מפנים לנכסים וטוענים אותם בזמן ריצה.

לדוגמה, אפשר לעיין בפרויקט ההדגמה באמצעות חבילת Addressables ב-GitHub. פרטים על הפיתוח של Addressables מופיעים במאמר בנושא Addressable Asset System בבלוג של Unity.

כשמשתמשים בפריסת נכסים שניתן להתייחס אליהם, יש יתרונות וחסרונות לאיגוד של מעט מדי נכסים או של יותר מדי נכסים בחבילות משותפות. מידע נוסף על ניהול תוכן באמצעות Addressables זמין במאמר איך מפשטים את ניהול התוכן באמצעות Addressables.

אתם יכולים להגדיר הדגמה עצמאית ולהתנסות במצבי הגישה כדי להכיר את מערכת Addressables. אפשר גם לעיין בפרויקט הקוד הפתוח BuildLayout Explorer for Unity 2019.3 and newer ולבדוק את הדוח buildlayout.txt שנוצר על ידי Addressables.

הנכסים של Chop Chop, פרויקט Unity Open, נארזו באמצעות מערכת Addressables לכל הפעולות של טעינה ופריקה. במאמר Packaging content with Addressable Assets | Open Projects Devlog יש הסבר מפורט על המבנה וההגדרה של חבילות Addressables.

בפרויקט Chop Chop, הסצנה היחידה שנטענת כברירת מחדל, סצנת האתחול, הוגדרה להשתמש ב-AssetReferences במקום בקישורים ישירים לנכסים בפרויקט (סצנות, prefabs וכו').

קוד המקור של פרויקט Unity הפתוח: Chop Chop זמין ב-GitHub. למרות שהפרויקט כבר לא בפיתוח, מאגר ה-Git והתיעוד שלו עדיין זמינים.

תוספים של צד שלישי

אם אתם משתמשים בתוספים של צד שלישי, כמו אלה שב-Unity Asset Store, הקפידו לבדוק את התיקיות ולהסיר נכסים מיותרים מתיקיות Resources. במהלך תהליך הבנייה, Unity אוספת את כל הנכסים שנכללים בתיקיות Resources ואורזת אותם בחבילה אחת שאפשר לגשת אליה בזמן הריצה. הפעולה הזו עלולה להגדיל את החבילה הסופית, ולרוב היא לא נדרשת.

כדי לאתר במהירות את כל תיקיות המשאבים, מחפשים את Resources בחלונית Project. אחרי זה תוכלו לבחור כל אחד מהם כדי לזהות את התוכן שלו ולקבוע אם הוא נחוץ למשחק.

פרסום ותחזוקה

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

ניתוח משוב מגרסה מוגבלת

אתם יכולים להשיק את המשחק לקהל יעד מוגבל ולבצע בדיקות בטא בקנה מידה גדול יותר, או להפעיל את המשחק כך שיהיה זמין באופן מלא בכל השווקים. במהלך הפצה מוגבלת, אתם יכולים לשפר את ביצועי האפליקציה על סמך קהל רחב יותר של משתמשים פעילים ומגוון רחב יותר של מכשירים.

לדוגמה, אפשר להשתמש ב-Android Performance Tuner for Unity וב-Google Analytics for Unity כדי לקבל תובנות לגבי ביצועי האפליקציה ומגמות בקרב השחקנים, שצוות הפיתוח יכול להשתמש בהן כדי לבצע שינויים ולפרסם עדכונים. אפשר גם להשתמש בנתוני הניתוח כדי לתכנן משחקי המשך או משחקים קשורים בז'אנר דומה.

בדיקות אלפא ובטא

אחרי שמגדירים את פרופיל האפליקציה ב-Google Play Console, אפשר להכין גרסאות אלפא ובטא ציבוריות לבדיקה ולהפיץ אותן לקהל מוגבל לצורך בדיקה לפני ההשקה. השקה לקהל מוגבל מאפשרת לכם לפתור בעיות סופיות במאגר גדול יותר של מכשירים, ולאסוף משוב ראשוני שתוכלו להגיב עליו לפני שתשיקו את האפליקציה לכל העולם.

הגרסאות של Unity מופצות דרך קובצי Android App Bundle. מידע נוסף זמין במאמר Manual: Delivering to Google Play של Unity, שמתואר בו גם המעבר מקובצי APK לפורמט AAB.

מעקב וניטור

במהלך שלב ההפעלה וההפצה של המשחק, אפשר להשתמש ב-Android Vitals כדי לעקוב אחרי בעיות בביצועים במכשירים שאולי לא הייתה לך גישה אליהם במהלך הפיתוח והבדיקה. פרטים נוספים זמינים בסרטון What's new for games in Reach and devices and Android vitals.

לרוב, לצוותי פיתוח גדולים יותר יש צינורות ייחודיים ומותאמים אישית של טלמטריה של משחקים, שמספקים מדדים שקשורים לביצועי המכשיר. כדאי להשתמש ב-Android Performance Tuner (APT) ובתוסף Unity המתאים כדי לכוונן מדדים שקשורים לקצב הפריימים, לאיכות הגרפית, לזמן הטעינה ולנטישה בזמן הטעינה. פועלים לפי המדריך המפורט בנושא שילוב של Android Performance Tuner במשחק Unity.

מחזור החיים של המשחק לא מסתיים אחרי שמתחילים לשדר אותו. מעקב אחרי הביצועים והמשוב, שמירה על רמה גבוהה שלהם ומענה למשוב הם קריטיים כדי שהמשתמשים יהיו מרוצים, כדי לקבל ביקורות חיוביות וכדי שהמשחק יזכה להצלחה בכל השווקים.