פיתוח משחק תלת-ממד למובייל: מחזור מלא מאב-טיפוס ועד פרסום

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

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

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

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

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

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

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

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

מה נותנים לופ משחק מנוהל ואופטימיזציה של סצנות

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

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

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

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

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

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

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

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

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

שלבי העבודה על הפרויקט: מהאודיט ועד המסירה

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

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

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

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

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

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

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

קייס: איך הסרנו את הקריסות במעבר בין סצנות

הפרויקט — מירוץ תלת-ממדי קז'ואלי על Unity עם עשרה מסלולים ומעבר בין סצנות בין המקצה לתפריט. במכשירים בסגמנט המחיר התחתון, בחזרה לתפריט, האפליקציה נסגרה: שיעור הסשנים האלה הגיע ל-7%, ובביקורות חזר המשפט «קורס אחרי המירוץ». במכשירי הדגל הבעיה לא שוחזרה, ולכן תלו אותה בחומרה חלשה ודחו אותה.

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

את היציבות אישרנו על מכשירים אמיתיים, ולא רק באמולטור: הרצנו 200 מעברים בין סצנות על כל דגם בסגמנט התחתון והבינוני. לפי הלקוח, שטף הפניות לתמיכה בנוגע לקריסות פסק, הדירוג בחנות עלה מ-3.8 ל-4.5, והריטנשן אחרי הסשן הראשון — בשליש.

מה עושים אם יש פרוטוטייפ אבל הפרויקט לא מתרחב?

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

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

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

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

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

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

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

איך יוצאים עדכונים של המשחק?

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

איך מוטמעים תשלום, אנליטיקה ואימות?

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

למי שייכות הזכויות על קוד המקור?

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

אפשר להעביר את הפרויקט לצוות אחר?

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

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

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

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

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

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