Sut y gwnaethom fecanwaith cyfrifo balistig ar gyfer saethwr symudol gydag algorithm iawndal oedi rhwydwaith

Helo, Nikita Brizhak ydw i, datblygwr gweinydd o Pixonic. Heddiw hoffwn siarad am wneud iawn am oedi mewn aml-chwaraewr symudol.

Mae llawer o erthyglau wedi'u hysgrifennu am iawndal oedi gweinydd, gan gynnwys yn Rwsieg. Nid yw hyn yn syndod, gan fod y dechnoleg hon wedi'i defnyddio'n weithredol wrth greu FPS aml-chwaraewr ers diwedd y 90au. Er enghraifft, gallwch chi gofio'r mod QuakeWorld, a oedd yn un o'r rhai cyntaf i'w ddefnyddio.

Rydyn ni hefyd yn ei ddefnyddio yn ein saethwr aml-chwaraewr symudol Dino Squad.

Yn yr erthygl hon, nid fy nod yw ailadrodd yr hyn sydd eisoes wedi'i ysgrifennu fil o weithiau, ond dweud sut y gwnaethom weithredu iawndal oedi yn ein gêm, gan ystyried ein pentwr technoleg a'n nodweddion gameplay craidd.

Ychydig eiriau am ein cortecs a thechnoleg.

Mae Dino Squad yn saethwr PvP symudol rhwydwaith. Mae chwaraewyr yn rheoli deinosoriaid sydd ag amrywiaeth o arfau ac yn ymladd ei gilydd mewn timau 6v6.

Mae'r cleient a'r gweinydd yn seiliedig ar Unity. Mae'r bensaernïaeth yn eithaf clasurol i saethwyr: mae'r gweinydd yn awdurdodaidd, ac mae rhagfynegiad cleient yn gweithio ar y cleientiaid. Mae'r efelychiad gêm yn cael ei ysgrifennu gan ddefnyddio ECS mewnol ac yn cael ei ddefnyddio ar y gweinydd a'r cleient.

Os mai dyma’r tro cyntaf ichi glywed am iawndal oedi, dyma wibdaith fer i’r mater.

Mewn gemau FPS aml-chwaraewr, mae'r ornest fel arfer yn cael ei efelychu ar weinydd pell. Mae chwaraewyr yn anfon eu mewnbwn (gwybodaeth am yr allweddi wedi'u gwasgu) i'r gweinydd, ac mewn ymateb mae'r gweinydd yn anfon cyflwr gêm wedi'i ddiweddaru iddynt gan ystyried y data a dderbyniwyd. Gyda'r cynllun rhyngweithio hwn, bydd yr oedi rhwng pwyso'r allwedd ymlaen a'r foment y mae cymeriad y chwaraewr yn symud ar y sgrin bob amser yn fwy na'r ping.

Tra ar rwydweithiau lleol efallai na fydd yr oedi hwn (a elwir yn boblogaidd yn lag mewnbwn) yn amlwg, wrth chwarae dros y Rhyngrwyd mae'n creu teimlad o “lithro ar rew” wrth reoli cymeriad. Mae'r broblem hon ddwywaith yn berthnasol i rwydweithiau symudol, lle mae'r achos pan fo ping chwaraewr yn 200 ms yn dal i gael ei ystyried yn gysylltiad rhagorol. Yn aml gall y ping fod yn 350, 500, neu 1000 ms. Yna mae'n dod yn bron yn amhosibl chwarae saethwr cyflym gydag oedi mewnbwn.

Yr ateb i'r broblem hon yw rhagfynegiad efelychu ochr y cleient. Yma mae'r cleient ei hun yn cymhwyso'r mewnbwn i gymeriad y chwaraewr, heb aros am ymateb gan y gweinydd. A phan dderbynnir yr ateb, mae'n syml yn cymharu'r canlyniadau ac yn diweddaru safbwyntiau'r gwrthwynebwyr. Ychydig iawn o oedi rhwng pwyso allwedd ac arddangos y canlyniad ar y sgrin yn yr achos hwn.

Mae'n bwysig deall y naws yma: mae'r cleient bob amser yn tynnu ei hun yn ôl ei fewnbwn olaf, a gelynion - gydag oedi rhwydwaith, yn ôl y cyflwr blaenorol o'r data o'r gweinydd. Hynny yw, wrth saethu at elyn, mae'r chwaraewr yn ei weld yn y gorffennol yn berthynas iddo'i hun. Mwy am ragfynegiad cleient ysgrifenasom yn gynharach.

