תכנון מערכת התקדמות למשחק מובייל

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

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

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

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

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

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

מה נותנת התקדמות מכוילת: האפקט בלוחות זמנים ובמדדים

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

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

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

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

מודלים של התקדמות: ליניארי, ספי, מסתעף

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

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

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

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

כיצד נבנית ההטמעה: שלבי העבודה ההנדסית

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

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

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

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

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

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

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

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

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

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

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

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

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

מה היה לפני התיקונים

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

מה שינו בעקומה

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

מה הראה המדידה לפני ואחרי

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

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

מה לעשות אם האיזון התפצל מנתוני האמת

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

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

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

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

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

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

ספקות טכניים נפוצים בתכנון איזון

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

כיצד נשלטת מהירות ההתקדמות?

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

האם אפשר לתקן את האיזון אחרי ההשקה?

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

כיצד ההתקדמות קשורה לתגמולים?

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

מה עם השחקנים שחזרו?

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

בואו נדון במשימה: מהיכן מתחיל התכנון

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

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

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

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