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

היי, אני Nikita Brizhak, מפתחת שרתים מבית Pixonic. היום אני רוצה לדבר על פיצוי על פיגור ב-Multiplayer נייד.

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

אנו משתמשים בו גם ביריות מרובה משתתפים הנייד שלנו Dino Squad.

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

כמה מילים על הקורטקס והטכנולוגיה שלנו.

Dino Squad הוא יורה PvP נייד ברשת. שחקנים שולטים בדינוזאורים המצוידים במגוון כלי נשק ונלחמים זה בזה בקבוצות 6 נגד 6.

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

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

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

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

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

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

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

חמושים בידע הזה, התחלנו ליישם פיצוי לאחור בשרת ב-Dino Squad. קודם כל, היינו צריכים להבין איך לשחזר בשרת את מה שהלקוח ראה? ומה בדיוק צריך לשחזר? במשחק שלנו, פגיעות מכלי נשק ויכולות מחושבות באמצעות הקרנות ושכבות-על - כלומר, באמצעות אינטראקציות עם המתנגשים הפיזיים של האויב. בהתאם לכך, היינו צריכים לשחזר את המיקום של המתנגשים הללו, שהשחקן "ראה" באופן מקומי, בשרת. באותו זמן השתמשנו בגרסת Unity 2018.x. ה-API של הפיזיקה שם הוא סטטי, העולם הפיזי קיים בעותק בודד. אין דרך לשמור את המצב שלו ואז לשחזר אותו מהקופסה. אז מה לעשות?

הפתרון היה על פני השטח; כל האלמנטים שלו כבר שימשו אותנו לפתרון בעיות אחרות:

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

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

public class TimeMachine : ITimeMachine
{
     //История игровых состояний
     private readonly IGameStateHistory _history;

     //Текущее игровое состояние на сервере
     private readonly ExecutableSystem[] _systems;

     //Набор систем, расставляющих коллайдеры в физическом мире 
     //по данным из игрового состояния
     private readonly GameState _presentState;

     public TimeMachine(IGameStateHistory history, GameState presentState, ExecutableSystem[] timeInitSystems)
     {
         _history = history; 
         _presentState = presentState;
         _systems = timeInitSystems;  
     }

     public GameState TravelToTime(int tick)
     {
         var pastState = tick == _presentState.Time ? _presentState : _history.Get(tick);
         foreach (var system in _systems)
         {
             system.Execute(pastState);
         }
         return pastState;
     }
}

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

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

אבל יש מעט מאוד מכונאים כאלה ב-Dino Squad! רוב כלי הנשק במשחק יוצרים קליעים - כדורים ארוכים שעפים למספר תקלות סימולציה (במקרים מסוימים, עשרות טיקים). מה לעשות איתם, באיזו שעה הם צריכים לטוס?

В מאמר עתיק לגבי ערימת הרשת Half-Life, החבר'ה מ-Valve שאלו את אותה שאלה, והתשובה שלהם הייתה כזו: פיצוי על פיגור קליעים הוא בעייתי, ועדיף להימנע מכך.

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

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

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

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

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

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

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

בנפרד, כדאי להעלות את נושא הביצועים. אם חשבתם שכל זה יאט את הקצב, אני עונה: זהו. Unity די איטית בהזזת מתנגשים ובכיבוי שלהם. ב-Dino Squad, במקרה ה"גרוע" ביותר, יכולים להיות כמה מאות קליעים הקיימים בו-זמנית בלחימה. העברת מתנגשים כדי לספור כל קליע בנפרד היא מותרות שלא משתלמת. לכן, זה היה הכרחי עבורנו למזער את מספר ה"חזרות" של הפיזיקה. לשם כך יצרנו רכיב נפרד ב-ECS בו אנו מקליטים את הזמן של הנגן. הוספנו אותו לכל הגופים שדורשים פיצוי פיגור (קליעים, יכולות וכו'). לפני שנתחיל לעבד ישויות כאלה, אנו מאגדים אותן עד לזמן זה ומעבדים אותן יחד, מגלגלים את העולם הפיזי פעם אחת עבור כל אשכול.

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

public sealed class LagCompensationSystemGroup : ExecutableSystem
{
     //Машина времени
     private readonly ITimeMachine _timeMachine;

     //Набор систем лагкомпенсации
     private readonly LagCompensationSystem[] _systems;
     
     //Наша реализация кластеризатора
     private readonly TimeTravelMap _travelMap = new TimeTravelMap();

    public LagCompensationSystemGroup(ITimeMachine timeMachine, 
        LagCompensationSystem[] lagCompensationSystems)
     {
         _timeMachine = timeMachine;
         _systems = lagCompensationSystems;
     }

     public override void Execute(GameState gs)
     {
         //На вход кластеризатор принимает текущее игровое состояние,
         //а на выход выдает набор «корзин». В каждой корзине лежат энтити,
         //которым для лагкомпенсации нужно одно и то же время из истории.
         var buckets = _travelMap.RefillBuckets(gs);

         for (int bucketIndex = 0; bucketIndex < buckets.Count; bucketIndex++)
         {
             ProcessBucket(gs, buckets[bucketIndex]);
         }

         //В конце лагкомпенсации мы восстанавливаем физический мир 
         //в исходное состояние
         _timeMachine.TravelToTime(gs.Time);
     }

     private void ProcessBucket(GameState presentState, TimeTravelMap.Bucket bucket)
     {
         //Откатываем время один раз для каждой корзины
         var pastState = _timeMachine.TravelToTime(bucket.Time);

         foreach (var system in _systems)
         {
               system.PastState = pastState;
               system.PresentState = presentState;

               foreach (var entity in bucket)
               {
                   system.Execute(entity);
               }
          }
     }
}

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

1. להבין עד כמה להגביל את מרחק התנועה המקסימלי בזמן.

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

2. קבע אילו חפצים ניתן להזיז בזמן ואילו לא.

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

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

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

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

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

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

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

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

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

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

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

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

מקור: www.habr.com