משחק סלולרי ב-Godot: מפרוטוטיפ לפרסום בחנויות

למה אב-טיפוס ב-Godot נתקע לפני פרסום

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

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

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

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

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

מה משתנה אחרי הגדרת צינור הבנייה

פרויקט ב-Godot לפני הגדרת הצינור נבנה ידנית: בניית release ארכה מארבעים דקות עד שעה וחצי, מפתחות חתימה נשמרו בהתכתבות, וחלק מהשלבים היו רק בראש של מהנדס אחד. אחרי המעבר לצינור אותה בנייה נמשכת 8–12 דקות בפקודה אחת, והארטיפקט המוכן מקבל מספר שלפיו אפשר למצוא אותו ולהשוות לקודם.

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

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

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

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

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

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

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

שלבי העבודה: מבדיקת הפרויקט ועד שחרור

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

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

שלושת השלבים הראשונים קובעים את העיקר — חיזוי של כל שחרור הבא.

מה מוסרים יחד עם בניית השחרור

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

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

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

מקרה בוחן: משחק מאב-טיפוס ועד פרסום

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

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

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

במה שונה בנייה ל-Android מבנייה ל-iOS באותו פרויקט?

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

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

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

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

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

התנגדויות טכניות נפוצות לפני התחלה

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

מי אחראי לבדיקה בחנויות האפליקציות?

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

מה קורה אחרי הפרסום — איך יוצאים עדכונים?

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

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

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

נדבר על המשחק שלכם ועל תוכנית הפרסום

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

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

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