למה משחק היפר-קז'ואל לא נכנס לטופ לפי התקנות
אב הטיפוס של משחק היפר-קז'ואל נבנה: ליבת המכניקה עובדת, שלבים נוצרים, הבילד עובר מודרציה ומופיע ב-Google Play. ההתקנות מגיעות, אבל ביום השני-שלישי המשפך מתמוטט: החזרה יורדת מתחת ל-20%, סשן ממוצע נכנס לדקה, ומכאן המספרים לא זזים.
הסיבה בדרך כלל לא בפרסום. אלגוריתמים של רכישת טראפיק מעריכים את ההתנהגות של הסשנים הראשונים: אם השחקן לא חוזר למחרת, המערכת מסווגת את הקהל כחלש, ועלות ההתקנה עולה מהר יותר מבסיס השחקנים. נוצר מעגל קסמים — מגדילים את היקף הרכישה, אבל שימור נמוך ומחיר עולה מושכים את הפרויקט למטה.
כישלון של אב טיפוס כמעט אף פעם לא נובע מהגרפיקה. נשברת החוליה "פעולה ראשונה — הצלחה ראשונה — הפעלה הבאה": השחקן לא מבין את המטרה תוך 5-10 שניות, עקומת הקושי בשלב השלישי-חמישי פוגעת במתחיל, והוא עוזב לפני שהמכניקה מספיקה להתגלות. בדיקת מכניקה נחוצה בדיוק כאן — בהתנהגות, ולא ב"מרגיש כיף לשחק" סובייקטיבי.
בהמשך נפרק איך לצאת מהמצב הזה: אילו מדדים למדוד על אב הטיפוס, איך להפריד בין בעיית השימור לבעיית הטראפיק, ובאיזה רגע להרחיב את הרכישה.
מה נותן משחק היפר-קז'ואל עם מחזור תיקונים משומן
מחזור תיקונים משומן הוא לא "הרבה איטרציות", אלא מסלול קבוע של השערה: המכניקה מתוארת במילים ובמספרי יעד, בונים אב טיפוס משחקי על שלב אחד, ורק אחר כך מחליטים אם לפתח אותה או לסגור.
איטרציית פיתוח אחת לא נוגעת בפרוגרסיה, בחנות ובאנליטיקה — משתנה רק הצומת הנבדק, ולכן הבילד והמדידה אורכים ימים, לא שבועות.
המדידה העיקרית במחזור — שימור הסשנים הראשונים. מסתכלים לא על המספר הממוצע, אלא על העקומה: שיעור השחקנים שהגיעו לסשן השני, אורך הסשן הראשון, נקודות הנשירה בשלבים הראשונים ובהקשיה הראשונה.
אם הנשירה מתרחשת במסך מסוים, הסיבה בדרך כלל באיזון או בהסבר הכלל, ולא במקור הטראפיק — וזה מתוקן בבילד הבא.
השערות מכניקה נבדקות אחת אחת ובסדר ההשפעה: קודם שליטה ומטרה, אחר כך קצב התגמול, ואחר כך פרוגרסיה ופרסומות מוטמעות. החלשות מנופות לפני בילד רחב היקף, כשהתיקון עולה אב טיפוס אחד, ולא עיצוב מחדש של שלבים, ממשק ומערכת תגמולים. הכלל פשוט: מכניקה בלי עלייה במדידה לא נכנסת לייצור.
מהירות הבדיקה הופכת לכמות ניתנת לניהול. בסוף המחזור יש לצוות יומן השערות עם תוצאות, לוח מדדים לשימור הסשנים הראשונים וקריטריון סינון ברור. הלקוח רואה לא דוח "עשינו", אלא דינמיקה: אילו מכניקות נשארו, אילו נסגרו ובאיזו מדידה זה אושר.
פורמטים של עבודה: ליבה מוכנה, אב טיפוס מקצה לקצה, היברידי
את הפורמט בוחרים לפי קריטריון אחד: כמה איטרציות מפרידות בין הצוות להשקה הראשונה על טראפיק פרסומי וכמה המכניקה מתרחקת מרפרנסים מוכחים.
ליבת מכניקות מוכנה מסירה סיכונים בפיזיקה, בשליטה ובתגובה לקלט, אבל מיד מטילה מגבלות של תבנית; אב טיפוס מקצה לקצה מסיר מגבלות, אבל מוסיף היקף עבודה עד הבילד הראשון.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| ליבת מכניקות מוכנה | ההשערה נבדקת בז'אנר מוכר: ראנר, סטאקר, פתרון פאזל | תקרה בעומק: תנאי שלבים ופרוגרסיה ייחודיים דורשים לכתוב מחדש שכבות לוגיקה |
| אב טיפוס מקצה לקצה | המכניקה היא ההשערה — צריך פיזיקה משלך ותגובה לא סטנדרטית למחווה | לוקח יותר זמן עד הבילד הראשון, סיכוי גבוה יותר לא לעמוד בשימור |
| פיתוח היברידי | הליבה ייחודית, אבל אנליטיקה, פרסומות מוטמעות והדרכה — טיפוסיים | יותר חיבורים: יש לשמור על תאימות גרסאות המודולים עם הליבה |
| מחזור מלא | ההשקה כבר נתנה עלות התקנה עובדת ויש טעם להגדיל תוכן | מוצדק רק אחרי השערה מאומתת, אחרת משכפלים שגיאות |
איך הפורמטים מתחברים ביניהם
אנחנו מרכיבים את כל הווריאנטים על חוזה אירועים אחד: אנליטיקה והלוגיקה הפנימית של השלבים מתחברות לליבה דרך שכבה משותפת, ולכן המעבר מאב טיפוס לענף הריליס לא דורש כתיבה מחדש.
את ענף המנוע אנחנו מחזיקים על ענף LTS עדכני של Unity, כדי שמודולים מוכנים והליבה לא יתפצלו בעדכונים, ושמדדי ההשקה הראשונה אפשר יהיה להשוות ישירות לאלה של הריליס.
איך העבודה מתנהלת: מהשערה ועד מסירת קוד המקור
העבודה מתנהלת בשלבים, ואחרי כל אחד יש נקודת החלטה: מאשרים את ההשערה בנתונים או סוגרים אותה, לפני שהושקעו בה שבועות. הסדר זהה גם למכניקה בודדת וגם לסדרת אבות טיפוס — קודם אודיט רפרנסים, אחר כך סכמה ובילד, ורק אחר כך בדיקה על זרם התקנות חי.
-
אודיט רפרנסים. מפרקים 8–12 משחקים מהז'אנר: מחזור של סשן אחד, עקומת קושי, רגע התגמול הראשון, מקומות של פרסומות מוטמעות. בפלט — טבלת מכניקות עם סימון "לוקחים / מתאימים / זורקים".
-
סכמת מכניקות ומתמטיקה. קובעים זמן עד הצלחה ראשונה, צעד הקושי ונקודות תגמול. איזון מחשבים בטבלאות: כמה שלבים עובר שחקן ממוצע ואיפה הוא נושר.
-
שלבי פיתוח אב טיפוס. מרכיבים בילד משחקי על placeholder אפורים: מכניקה אחת, כעשרה שלבים, מינימום ויזואל. כך נבדקת המכניקה עצמה, ולא איכות הרינדור.
-
אינסטרומנטציה של אנליטיקה. אירועי התחלת סשן, סיום שלב, התקדמות והצגות פרסום. בלעדיהם זרם ההתקנות נותן מספרים בלי סיבות, ולא ברור מה בדיוק לכוונן.
-
בדיקה על זרם התקנות. השקה מוגבלת על טראפיק אמיתי: שימור היום הראשון, אורך סשן, עומק התקדמות, שיעור המגיעים למסך המפתח.
-
החלטה לפי מדד הצלחה. אם המספרים מחזיקים ברף שנקבע לפני ההשקה — מרחיבים ומגדילים תוכן. אם לא — מתעדים איזו השערה לא עבדה, ומחליפים מכניקה, לא גרפיקה.
-
מסירה. קוד מקור, בילדים לפלטפורמות היעד, טבלאות איזון, מפת אירועי אנליטיקה והוראות בנייה — צוות הלקוח ממשיך לעבוד בלעדינו.
מה נשאר אצלכם: בילדים, אנליטיקה, נהלים
מסירת פרויקט היא לא ארכיון עם קוד וקישור לבילד. עבור משחק היפר-קז'ואל אנחנו מוסרים ערכה, שלפיה הצוות שלכם או קבלן חדש יבנה ריליס, יראה את התנהגות השחקנים ויוציא עדכון בלעדינו. להלן רשימת מה שמתועד בפרוטוקול הקבלה.
- מסירת קוד מקור — מאגר עם היסטוריית שינויים מלאה, ענפי ריליס והערות למודולים מרכזיים במחזור המשחק.
- זכויות על הבילד — ריליס חתום, שפורסם בחנויות האפליקציות תחת חשבון המפתח שלכם.
- גישות ובעלות — חשבונות פרסום, מפתחות חתימה והגדרות מועברים לארגון שלכם, ולא נשארים אצלנו.
- אנליטיקה מוגדרת — אירועים, משפך מהצגה ועד הסשן הראשון, דוחות שימור לפי ימים והוצאות גיוס.
- תיעוד הפרויקט — ארכיטקטורה, סכמת שמירת התקדמות, תיאור איזון שלבים והוראות בנייה לריליס.
- נוהל עדכונים — סדר הוצאת תיקונים לגרסאות מערכת חדשות, לוחות זמנים לבדיקה וכלל חזרה לריליס הקודם.
- צ'ק-ליסט קבלה — סט בדיקות שמאשרות שהבילד, האנליטיקה והגישות עובדים כבר בצד שלכם.
כל סעיף נסגר בבדיקה, לא בחתימה: אתם בונים ריליס מקוד המקור ומוודאים שהאירועים מגיעים לדוחות.
ניתוח מקרה: דינמיקת מדדים לפני ואחרי תיקונים
אלינו הגיע אב טיפוס משחקי של משחק היפר-קז'ואל: המחזור הבסיסי "הפעיל — עבר — נכשל — חזר" עבד, אבל ברכישות המבחן הראשונות הקוהורטה עזבה כמעט מיד. מדידות דרך Adjust הראו אותה תמונה בכל הניסיונות: חלק ניכר מהשחקנים לא שרד עד הניצחון הראשון. ההדרכה ארכה יותר מדקה, וההפסד הראשון נפל על שלב שבו הכללים עוד לא היו ברורים.
מה עבדנו מחדש במכניקה
מסך ההדרכה הוסר וההיכרות עם הכללים הועברה לפעולה — הניצחון הראשון נכנס כעת ב-15 שניות. עקומת הקושי הורכבה מחדש: כישלון מגיע אחרי שתי הצלחות רצופות, ולא בשלב הראשון. במסך ההפסד נוסף ריסטארט בטאפ אחד, נוספו פס התקדמות עד התגמול הבא ובונוס על חזרה ביום השני.
| מדד | לפני תיקונים | אחרי |
|---|---|---|
| שימור היום הראשון | 24% | 37% |
| שימור היום השביעי | 4% | 9% |
| אורך סשן ממוצע | 2.1 דק' | 4.3 דק' |
| חזרה בתוך יומיים | 18% | 34% |
העבודה מחדש נגעה רק בשכבת המוטיבציה וההגשה: הליבה ומערכת השלבים נשארו כשהיו, ולכן מחזור הרכישות החוזר הופעל בלי לבנות מחדש את הפרויקט. דינמיקת מדדים במקרה כזה כמעט תמיד נתקעת ב-60 השניות הראשונות וברגע ההפסד הראשון — היקף התוכן בהתחלה משפיע הרבה פחות.
במה אב טיפוס לבדיקה שונה מבילד מלא?
אב טיפוס ובילד מלא הם כלים שונים, ובלבול ביניהם יקר. אב טיפוס בודק אם מחזור המשחק עצמו תופס, ועונה על השאלה הזו בתוך שבועות ספורים. בילד מלא בודק משהו אחר: האם המכניקה תעמוד בזרם טראפיק בתשלום והאם תחזיר את ההשקעה.
לוחות הזמנים של אב טיפוס קצרים — שבועיים עד ארבעה שבועות, כי הוויזואל סכמטי וחלק מהמערכות מוחלפות ב-placeholders. בילד מלא דורש פי כמה יותר: מתווספים מטא-פרוגרסיה, פרסומות מוטמעות, רכישות בתוך המשחק וסימון אירועים.
ההבדלים בדיוק המסקנות עקרוניים. אב טיפוס מראה אם המחזור מעניין, אבל לא מאשר החזר השקעה: בלי ארט אמיתי ורשתות פרסום, בדיקת עלות התקנה (CPI) נותנת תמונה מוטה. לכן לא הכול עובר לבילד מלא — שלד המכניקה, איזון השלבים הראשונים וסימון אירועים, בעוד שהוויזואל והכלכלה נבנים מחדש.
שאלות נפוצות על מכניקה, אנליטיקה ומסירה
החלטות על מכניקות מתקבלות לא "לפי הטעם", אלא לפי מספרים: לאב טיפוס יש סט אירועים — הסשן הראשון, אורכו, מעבר שלבים, חזרה למחרת. ענף לא עובר לבילד הריליס עד שהוא נותן עלייה יציבה במדד המפתח בקטע טראפיק קצר.
העברת הזכויות מתועדת לפני ההתחלה, לא אחרי: קוד המקור נמצא במאגר שלכם, הפרסום בחנויות, לוח האנליטיקה וחשבונות הפרסום רשומים על שמכם. אנחנו עובדים כקבלן, לא כמחזיקי החשבונות — זה מסיר חצי מהשאלות בעת החלפת קבלן.
יש לנו כבר אב טיפוס — אפשר לשפר אותו?
אנחנו מסתכלים על הבילד, מבנה המסכים ואילו אירועים הוא כבר מפיק. אם הבסיס מאפשר להרחיב מכניקות ולחבר אנליטיקה — מפתחים אותו. אם לא, מעבירים את הלוגיקה לבסיס נקי: בדרך כלל זה מהיר יותר מאשר לתקן ארכיטקטורה של אחרים, ואנחנו מסכמים בנפרד את ההיקף.
למי שייכים קוד המקור והנתונים שנצברו?
לכם. קוד המקור, קונפיגורציות השלבים והאירועים שנצברו נשארים בצד שלכם, ואת הגישות אנחנו מוסרים עם סיום השלב. נתונים של פרויקט אחד לא נעשה בהם שימוש חוזר באחרים — זה כתוב בחוזה ובתנאים הטכניים.
איך משתנות מכניקות אחרי בדיקה?
בודקים השערות אחת אחת: מתקנים פרמטר מסוים, מחזיקים את השאר ללא שינוי ובוחנים איך המדד מגיב. כך רואים מה בדיוק נתן את האפקט, ומה סתם חפף לעלייה בטראפיק.
בואו נדבר על המשימה: מה לשלוח להערכה ולתוכנית
קונספט בדמות תיאור, רפרנסים וכמה מסכים מספיק כדי לחזור עם הערכת היקף העבודה ותוכנית למחזור הראשון. להלן הנתונים המקדימים שהכי מרחיבים את טווח ההערכה: ככל שהם סגורים יותר, כך יש פחות איטרציות הבהרה.
- ליבת הגיימפליי: מכניקות מרכזיות, משך סיבוב, תנאי הפסד ומה שמושך את השחקן לסבב הבא.
- רפרנסים: 2–3 משחקי עוגן ומה חשוב בהם — קצב, עקומת קושי, הגשה.
- ארט ותוכן: 2D או 3D, מספר שלבים ונכסים, האם יש קוד מקור או בונים מאפס.
- פלטפורמות ואזורים: חנויות אפליקציות, גרסאות מערכת מינימליות, כיוון מסך, גיאוגרפיה של ההשקה.
- מונטיזציה ואנליטיקה: פורמטים פרסומיים בין סיבובים, רכישות בתוך המשחק, רשימת אירועים למשפך ולשימור.
- גישות וקריטריוני בדיקה: חשבונות חנויות וחשבונות פרסום, וגם המדד שנחשב להצלחה ושבפיו מרחיבים.
בהמשך — דיון במשימה: שיחה קצרה, שלאחריה נשלח תוכנית עבודה לפי שלבים, לוחות זמנים והרכב צוות למחזור הראשון. תארו את המשימה בצורה חופשית — את החסר נשלים בעצמנו.