Како ја подобривме механиката на балистичките пресметки за мобилен стрелец со алгоритам за компензација на латентност на мрежата

Здраво, јас сум Никита Брижак, развивач на сервери од Pixonic. Денес би сакал да зборувам за компензирање на заостанување во мобилниот мултиплеер.

Многу статии се напишани за компензација на доцнење на серверот, вклучително и на руски. Ова не е изненадувачки, бидејќи оваа технологија активно се користи во создавањето на FPS за мултиплеер од доцните 90-ти. На пример, можете да се сетите на модот QuakeWorld, кој беше еден од првите што го користеше.

Го користиме и во нашиот мобилен шутер со повеќе играчи Dino Squad.

Во оваа статија, мојата цел не е да го повторам она што е веќе напишано илјада пати, туку да кажам како ја имплементиравме компензацијата на задоцнување во нашата игра, земајќи ги предвид нашиот технолошки куп и основните карактеристики на игра.

Неколку зборови за нашиот кортекс и технологијата.

Dino Squad е мрежен мобилен PvP стрелец. Играчите контролираат диносауруси опремени со различни оружја и се борат едни со други во тимови 6v6.

И клиентот и серверот се базираат на Unity. Архитектурата е прилично класична за стрелците: серверот е авторитарен, а предвидувањето на клиентот работи на клиентите. Симулацијата на играта е напишана со користење на ECS во куќата и се користи и на серверот и на клиентот.

Ако ова е прв пат да слушате за компензација на доцнење, еве една кратка екскурзија во ова прашање.

Во FPS игрите со повеќе играчи, натпреварот обично се симулира на оддалечен сервер. Играчите го испраќаат својот влез (информации за притиснати копчиња) до серверот, а како одговор серверот им испраќа ажурирана состојба на играта земајќи ги предвид примените податоци. Со оваа шема за интеракција, доцнењето помеѓу притискањето на копчето напред и моментот кога ликот на играчот се движи на екранот секогаш ќе биде поголемо од пингот.

Додека на локалните мрежи ова доцнење (популарно наречено влезно задоцнување) може да биде незабележливо, кога се игра преку Интернет создава чувство на „лизгање на мраз“ кога се контролира ликот. Овој проблем е двојно релевантен за мобилните мрежи, каде што случајот кога пингот на играчот е 200 ms сè уште се смета за одлична врска. Честопати пингот може да биде 350, 500 или 1000 ms. Тогаш станува речиси невозможно да се игра брз шутер со влезно задоцнување.

Решението за овој проблем е предвидување на симулација од страна на клиентот. Овде самиот клиент го применува внесувањето на карактерот на играчот, без да чека одговор од серверот. И кога ќе се добие одговорот, тој едноставно ги споредува резултатите и ги ажурира позициите на противниците. Доцнењето помеѓу притискање на копче и прикажување на резултатот на екранот во овој случај е минимално.

Важно е да се разбере нијансата овде: клиентот секогаш се црта според последниот влез, а непријателите - со доцнење на мрежата, според претходната состојба од податоците од серверот. Односно, кога пука во непријател, играчот го гледа во минатото во однос на себе. Повеќе за предвидување на клиентот напишавме претходно.

Така, предвидувањето на клиентот решава еден проблем, но создава друг: ако играчот пука на местото каде што бил непријателот во минатото, на серверот кога пука во истата точка, непријателот можеби повеќе не е на тоа место. Компензацијата на доцнењето на серверот се обидува да го реши овој проблем. Кога ќе се пука од оружје, серверот ја враќа состојбата на играта што играчот ја видел локално во моментот на истрелот и проверува дали навистина можел да го погоди непријателот. Ако одговорот е „да“, ударот се брои, дури и ако непријателот повеќе не е на серверот во тој момент.

Вооружени со ова знаење, почнавме да спроведуваме компензација за доцнење на серверот во Dino Squad. Пред сè, моравме да разбереме како да го вратиме на серверот она што го видел клиентот? И што точно треба да се обнови? Во нашата игра, ударите од оружје и способности се пресметуваат преку зраци и преклопувања - односно преку интеракции со физичките судири на непријателот. Соодветно, требаше да ја репродуцираме позицијата на овие судири, кои играчот ги „виде“ локално, на серверот. Во тоа време ја користевме верзијата Unity 2018.x. АПИ за физика таму е статичен, физичкиот свет постои во една копија. Не постои начин да се зачува неговата состојба и потоа да се врати од кутијата. Па што да се прави?

Решението беше на површината; сите негови елементи веќе беа искористени од нас за решавање на други проблеми:

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-виот штиклирање, во овој случај, компензацијата на задоцнување повеќе не се применува

