Megapack: כיצד פקטוריו פתר את בעיית מרובי השחקנים של 200 שחקנים

במאי השנה השתתפתי כשחקן ב אירועי MMO של KatherineOfSky. שמתי לב שכשמספר השחקנים מגיע למספר מסוים, כל כמה דקות חלק מהם "נופלים". למזליכם (אבל לא בשבילי), הייתי אחד מהשחקנים האלה בכל פעםאפילו עם חיבור טוב. לקחתי את זה כאתגר אישי והתחלתי לחפש את הגורמים לבעיה. לאחר שלושה שבועות של איתור באגים, בדיקות ותיקון, הבאג תוקן סוף סוף, אבל המסע לא היה כל כך קל.

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

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


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

Multiplayer Mega Pack - פרטים טכניים

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

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

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

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

לשם כך, אנו שומרים עותק של הקובץ שנוצר פעולות קלט בתור העיכוב.

כלומר, בסוף התהליך בצד הלקוח, התמונה נראית בערך כך:

1. להגיש מועמדות פעולות קלט כל השחקנים מצב משחק האופן שבו פעולות הקלט הללו התקבלו מהשרת.
2. הסר הכל מתור ההשהיה פעולות קלט, שלפי השרת, כבר הוחלו עליו מצב משחק.
3. הסר מצב חביון ואפס אותו כך שהוא ייראה בדיוק כמו מצב משחק.
4. החל את כל הפעולות מתור ההשהיה על מצב חביון.
5. מבוסס על נתונים מצב משחק и מצב חביון להציג את המשחק לשחקן.

כל זה חוזר על עצמו בכל מידה.

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

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

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

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

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

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

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

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

מקור: www.habr.com