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

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

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

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

תכנון ועיצוב

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

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

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

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

עיצוב לנייד

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

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

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

פיתוח ובדיקה

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

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

רינדור

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

מרקמים

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

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

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

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

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

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

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

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

תיבת דו-שיח שמציגה את הגדרות הפרויקט > הגדרות הנגן > אופטימיזציה לקצב תהילה
איור 1. קצב פריימים שעבר אופטימיזציה זמין בקטע הגדרות נגן ב-Unity מגרסה 2019.2 ואילך.

ממשק API של Vulkan

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

Auto Graphics API

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

כשבוחרים את גרסת Unity, חשוב לזכור את השיקולים הבאים להשתמש ב:

  • Unity 2021.1 וגרסאות קודמות לא תומכות ב-Vulkan עם Auto ממשק 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.
הגדרות הפרויקט > הגדרות הנגן > רינדור > Auto Graphics API
איור 2. ההגדרה Auto Graphics API.

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

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

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

הגדרות הפרויקט > הגדרות הנגן > רינדור > ממשקי API לגרפיקה
איור 3. הגדרה ידנית של ממשקי API גרפיים כש-Auto Graphics API מושבתת. Vulkan היא האפשרות הראשונה. ב-Unity אפשר להשתמש ב-OpenGL ES 3.0.

משיכת שיחות

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

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

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

אזורים כהים

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

מרקם

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

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

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

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

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

איור 4. סימולטור המכשירים שמריץ את Trivial Kart.

אפשר למצוא את קוד המקור של Trivial Kart משחקים לדוגמה ב-GitHub.

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

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

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

פיזיקה

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

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

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

פרופיל

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

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

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

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

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

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

ניהול הזיכרון

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

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

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

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

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

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

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

הבנה מעמיקה יותר של ארגון הזיכרון במכשירי Android וכיצד Unity עובד איתו, תוכלו לצפות הסבר על השימוש בזיכרון ב-Android (מ-Google I/O 2018) הסרטון מסביר את סוגי בעיות הזיכרון ומתי אין מספיק זיכרון נכנס לתוקף.

איסוף אשפה

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

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

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

// 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 כדי להסיר את ברירת המחדל, Start() פונקציות stub של Update() כדי לא להשאיר ריק בטעות יפעלו במהלך ההתפתחות.

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

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

מאגר טרום

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

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

העברת נכסים

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

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

כתובות URL

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

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

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

אפשר להגדיר ולהתנסות במצבי הגישה כדי לקבל נוח למערכת עם כתובות ה-URL. אפשר גם לראות את פרויקט הקוד הפתוח BuildLayout Explorer ל-Unity 2019.3 ואילך, ולבדוק את דוח buildlayout.txt שנוצר על ידי ניתנים לכתובות.

הנכסים של Chop Chop, פרויקט של Unity Open, נארזו באמצעות הפונקציה מערכת ניתנת לכתובות לכל סוגי הטעינה והפריקה. צפייה אריזת תוכן באמצעות נכסים שניתן לטפל בהם | פתיחת Projects Devlog לקבלת הדרכה מפורטת לגבי המבנה והגדרה של כתובות ה-URL חבילות.

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

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

יישומי פלאגין של צד שלישי

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

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

איור 7. יכול להיות שיש כמה תיקיות של משאבים אורב בתיקיות שהורדתם מ-Unity Asset Store. אפשר למחוק אותם עד ולא לכלול אותם בחבילת האפליקציות שלכם.

פרסום ותחזוק

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

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

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

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

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

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

גרסאות ה-build שלך של Unity מופצות באמצעות קובצי Android App Bundle. לקבלת מידע, לראות את ידני: משלוח ל-Google Play מ-Unity, שמתאר גם את השינויים מקובצי APK ל-AAB הפורמט.

מעקב ומעקב

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

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

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