Во нашата имплементација, овие два пристапа се разликуваа во само неколку линии код, така што ги создадовме и двата, и долго време тие постоеја паралелно. Во зависност од механиката на оружјето и брзината на куршумот, избравме една или друга опција за секој диносаурус. Пресвртна точка овде беше појавувањето во играта на механиката како „ако го погодиш непријателот толку пати во такво и такво време, добиј таков и таков бонус“. Секој механичар каде што времето во кое играчот го погоди непријателот одигра важна улога, одби да работи со вториот пристап. Така, завршивме со првата опција, и таа сега се однесува на сите оружја и сите активни способности во играта.

Одделно, вреди да се подигне прашањето за перформансите. Ако мислевте дека сето ова ќе ги забави работите, одговарам: тоа е. Единството е прилично бавно во движењето на судирите и нивното вклучување и исклучување. Во 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 Hz). Ова им овозможува на играчите да ги погодат противниците дури и при многу високи пингови.

2. Определи кои предмети може да се преместуваат навреме, а кои не.

Ние, се разбира, ги раздвижуваме нашите противници. Но, на пример, енергетските штитови што можат да се инсталираат, не се. Решивме дека е подобро да се даде приоритет на одбранбената способност, како што често се прави во онлајн стрелците. Ако играчот веќе поставил штит во сегашноста, куршумите од минатото со компензирање на заостанување не треба да летаат низ него.

3. Одлучете дали е неопходно да се компензира за способностите на диносаурусите: каснување, удар со опашка итн. Одлучивме што е потребно и ги обработуваме според истите правила како куршумите.

4. Определете што да правите со судирите на играчот за кој се врши компензација на заостанување. На добар начин, нивната позиција не треба да се префрли во минатото: играчот треба да се гледа себеси во исто време кога е сега на серверот. Сепак, ги враќаме и судирите на шутерскиот играч, а има неколку причини за тоа.

Прво, го подобрува кластерирањето: можеме да ја користиме истата физичка состојба за сите играчи со блиски пингови.

Второ, при сите зраци и преклопувања секогаш ги исклучуваме судирите на играчот кој ги поседува способностите или проектилите. Во Dino Squad, играчите контролираат диносауруси, кои имаат прилично нестандардна геометрија според стандардите на стрелците. Дури и ако играчот пука под необичен агол и траекторијата на куршумот помине низ судирот на диносаурусите на играчот, куршумот ќе го игнорира.

Трето, ги пресметуваме позициите на оружјето на диносаурусот или точката на примена на способноста користејќи податоци од ECS дури и пред почетокот на компензацијата на доцнењето.

Како резултат на тоа, вистинската позиција на судирите на играчот со компензирање на заостанување ни е неважна, па тргнавме по попродуктивен и во исто време поедноставен пат.

Латентноста на мрежата не може едноставно да се отстрани, таа може само да се маскира. Како и секој друг метод на маскирање, компензацијата на доцнењето на серверот има свои компромиси. Го подобрува гејмерското искуство на играчот кој шутира на сметка на играчот кон кој се пука. За Дино Сквад, сепак, изборот овде беше очигледен.

Се разбира, сето ова мораше да се плати и со зголемената сложеност на кодот на серверот како целина - и за програмерите и за дизајнерите на игри. Ако порано симулацијата беше едноставно секвенцијално повикување на системи, тогаш со компензација на заостанување, во него се појавија вгнездени јамки и гранки. Исто така, потрошивме многу напор за да биде погодно за работа.

Во верзијата од 2019 година (а можеби и малку порано), Unity додаде целосна поддршка за независни физички сцени. Ги имплементиравме на серверот речиси веднаш по ажурирањето, бидејќи сакавме брзо да се ослободиме од физичкиот свет заеднички за сите простории.

На секоја соба за игри и дадовме своја физичка сцена и на тој начин ја елиминиравме потребата да се „исчисти“ сцената од податоците на соседната просторија пред да се пресмета симулацијата. Прво, тоа даде значително зголемување на продуктивноста. Второ, овозможи да се ослободиме од цела класа на грешки што се појавија ако програмерот направи грешка во кодот за чистење на сцената при додавање нови елементи на играта. Ваквите грешки тешко се дебагираа, и тие често резултираа со состојбата на физичките предмети во сцената на една просторија што „течеа“ во друга просторија.

Дополнително, направивме одредено истражување за тоа дали физичките сцени може да се користат за складирање на историјата на физичкиот свет. Односно, условно, не одвојувајте една сцена во секоја соба, туку 30 сцени и од нив направете цикличен тампон, во кој ќе ја зачувате приказната. Општо земено, опцијата се покажа дека работи, но ние не ја имплементиравме: не покажа лудо зголемување на продуктивноста, туку бараше прилично ризични промени. Беше тешко да се предвиди како ќе се однесува серверот кога ќе работи долго време со толку многу сцени. Затоа, го следевме правилото:Ако не се скрши, не го поправајте".

Извор: www.habr.com