Felly, mae rhagfynegiad cleient yn datrys un broblem, ond yn creu un arall: os yw chwaraewr yn saethu ar y pwynt lle'r oedd y gelyn yn y gorffennol, ar y gweinydd wrth saethu ar yr un pwynt, efallai na fydd y gelyn yn y lle hwnnw mwyach. Mae iawndal oedi gweinydd yn ceisio datrys y broblem hon. Pan fydd arf yn cael ei danio, mae'r gweinydd yn adfer cyflwr y gêm a welodd y chwaraewr yn lleol ar adeg yr ergyd, ac yn gwirio a allai fod wedi taro'r gelyn mewn gwirionedd. Os mai'r ateb yw "ie," mae'r ergyd yn cael ei gyfrif, hyd yn oed os nad yw'r gelyn bellach ar y gweinydd bryd hynny.

Gyda'r wybodaeth hon, fe wnaethom ddechrau gweithredu iawndal oedi gweinyddwr yn Dino Squad. Yn gyntaf oll, roedd yn rhaid i ni ddeall sut i adfer ar y gweinydd yr hyn a welodd y cleient? A beth yn union sydd angen ei adfer? Yn ein gêm, mae trawiadau o arfau a galluoedd yn cael eu cyfrifo trwy belydriadau a throshaenau - hynny yw, trwy ryngweithio â gwrthdrawiadau corfforol y gelyn. Yn unol â hynny, roedd angen i ni atgynhyrchu lleoliad y gwrthdrawiadau hyn, a “welodd” y chwaraewr yn lleol, ar y gweinydd. Bryd hynny roeddem yn defnyddio fersiwn Unity 2018.x. Mae'r API ffiseg yno yn sefydlog, mae'r byd ffisegol yn bodoli mewn un copi. Nid oes unrhyw ffordd i achub ei gyflwr ac yna ei adfer o'r blwch. Felly beth i'w wneud?

Roedd yr ateb ar yr wyneb; roedd ei holl elfennau eisoes wedi cael eu defnyddio gennym ni i ddatrys problemau eraill:

1. Ar gyfer pob cleient, mae angen inni wybod faint o'r gloch y gwelodd wrthwynebwyr pan bwysodd yr allweddi. Rydym eisoes wedi ysgrifennu'r wybodaeth hon yn y pecyn mewnbwn a'i ddefnyddio i addasu rhagfynegiad y cleient.
2. Mae angen inni allu storio hanes gwladwriaethau gêm. Ynddo y byddwn yn dal safleoedd ein gwrthwynebwyr (ac felly eu gwrthdrawiadwyr). Roedd gennym ni hanes y wladwriaeth eisoes ar y gweinydd, fe wnaethon ni ei ddefnyddio i adeiladu deltas. Gan wybod yr amser iawn, gallem yn hawdd ddod o hyd i'r cyflwr cywir mewn hanes.
3. Nawr bod gennym gyflwr y gêm o hanes mewn llaw, mae angen inni allu cydamseru data chwaraewyr â chyflwr y byd ffisegol. Gwrthdarwyr presennol - symud, colli rhai - creu, rhai diangen - dinistrio. Roedd y rhesymeg hon eisoes wedi'i hysgrifennu ac roedd yn cynnwys sawl system ECS. Fe wnaethon ni ei ddefnyddio i gynnal sawl ystafell gêm mewn un broses Unity. A chan fod y byd corfforol yn un i bob proses, roedd yn rhaid ei ailddefnyddio rhwng ystafelloedd. Cyn pob tic o'r efelychiad, fe wnaethom "ailosod" cyflwr y byd corfforol a'i ail-gychwyn â data ar gyfer yr ystafell bresennol, gan geisio ailddefnyddio gwrthrychau gêm Unity gymaint â phosibl trwy system gronni glyfar. Y cyfan oedd ar ôl oedd defnyddio'r un rhesymeg ar gyfer y cyflwr gêm o'r gorffennol.

Trwy roi’r holl elfennau hyn at ei gilydd, fe gawson ni “beiriant amser” a allai dreiglo cyflwr y byd corfforol yn ôl i’r eiliad iawn. Trodd y cod allan i fod yn syml:

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;
     }
}

Y cyfan oedd ar ôl oedd darganfod sut i ddefnyddio'r peiriant hwn i wneud iawn yn hawdd am ergydion a galluoedd.

