פיתוח מאץ'-3: היכן נשברת לולאת המשחק
אב-טיפוס עם עשרה שלבים נראה בריא: הלוח נבנה, המפלים מחושבים, מטרות השלב מתאימות. הבעיה מתגלה בחלק האמצעי של המשחק — שיעור המעבר יורד משני שלישים צפויים לשליש, ומספר הניסיונות לשלב גדל מהר יותר ממה שהונח בעקומת הקושי.
הסיבה בדרך כלל בגנרטור. הוא מניח את האריחים ובודק את הלוח ההתחלתי לקיום מהלך, אך אינו מחשב מחדש את יכולת הפתרון לאחר מפל ומילוי: הלוח מגיע למצב שבו אין התאמות, וגם אין מהלך חוקי. ערבוב מחדש ברגע זה שובר מכשולים שהוצבו מראש — השלב הופך לשלב אחר.
השכבה השנייה — סדר השלבים בלולאת המשחק של הפאזל. בדיקת קיום מהלכים, המוצבת בסוף, מגלה מבוי סתום רק לאחר אנימציית המהלך. אלגוריתם בחירת האריחים צריך לעבוד יחד עם הגנרטור: בעת מילוי מוערכת לא רק ההתאמה הנוכחית, אלא גם האם יישארו מהלכים חוקיים בעוד מהלך-שניים קדימה.
איזון שלבים במאץ'-3 ועקומת הקושי נבנים בדרך כלל ידנית לפי תחושה: מגבלות מהלכים, מטרות וסט מכשולים מקובעים לפני שמופיעים נתונים על מעברים אמיתיים.
הכלכלה בתוך המשחק מוציאה משאבים לפי מודל אחד, והשחקנים מוציאים לפי אחר — עד אמצע המשחק הפער נעשה מורגש, ותיקון נקודתי של שלבים בודדים אינו סוגר אותו.
אנו מפרקים כיצד זה נסגר: מגנרטור עם הבטחת פתרון ועד טבלאות איזון שמרכיבות מחדש לפי נתוני מעברים.
מה נותנת בנייה מחדש של הליבה: שימור שחקנים ושיעור מעבר
הליבה של מאץ'-3 היא גנרטור הלוח וכללי חיפוש המהלכים, ולא אנימציית ההחלפה. כאשר הגנרטור אינו בודק את הלוח למהלכים תקפים, השחקן נתקע: יש אריחים, אין קומבינציות.
יצירת לוח ללא מבוי סתום — היגיינה בסיסית: לאחר כל נפילה ומילוי חללים מתבצע חיפוש מהלכים, ואם אין כאלה הלוח נבנה מחדש מאותו זרע עד להופעת לפחות החלפה חוקית אחת.
השכבה השנייה — עקומת הקושי. במקום תיקון ידני של כל שלב בנפרד, אנו מגדירים כמה צירים: מטרה, מגבלת מהלכים, סט אריחים, מכשולים, תדירות בונוסים. זה נותן עומק התקדמות שבו שיעור המעבר של שלבים עולה באופן חלק, ובקטעים קשים רואים היכן בדיוק השחקנים נושרים.
שימור השחקנים בפאזל נשען על הסשנים הראשונים. אם בשלב העשירי אדם נתקל כמה פעמים במטרה בלתי מושגת, סשן שני לא יהיה. לאחר בנייה מחדש של רשת השלבים, שיעור המגיעים לסוף בלוק ההדרכה עלה, והנשירה בשלבים האמצעיים הפסיקה להיות צוק.
יציבות האנימציה — ענף עבודה נפרד. מפל בונוסים יוצר פרץ חישובים ונפילות ביצועים במכשירים חלשים: מגבילים את עומק המפל, מחשבים את מצב הלוח לפני תחילת הוויזואליזציה, מצלמים פרופיל במכשירים אמיתיים — Unity הוא הכלי העיקרי שלנו, אך החלטות מתקבלות לפי מדידות, לא לפי תחושות.
התוצאה מדידה: אין לוחות ללא מהלך בכל סט השלבים, השלב מוכן להצגה מהר יותר, ושיעור החוזרים ביום השני והשביעי עלה באותו זרם שחקנים.
אפשרויות פיתוח של משחק מאץ'-3 והמגבלות שלהן
לפני בחירת סטאק, מגדירים את מקור המכניקות: הוא קובע כמה זמן ייקח האיזון וכמה כואב יהיה להעביר את המשחק לפלטפורמה שנייה. לוח, מפלים, איסוף התאמות ולוגיקת רמזים — זה הליבה, והיא בדיוק קובעת אילו תיקונים בכלל אפשריים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| סט מכניקות מוכן | נדרש אתחול מהיר על רשת ומפלים מוכחים | לוגיקת השלבים סגורה: לא ניתן להוסיף כללי הרכבה משלך ובונוסים לא סטנדרטיים, גנרטור השלבים מגיע בחבילה וכמעט אינו ניתן להגדרה |
| ליבה עצמאית למשחק | מתוכננות מכניקות משלך, לוגיקה בשרת ותמיכה ארוכה | ארוך ויקר יותר בהתחלה: אנו כותבים בעצמנו בדיקת מהלכים, ניתוח מפלים, טבלאות פרסים ותנאי ניצחון |
| גישה היברידית | נדרשים בונוסים משלך או גנרטור שלבים על בסיס מוכן | קוד צד שלישי צריך לסנכרן עם הכללים שלך בכל עדכון של הסט |
סעיף נפרד — גנרטור השלבים: הוא קובע אם המשחק מתרחב בכוחות מעצב המשחק או שנדרש מהנדס לכל שלב. יכולת ההעברה לפלטפורמה אחרת מונחת כבר בשלב הזה: אם הלוח, המהלכים וההתקדמות מתוארים בנתונים ולא מפוזרים בין מסכים, הפלטפורמה השנייה מקבלת את אותה לוגיקה ושכבת רינדור נפרדת.
שלבי העבודה: מניתוח המכניקה ועד לשחרור
פיתוח מאץ'-3 אנו מובילים מהמצב הנוכחי של הפרויקט: קודם כל מודדים את מה שכבר עובד, ורק אחר כך משנים קוד. לכן בניית הליבה אינה מתחילה משכתוב חלקים עובדים, והחלטות איזון מתקבלות לפי מספרים, לא לפי תחושות.
- אודיט של אב-הטיפוס של המשחק. מודדים את תגובת הלוח להחלקה ולמפלים, מריצים את הגנרטור על מצבי מבוי סתום, מתעדים מעבר שלבים ונקודות נשירה של שחקנים.
- תכנון ארכיטקטורת המשחק. בתרשים הקשרים מפרידים את ליבת המשחק — יצירת לוח, חיפוש התאמות, כבידה, מפלים — ואת שכבות הממשק, הנתונים והאנליטיקה. הכללים נבדקים בבדיקות בלי להפעיל את האפליקציה.
- בניית ליבת המשחק. יצירה דטרמיניסטית לפי זרע, מאגרי אובייקטים במקום יצירות מתמידות, שחזור משחק לאחר מזעור האפליקציה.
- כיול איזון. משקלי אריחים, מטרות שלב, מגבלת מהלכים, עקומת קושי. הסימולטור עובר שלבים אלפי פעמים ומוציא שיעור הצלחות ותדירות מבוי סתום — התיקונים נעשים לפי המספרים האלה.
- בניות בדיקה. מעגל סגור של שחקנים והרצות פנימיות: אירועי אנליטיקה לפי שלבים, שיעור מעבר, מספר ניסיונות, חזרות למשחק.
- קבלת הפרויקט. קוד מקור, תרשים ארכיטקטורה, תיעוד לגנרטור וטבלאות איזון, הוראות להוצאת עדכונים ולניתוח תקלות.
סדר כזה חוסך שבועות של עיבודים מחדש: צווארי בקבוק נמצאים לפני השחרור, ולא בביקורות. בהמשך הפרויקט חי במחזור עבודה — שלבים ומכניקות חדשים נכנסים לסכמה המוכנה בלי לשכתב את הליבה.
חפצי הפרויקט: קוד מקור, טבלאות איזון, נהלים
לאחר המסירה הפרויקט לא צריך להיות תלוי בנו. לכן האספקה כוללת לא בנייה מורכבת בחדר סגור של הקבלן, אלא מאגר עם היסטוריית שינויים מלאה, בנייה ניתנת לשחזור ונתונים שהצוות שלך עורך בעצמו. להלן רשימה של מה שמתועד במעמד המסירה ונשאר אצל המזמין.
- קוד המקור של המשחק — מאגר עם היסטוריית קומיטים, הוראות בנייה והגדרות סביבות; ענף השחרור מופרד מענף הפיתוח, וההרשאות ניתנות למהנדסים שלך.
- טבלאות איזון — קונפיגורציות בפורמטים קריאים (CSV, JSON): פרסים על שלב, תמחור בוסטרים ורמזים, עקומות קושי לפי פרקים. נערכות בלי לבנות מחדש את האפליקציה.
- כללי יצירת שלבים — תיאור אלגוריתם פריסת האריחים, קריטריונים לפתירות ומפלים, וגם סקריפטים של הגנרטור והמאמת עם דוגמאות הרצה.
- סכמות כלכלה והתקדמות — זרימות מטבע, נקודות מונטיזציה, קשרים בין קושי השלב לשימור השחקן בסשן הראשון.
- תיעוד הפרויקט — ארכיטקטורת הלקוח והחלק בשרת, פורמטי שמירות, רשימת שירותים חיצוניים ותפקידם בלולאת המשחק.
- נוהל עדכונים — סדר הוצאת גרסאות, כללי תאימות שמירות בין בניות וסדר חזרה לגרסה קודמת.
- הוראות קבלה וניטור — סדר בדיקת שלבים חדשים, סט מדדי משפך והגדרת התראות על תקלות בפרודקשן.
סט כזה מאפשר לפתח את המשחק עם הצוות שלך או להעביר אותו לקבלן אחר בלי לשחזר את הלוגיקה לפי סימנים עקיפים.
מקרה בוחן: הפעלה מחדש של רשת השלבים במשחק פעיל
מקרה של משחק מובייל: רשת של כמה מאות שלבים יצאה לאור, אך שיעור המעבר ירד במדרגות ולא באופן חלק. בחלק מהשלבים שיעור הניצחונות עמד על 12-18%, שחקנים נשחקו עד הניסיון השלושים-שישים וסגרו את האפליקציה.
ייצוא אירועים ל-GameAnalytics הראה: כ-70% מהנשירה מתרכזים בעשרים שלבים "צרים" מתוך כל הרשת — כלומר הבעיה לא הייתה בקושי בכללותו, אלא בפריסות לוח ספציפיות.
איך עבדנו מחדש על השלבים בלי לעצור את המשחק
פירקנו את הרשת לפי עקומת הקושי: לכל קטע הגדרנו שיעור ניצחונות יעד (75-80% בשלבים הראשונים, 45% באמצע, 25% בשיאים) והשווינו לנתון בפועל. גנרטור הלוח קיבל בדיקת פתירות — לפני הפצה הפריסה מורצת בחיפוש פתרונות, וקומבינציות שבהן המטרה אינה מושגת בלי בוסטר בתשלום נפסלות.
בדרך גם העלינו את הערך של מהלכים רגילים: התאמות שכנות יוצרות שרשראות לעתים קרובות יותר, והשלב נסגר במספר מהלכים קטן יותר.
כדי לא לעצור משחק פעיל, הוצאנו את סט השלבים לקובץ הגדרות מרוחק עם ניהול גרסאות והפצנו בקבוצות של עשרים ל-10% מהקהל. חזרה לסט הקודם — פעולה אחת, בלי בנייה מחדש ופרסום בחנויות האפליקציות.
תוצאה: שיעור הניצחונות בשלבים הבעייתיים עלה ל-46%, הנשירה באמצע הרשת הצטמצמה כמעט בחצי, וסשנים חוזרים ביום שלמחרת הוסיפו תשע נקודות אחוז. פיתוח מאץ'-3 אחרי השחרור הוא עבודה עם איזון, לא תיקון תוכן מדביק.
במה שונה רשת מפלים מפיזיקת נפילה הוגנת?
רשת מפלים ופיזיקת נפילה של אריחים נבדלות במה שקורה לאחר הסרת אריחים. במודל המפלים הלוח הוא מטריצה של קואורדינטות שלמות: אלמנט נעלם, העליונים זזו שורה, מלמעלה נוספו חדשים, והמפל הבא נפתר באותו מחזור. במודל הפיזיקלי האריח מקבל מהירות, נופל בתאוצה ומתנגש בשכנים — סדר הנחיתה תלוי בצעד הסימולציה.
מכאן ההבדל ביכולת לחזות את הלוח. רשת מפלים היא דטרמיניסטית: אותו רצף מהלכים נותן אותן קומבינציות בכל מכשיר, כי המצב מתואר במטריצת מספרים שלמים ואינו תלוי בקצב רענון הפריימים.
פיזיקה לא נותנת הבטחה כזו: בעומס שונה על המעבד האריחים נוחתים אחרת, ואותן קומבינציות במכשירים שונים נבדלות. במשחק רשתי זה עולה בסנכרון מצב ובחזרות לאחור.
התוצאה השנייה — תחושת הוגנות. במפל השחקן רואה לאיזו עמודה מה ייפול, ומתכנן שניים-שלושה מהלכים קדימה, והפסד נקרא כטעות שלו. במקום שבו התוצאה תלויה בהתנגשויות, אותו תכנון עובד רק לסירוגין, והתכנון מוחלף בניחוש — זו הדבר הראשון שמתלוננים עליו בביקורות.
הבחירה נקבעת בדרך כלל מראש לפי המכניקה. אם הליבה היא פאזל עם תכנון ודירוגים, לוקחים מפל: מצב הלוח משוחזר בשידור חוזר, נבדק בשרת ומוגן מפני החלפת תוצאה. פיזיקה מחברים בשביל קריסה מרשימה ובונוסים עם מחיקה המונית — אז מריצים את הסימולציה בצעד קבוע, ואת הפערים מטשטשים בצילומי מצב.
שאלות נפוצות על מכניקה, איזון ותמיכה
מצבי מבוי סתום, איזון שהתפזר, אב-טיפוס על בונה מוכן — הספקות האלה צפים לפני ההתחלה. להלן תשובות טכניות קצרות: איך בודקים את המכניקה, אילו נתונים אוספים ומה נשאר אצל המזמין.
איך אתם מוצאים מצבי מבוי סתום על הלוח?
מריצים שלבים עם בוט: אלפי משחקים לפי אסטרטגיות שונות מראים לוחות שבהם לא נותרו מהלכים או שהמטרה אינה מושגת. את הגנרטור בודקים בנפרד על פריסות נדירות כדי שהלוח לא ייתקע בהתחלה.
האם יהיה צורך לשכתב את האיזון אחרי ההשקה?
לא מאפס. את האיזון אנחנו שומרים בטבלאות, לא בקוד: מטרות, מגבלת מהלכים, משקל האריחים וסיכוי נפילת הבונוסים נערכים בלי בנייה מחדש. אחרי השינויים הבוט מריץ את השלבים מחדש ומשווה את שיעור המעבר.
אפשר להעביר אב-טיפוס מבונה מוכן?
כן. מפרקים סצנות ומכניקה של אב-הטיפוס, מעבירים את הלוגיקה לענף Unity עדכני ומשווים למקור לפי משחקי בקרה. האיזון והשלבים נשמרים; אנחנו כותבים מחדש את ארכיטקטורת השמירות והאנליטיקה.
מה כלול במסירת התמיכה?
מאגר, קונפיגורציות איזון, סכמות נתונים, הוראות בנייה ושחרור, גישות לחנויות האפליקציות. הצוות שלך יוכל להוביל את הפרויקט בעצמו — אנחנו מפרקים את צווארי הבקבוק.
איך מחברים אנליטיקה?
אוספים משפך: התקנה, הדרכה, ניצחון ראשון, נשירה בשלב, חזרות, תשלומים. לאירועים נותנים שמות לפי סכמה אחידה, כדי שדוחות לפי שלבים וכלכלה יתאמו בלי הדבקה ידנית.
נדבר על המשימה: מכניקה, היקף, הרכב צוות
כדי לחזור עם הערכת היקף העבודה ותוכנית שלבים, צריך נתוני פתיחה — בלעדיהם כל הערכה הופכת לטווח רחב של לוחות זמנים והרכב צוות. ככל שהחומרים קונקרטיים יותר, כך פחות הנחות בתוכנית, וכך מדויק יותר נמנה את היקף העבודה בכל חלק: מכניקת לוח, ממשק, כלכלה, חלק בשרת.
מה לשלוח ומה להבהיר בהתחלה:
- פלטפורמות וכיסוי מכשירים: רק סמארטפונים או גם טאבלטים, כיוון המסך, גרסת מערכת מינימלית נתמכת — מזה תלוי היקף התאמת הממשק.
- חומרי אב-הטיפוס: סקיצות שלבים, תרשימי לוח המשחק, דוגמאות לסגנון ויזואלי, תיאור מכניקות בחירה ונפילה של אריחים. אם יש מודל שניתן לשחק בו — נפרק אותו ראשון.
- כללי השלב: גודל הלוח, סט אריחים ובונוסים, תנאי ניצחון והפסד, מגבלת מהלכים והתנהגות הלוח כשאין התאמות.
- מונטיזציה: פרסום בין שלבים, רכישות בתוך האפליקציה, מנוי או שילוב שלהם — מזה תלויה סכמת ההתקדמות ועקומת הקושי.
- הרכב הצוות: אילו תפקידים אתם מכסים (עיצוב משחק, ארט, אנליטיקה), ואילו אנחנו לוקחים על עצמנו. זה קובע ישירות את תוכנית השלבים ונקודות התיאום.
- מגבלות ותחילת הפרויקט: לוחות זמנים רצויים, דרישות פלטפורמות פרסום, חשבונות מפתח מוכנים, גישות למערכות שלך.
לאחר הניתוח נחזור עם הערכת היקף העבודה, תוכנית שלבים לאב-טיפוס, ייצור והשקה, והצעה להרכב הצוות. תארו את המשימה — נקבע שיחה עניינית.