מערכת AI לקושי דינמי במשחק: פיתוח DDA

קושי אדפטיבי במקום איזון סטטי של שלבים

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

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

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

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

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

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

אפקט היישום: שימור, נשירה, אורך סשן

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

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

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

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

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

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

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

שלוש אפשרויות עבודה

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

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

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

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

סט ארטיפקטים: תצורות, סכמות, נהלים

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

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

מקרה בוחן: כיצד ההתאמה שינתה את התנהגות השחקנים

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

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

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

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

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

במה קושי אדפטיבי שונה מאיזון ידני?

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

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

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

ספקות לגבי יישום: שאלות מהנדסים

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

לא יהיו מספיק נתונים לאימון?

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

כיצד מחזירים שינוי אם נהיה גרוע יותר?

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

לא ישעמם לשחקנים חזקים?

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

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

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

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

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

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