Yn yr achos symlaf, pan fydd y mecaneg yn seiliedig ar un hitscan, mae'n ymddangos bod popeth yn glir: cyn i'r chwaraewr saethu, mae angen iddo rolio'r byd corfforol yn ôl i'r cyflwr dymunol, gwneud raycast, cyfrif y taro neu'r colli, a dychwelyd y byd i'r cyflwr cychwynnol.

Ond ychydig iawn o fecanegau o'r fath sydd yn Sgwad Dino! Mae'r rhan fwyaf o'r arfau yn y gêm yn creu projectiles - bwledi hirhoedlog sy'n hedfan am sawl trogod efelychu (mewn rhai achosion, dwsinau o drogod). Beth i'w wneud â nhw, faint o'r gloch ddylen nhw hedfan?

В erthygl hynafol am y pentwr rhwydwaith Half-Life, gofynnodd y dynion o Falf yr un cwestiwn, a'u hateb oedd hyn: mae iawndal oedi projectile yn broblemus, ac mae'n well ei osgoi.

Nid oedd gennym yr opsiwn hwn: roedd arfau yn seiliedig ar daflegrau yn nodwedd allweddol o ddyluniad y gêm. Felly roedd yn rhaid i ni feddwl am rywbeth. Ar ôl ychydig o drafod syniadau, gwnaethom lunio dau opsiwn a oedd i'w gweld yn gweithio:

1. Rydyn ni'n clymu'r taflunydd ag amser y chwaraewr a'i creodd. Pob tic o'r efelychiad gweinydd, ar gyfer pob bwled o bob chwaraewr, rydym yn rholio'r byd ffisegol yn ôl i gyflwr y cleient ac yn gwneud y cyfrifiadau angenrheidiol. Roedd y dull hwn yn ei gwneud hi'n bosibl cael llwyth gwasgaredig ar y gweinydd ac amser hedfan rhagweladwy tafluniau. Roedd rhagweladwyedd yn arbennig o bwysig i ni, gan fod gennym yr holl daflegrau, gan gynnwys tafluniau gelyn, a ragwelir ar y cleient.

Yn y llun, mae'r chwaraewr yn tic 30 yn tanio taflegryn yn y disgwyl: mae'n gweld i ba gyfeiriad y mae'r gelyn yn rhedeg ac mae'n gwybod cyflymder bras y taflegryn. Yn lleol mae'n gweld ei fod wedi taro'r targed ar y 33ain tic. Diolch i iawndal oedi, bydd hefyd yn ymddangos ar y gweinydd

2. Rydym yn gwneud popeth yr un fath ag yn yr opsiwn cyntaf, ond, ar ôl cyfrif un tic o'r efelychiad bwled, nid ydym yn stopio, ond yn parhau i efelychu ei hedfan o fewn yr un tic gweinydd, bob tro yn dod â'i amser yn agosach at y gweinydd tic un wrth un a diweddaru safleoedd y gwrthdrawiad. Gwnawn hyn nes bod un o ddau beth yn digwydd:

• Mae'r fwled wedi dod i ben. Mae hyn yn golygu bod y cyfrifiadau wedi dod i ben, gallwn gyfrif colli neu ergyd. A dyma ar yr un tic ag y taniwyd yr ergyd! I ni roedd hyn yn fantais a minws. Mantais ychwanegol - oherwydd i'r chwaraewr saethu, gostyngodd hyn yn sylweddol yr oedi rhwng yr ergyd a'r gostyngiad yn iechyd y gelyn. Yr anfantais yw y gwelwyd yr un effaith pan daniodd gwrthwynebwyr at y chwaraewr: dim ond roced araf y taniodd y gelyn, mae'n ymddangos, ac roedd y difrod eisoes wedi'i gyfrif.
• Mae'r bwled wedi cyrraedd amser y gweinydd. Yn yr achos hwn, bydd ei efelychiad yn parhau yn y tic gweinydd nesaf heb unrhyw iawndal oedi. Ar gyfer taflunyddion araf, gallai hyn, yn ddamcaniaethol, leihau nifer y dychweliadau ffiseg o gymharu â'r opsiwn cyntaf. Ar yr un pryd, cynyddodd y llwyth anwastad ar yr efelychiad: roedd y gweinydd naill ai'n segur, neu mewn un tic gweinydd roedd yn cyfrifo dwsin o diciau efelychu ar gyfer sawl bwled.

