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

Здравейте, аз съм Никита Брижак, разработчик на сървъри от Pixonic. Днес бих искал да говоря за компенсиране на изоставането в мобилния мултиплейър.

Много статии са написани за компенсиране на забавяне на сървъра, включително на руски език. Това не е изненадващо, тъй като тази технология се използва активно при създаването на мултиплейър FPS от края на 90-те години. Например, можете да си спомните мода QuakeWorld, който беше един от първите, които го използваха.

Използваме го и в нашия мобилен мултиплейър шутър Dino Squad.

В тази статия целта ми не е да повтарям това, което вече е написано хиляди пъти, а да разкажа как внедрихме компенсация на забавяне в нашата игра, като взехме предвид нашия технологичен стек и основните характеристики на играта.

Няколко думи за нашия кортекс и технология.

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

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

Ако за първи път чувате за компенсация за изоставане, ето кратка екскурзия в проблема.

В FPS игрите за много играчи мачът обикновено се симулира на отдалечен сървър. Играчите изпращат своя вход (информация за натиснатите клавиши) на сървъра и в отговор сървърът им изпраща актуализирано състояние на играта, като взема предвид получените данни. С тази схема на взаимодействие забавянето между натискането на клавиша за напред и момента, в който персонажът на играча се премести на екрана, винаги ще бъде по-голямо от пинга.

Докато в локалните мрежи това забавяне (популярно наричано забавяне на входа) може да е незабележимо, когато играете през интернет, то създава усещане за „плъзгане по лед“ при управление на герой. Този проблем е двойно актуален за мобилните мрежи, където случайът, когато ping на играча е 200 ms, все още се счита за отлична връзка. Често пингът може да бъде 350, 500 или 1000 ms. Тогава става почти невъзможно да играете бърз стрелец със забавяне на входа.

Решението на този проблем е прогнозиране на симулация от страна на клиента. Тук самият клиент прилага входа към героя на играча, без да чака отговор от сървъра. И когато се получи отговор, той просто сравнява резултатите и актуализира позициите на опонентите. Закъснението между натискане на клавиш и показване на резултата на екрана в този случай е минимално.

Тук е важно да разберете нюанса: клиентът винаги се чертае според последното му въвеждане, а враговете - с мрежово забавяне, според предишното състояние от данните от сървъра. Тоест, когато стреля по враг, играчът го вижда в миналото спрямо себе си. Повече за прогнозирането на клиента писахме по-рано.

По този начин прогнозирането на клиента решава един проблем, но създава друг: ако играч стреля в точката, където врагът е бил в миналото, на сървъра, когато стреля в същата точка, врагът може вече да не е на това място. Компенсацията за забавяне на сървъра се опитва да реши този проблем. Когато се стреля с оръжие, сървърът възстановява състоянието на играта, което играчът е видял локално в момента на изстрела, и проверява дали наистина е могъл да удари врага. Ако отговорът е „да“, ударът се зачита, дори ако врагът вече не е на сървъра в този момент.

Въоръжени с това знание, започнахме да прилагаме компенсация за забавяне на сървъра в 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 Hz). Това позволява на играчите да удрят опоненти дори при много висок пинг.

2. Определете кои обекти могат да бъдат преместени във времето и кои не.

Ние, разбира се, движим нашите опоненти. Но монтируемите енергийни щитове, например, не са. Решихме, че е по-добре да дадем приоритет на защитните способности, както често се прави в онлайн шутърите. Ако играчът вече е поставил щит в настоящето, куршуми от миналото с компенсация на забавянето не трябва да летят през него.

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

4. Определете какво да правите с колайдърите на играча, за когото се извършва компенсация на изоставането. В добър смисъл тяхната позиция не трябва да се измества в миналото: играчът трябва да вижда себе си в същото време, в което е сега на сървъра. Въпреки това, ние също така връщаме назад колайдерите на стрелящия играч и има няколко причини за това.

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

Второ, във всички лъчеви предавания и припокривания ние винаги изключваме колайдерите на играча, който притежава способностите или снарядите. В Dino Squad играчите контролират динозаври, които имат доста нестандартна геометрия според стандартите на стрелците. Дори ако играчът стреля под необичаен ъгъл и траекторията на куршума минава през динозавър колайдера на играча, куршумът ще го игнорира.

Трето, ние изчисляваме позициите на оръжието на динозавъра или точката на приложение на способността, използвайки данни от ECS дори преди началото на компенсацията на забавянето.

В резултат на това реалната позиция на колайдерите на играча с компенсиран лаг не е важна за нас, така че поехме по-продуктивен и в същото време по-прост път.

Латентността на мрежата не може просто да бъде премахната, тя може само да бъде маскирана. Както всеки друг метод за прикриване, компенсацията на забавянето на сървъра има своите компромиси. Подобрява игровото изживяване на играча, който стреля, за сметка на играча, по който се стреля. За Dino Squad обаче изборът тук беше очевиден.

Разбира се, всичко това трябваше да бъде платено и от повишената сложност на сървърния код като цяло - както за програмисти, така и за дизайнери на игри. Ако по-рано симулацията беше просто последователно извикване на системи, тогава с компенсация на забавяне в нея се появиха вложени цикли и клонове. Освен това положихме много усилия, за да го направим удобен за работа.

Във версията от 2019 г. (и може би малко по-рано) Unity добави пълна поддръжка за независими физически сцени. Ние ги внедрихме на сървъра почти веднага след актуализацията, защото искахме бързо да се отървем от физическия свят, общ за всички стаи.

Дадохме на всяка игрална зала своя собствена физическа сцена и по този начин елиминирахме необходимостта от „изчистване“ на сцената от данните на съседната стая, преди да изчислим симулацията. Първо, това значително увеличи производителността. Второ, това направи възможно да се отървете от цял ​​клас грешки, които възникнаха, ако програмистът направи грешка в кода за почистване на сцената при добавяне на нови елементи на играта. Такива грешки бяха трудни за отстраняване и те често водеха до състояние на физически обекти в сцената на една стая, „преливаща“ в друга стая.

Освен това направихме някои изследвания дали физическите сцени могат да се използват за съхраняване на историята на физическия свят. Тоест, условно, разпределете не една сцена за всяка стая, а 30 сцени и направете от тях цикличен буфер, в който да съхранявате историята. Като цяло опцията се оказа работеща, но не я внедрихме: не показа лудо увеличение на производителността, но изискваше доста рисковани промени. Беше трудно да се предвиди как ще се държи сървърът, когато работи дълго време с толкова много сцени. Затова следвахме правилото: „Ако не се счупи, не го отстранявайте".

Източник: www.habr.com