Yr un senario ag yn y llun blaenorol, ond wedi'i gyfrifo yn ôl yr ail gynllun. Mae'r taflegryn “dal i fyny” gydag amser y gweinydd ar yr un tic ag y digwyddodd yr ergyd, a gellir cyfrif y taro mor gynnar â'r tic nesaf. Ar y 31ain tic, yn yr achos hwn, nid yw iawndal oedi yn cael ei gymhwyso mwyach

Yn ein gweithrediad, roedd y ddau ddull hyn yn wahanol mewn dim ond cwpl o linellau o god, felly fe wnaethon ni greu'r ddau, ac am amser hir roeddent yn bodoli ochr yn ochr. Yn dibynnu ar fecaneg yr arf a chyflymder y bwled, fe wnaethon ni ddewis un neu opsiwn arall ar gyfer pob deinosor. Y trobwynt yma oedd ymddangosiad mecaneg yn y gêm fel “os ydych chi'n taro'r gelyn gymaint o weithiau mewn amser o'r fath, mynnwch fonws o'r fath.” Gwrthododd unrhyw fecanig lle'r oedd yr amser y mae'r chwaraewr yn taro'r gelyn yn chwarae rhan bwysig i weithio gyda'r ail ddull. Felly fe aethon ni i ben gyda'r opsiwn cyntaf, ac mae bellach yn berthnasol i bob arf a phob gallu gweithredol yn y gêm.

Ar wahân, mae'n werth codi mater perfformiad. Os oeddech yn meddwl y byddai hyn i gyd yn arafu pethau, yr wyf yn ateb: y mae. Mae undod yn eithaf araf yn symud gwrthdrawiadwyr a'u troi ymlaen ac i ffwrdd. Yn Sgwad Dino, mewn senario "gwaethaf", gall fod cannoedd o daflegrau yn bodoli ar yr un pryd wrth ymladd. Mae symud gwrthdrawiadwyr i gyfrif pob taflunydd yn unigol yn foethusrwydd anfforddiadwy. Felly, roedd yn gwbl angenrheidiol i ni leihau nifer yr “esgyniadau” ffiseg. I wneud hyn, rydym wedi creu cydran ar wahân yn ECS lle rydym yn cofnodi amser y chwaraewr. Fe wnaethom ei ychwanegu at bob endid sydd angen iawndal oedi (prosiectau, galluoedd, ac ati). Cyn i ni ddechrau prosesu endidau o'r fath, rydym yn eu clystyru erbyn hyn ac yn eu prosesu gyda'i gilydd, gan rolio'r byd ffisegol yn ôl unwaith ar gyfer pob clwstwr.

Ar hyn o bryd mae gennym system sy'n gweithio'n gyffredinol. Ei god ar ffurf ychydig yn symlach:

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);
               }
          }
     }
}

Y cyfan oedd ar ôl oedd ffurfweddu'r manylion:

1. Deall faint i gyfyngu ar y pellter symud mwyaf mewn amser.

Roedd yn bwysig i ni wneud y gêm mor hygyrch â phosibl mewn amodau o rwydweithiau symudol gwael, felly fe wnaethom gyfyngu'r stori gydag ymyl o 30 tic (gyda chyfradd dicio o 20 Hz). Mae hyn yn galluogi chwaraewyr i daro gwrthwynebwyr hyd yn oed ar pings uchel iawn.

2. Penderfynwch pa wrthrychau y gellir eu symud mewn amser a pha rai na allant.

Rydyn ni, wrth gwrs, yn symud ein gwrthwynebwyr. Ond nid yw tariannau ynni gosodadwy, er enghraifft, yn wir. Fe wnaethom benderfynu ei bod yn well rhoi blaenoriaeth i'r gallu amddiffynnol, fel sy'n cael ei wneud yn aml mewn saethwyr ar-lein. Os yw'r chwaraewr eisoes wedi gosod tarian yn y presennol, ni ddylai bwledi iawndal o'r gorffennol hedfan drwyddi.

3. Penderfynwch a oes angen gwneud iawn am alluoedd y deinosoriaid: brathiad, taro cynffon, ac ati. Fe wnaethom benderfynu beth oedd ei angen a'u prosesu yn unol â'r un rheolau â bwledi.

4. Penderfynwch beth i'w wneud â gwrthdrawiadwyr y chwaraewr y mae iawndal oedi yn cael ei berfformio ar ei gyfer. Mewn ffordd dda, ni ddylai eu safle symud i'r gorffennol: dylai'r chwaraewr weld ei hun yn yr un amser ag y mae bellach ar y gweinydd. Fodd bynnag, rydym hefyd yn rholio yn ôl y gwrthdrawiadwyr y chwaraewr saethu, ac mae sawl rheswm am hyn.

Yn gyntaf, mae'n gwella clystyru: gallwn ddefnyddio'r un cyflwr corfforol ar gyfer pob chwaraewr gyda phingiau agos.

Yn ail, ym mhob pelydr-ddarllediadau a gorgyffwrdd rydym bob amser yn cau allan y gwrthdrawiadwyr y chwaraewr sy'n berchen ar y galluoedd neu projectiles. Yn Sgwad Dino, mae chwaraewyr yn rheoli deinosoriaid, sydd â geometreg braidd yn ansafonol yn ôl safonau saethwr. Hyd yn oed os yw'r chwaraewr yn saethu ar ongl anarferol a thaflwybr y bwled yn mynd trwy wrthdrawwr deinosor y chwaraewr, bydd y bwled yn ei anwybyddu.

Yn drydydd, rydym yn cyfrifo lleoliad arf y deinosor neu bwynt cymhwyso'r gallu gan ddefnyddio data o'r ECS hyd yn oed cyn dechrau iawndal oedi.

O ganlyniad, nid yw sefyllfa wirioneddol gwrthdrawiadwyr y chwaraewr sy'n cael ei ddigolledu ag oedi yn bwysig i ni, felly fe wnaethom gymryd llwybr mwy cynhyrchiol ac ar yr un pryd symlach.

Ni ellir dileu hwyrni rhwydwaith yn syml, dim ond ei guddio y gellir ei guddio. Fel unrhyw ddull arall o guddio, mae gan iawndal oedi gweinyddwr ei gyfaddawdau. Mae'n gwella profiad hapchwarae'r chwaraewr sy'n saethu ar draul y chwaraewr sy'n cael ei saethu. I Sgwad Dino, fodd bynnag, roedd y dewis yma yn amlwg.

Wrth gwrs, roedd yn rhaid talu am hyn i gyd hefyd gan gymhlethdod cynyddol cod y gweinydd yn ei gyfanrwydd - ar gyfer rhaglenwyr a dylunwyr gemau. Os yn gynharach roedd yr efelychiad yn alwad ddilyniannol syml o systemau, yna gydag iawndal oedi, roedd dolenni nythu a changhennau yn ymddangos ynddo. Fe wnaethom hefyd wario llawer o ymdrech i'w wneud yn gyfleus i weithio gydag ef.

Yn fersiwn 2019 (ac efallai ychydig yn gynharach), ychwanegodd Unity gefnogaeth lawn i olygfeydd corfforol annibynnol. Fe wnaethon ni eu gweithredu ar y gweinydd bron yn syth ar ôl y diweddariad, oherwydd ein bod ni eisiau cael gwared yn gyflym ar y byd corfforol sy'n gyffredin i bob ystafell.

Fe wnaethon ni roi ei olygfa gorfforol ei hun i bob ystafell gêm ac felly dileu'r angen i “glirio” yr olygfa o ddata'r ystafell gyfagos cyn cyfrifo'r efelychiad. Yn gyntaf, rhoddodd gynnydd sylweddol mewn cynhyrchiant. Yn ail, roedd yn ei gwneud hi'n bosibl cael gwared ar ddosbarth cyfan o fygiau a gododd pe bai'r rhaglennydd yn gwneud gwall yn y cod glanhau golygfa wrth ychwanegu elfennau gêm newydd. Roedd gwallau o'r fath yn anodd eu dadfygio, ac roeddent yn aml yn arwain at gyflwr gwrthrychau corfforol mewn golygfa un ystafell yn "llifo" i ystafell arall.

Yn ogystal, gwnaethom rywfaint o ymchwil i weld a ellid defnyddio golygfeydd ffisegol i storio hanes y byd ffisegol. Hynny yw, yn amodol, dyrannwch nid un olygfa i bob ystafell, ond 30 golygfa, a gwnewch glustogfa gylchol ohonynt, i storio'r stori. Yn gyffredinol, roedd yr opsiwn yn gweithio, ond ni wnaethom ei weithredu: nid oedd yn dangos unrhyw gynnydd gwallgof mewn cynhyrchiant, ond roedd angen newidiadau eithaf peryglus. Roedd yn anodd rhagweld sut y byddai'r gweinydd yn ymddwyn wrth weithio am amser hir gyda chymaint o olygfeydd. Felly, fe wnaethon ni ddilyn y rheol: “Os nad yw wedi torri, peidiwch â'i drwsio'.

Ffynhonnell: hab.com