Megapakett: kuidas suudavad Factorio arendajad lahendada 200 mängija mängimise probleemid

Sel aasta mais osalesin mängijana KatherineOfSky MMO-sündmusel. Märkasin, et kui mängijate arv jõuab teatud piirini, katkeb osa neist iga paari minuti tagant. Õnneks teie jaoks (kuid mitte minu jaoks) olin ma üks nendest mängijatest, kes katkestas igal korral, isegi hea ühenduse korral. Võtsin seda kui isiklikku väljakutset ja hakkasin otsima probleemi põhjuseid. Pärast kolme nädala pikkust tõrkeotsingut, testimist ja parandusi suudeti viga lõpuks kõrvaldada, kuid see teekond polnud sugugi lihtne.

Mitme mängija mängude probleemide jälgimine on väga keeruline. Need tekivad tavaliselt väga spetsiifiliste võrguparameetrite ja mängu konkreetsete tingimuste korral (antud juhul - üle 200 mängija olemasolu). Isegi kui probleemi õnnestub korrata, ei saa seda korralikult siluda, kuna kontrollpunktide sisestamine peatab mängu, segab ajastust ja viib tavaliselt ühenduse katkestamiseni ajapiirangute tõttu. Kuid tänu visadusele ja suurepärasele tööriistale nimega clumsy õnnestus mul välja selgitada, mis toimub.

Kokkuvõttes: simuleerimise viivituste viga ja mittetäielik rakendamine põhjustas olukorra, kus klient pidi mõnikord ühes tsüklis saatma võrku paketi, mis sisaldas umbes 400 mänguobjekti tegevust (me nimetame seda „megapakendiks“). Pärast seda peab server mitte ainult kõiki neid sisendi tegevusi õigesti vastu võtma, vaid ka need kõigile teistele klientidele edastama. Kui sul on 200 klienti, muutub see kiiresti probleemiks. Serverikanal täitub kiiresti, mis viib pakettide kadumiseni ja nõutud pakettide kaskaadi. Sisendi viivitamine toob kaasa veelgi rohkem kliente, kes hakkavad megapakette saatma, ja nende laviin suureneb veelgi. Õnnelikud kliendid suudavad taastuda, kõik teised aga „langevad välja“.


Probleem oli piisavalt fundamentaalne ja selle lahendamine võttis mul kaks nädalat. See on üsna tehniline, seetõttu selgitan allpool mõned olulisemad tehnilised üksikasjad. Kuid esmalt peate teadma, et alates versioonist 0.17.54, mis ilmus 4. juunil, on võrguühenduse probleemide korral mitmikmängu stabiilsus paranenud ning viivituste varjamine on palju vähem häiriv (vähem tõrkeid ja teleportimist). Lisaks olen muutnud viivituste varjamise meetodit lahingus ning loodan, et need on seeläbi natuke sujuvamad.

Mitmikmängu megapakett — tehnilised üksikasjad

Lihtsalt seletades töötab mängus mitmikmäng järgmiselt: kõik kliendid simuleerivad mängu seisundit, saates ja vastu võttes ainult mängija sisendeid (mida nimetatakse 'sisendtoiminguteks', Input Actions). Serveri peamine ülesanne on tagada Input Actions ja kontrollida, et kõik kliendid teevad ühes taktis samu toiminguid. Selle kohta saate rohkem lugeda postitusest FFF-149.

Kuna server peab otsustama, milliseid toiminguid teha, liiguvad mängija tegevused ligikaudu järgmise tee kaudu: mängija tegevus -> mänguklient -> võrk -> server -> võrk -> mänguklient. See tähendab, et iga mängija tegevus täidetakse alles pärast seda, kui see on teinud edas-tagasi tee üle võrgu. Seetõttu näeks mäng välja äärmiselt aeglane, mistõttu peaaegu kohe pärast mitmikmängu ilmumist mängus tutvustati latentsuse varjestamise mehhanismi. Latentsuse varjestamine simuleerib mängija sisendit, arvestamata teiste mängijate tegevusi ja serveri otsuseid.

Factorios on mängu olek Mängu olek — see on täielik kaardi, mängija, üksuste ja kõige muu seisund. Seda simuleeritakse määratult kõigis klientides serverilt saadud tegevuste põhjal. Mängu olek on püha, ja kui see kunagi hakkab eristuma serverist või mõnest muust kliendist, tekib desünkroonsus.

Lisaks Mängu olek meil on latentsuse olek Latentsuse olek. See sisaldab väikest alamhulka põhiseisundist. Latentsuse olek ei ole püha ja lihtsalt kujutab ette, milline on mängu seis tulevikus, põhinedes mängija sisestatud andmetele Input Actions.

Selleks salvestame koostatud koopiat Input Actions viivituste järjekorras.

Ehkki lõppprotsess kliendi poole näeb välja umbes nii:

1. Kasutame Input Actions kõigi mängijate jaoks Mängu olek niimoodi, nagu need sisestusteaded serverilt saadi.
2. Kustutame kõik järjekorrast viivitused Input Actions, mis serveri andmetel on juba rakendatud Mängu olek.
3. Kustutame Latentsuse olek ja lähtestame selle, et see näeks välja just selline, nagu Mängu olek.
4. Rakendame kõik tegevused viivituste järjekorrast Latentsuse olek.
5. Põhinedes andmetele Mängu olek ja Latentsuse olek renderdame mängu mängijale.

Kõike seda korratakse igas taktis.

Liialt keeruline? Ärge muretsege, see ei ole veel kõik. Interneti-ühenduste ebaregulaarsete omaduste kompenseerimiseks oleme loonud kaks mehhanismi:

• Vahelejätetud taktide puhul: kui server otsustab, et Input Actions teostatakse mängu takt, siis kui ta ei saanud Input Actions mingi mängija andmeid (näiteks suurenenud viivituse tõttu), siis ta ei oota, vaid teatab sellele kliendile: "ma ei arvestanud sinu Input Actions, püüan need järgmistesse takti lisada." See on tehtud selleks, et ühe mängija ühenduse (või arvuti) probleemide tõttu ei aeglustuks kaardi uuendamine kõigi teiste jaoks. Tasub märkida, et Input Actions ei ignoreerita, vaid lihtsalt lükatakse edasi.
• Üksuse tagasipöördumise latentsus: server püüab arvata, milline on andmete tagasisaatmise latentsus kliendi ja serveri vahel iga kliendi jaoks. Iga 5 sekundi järel arutab ta vajadusel kliendiga uut latentsust (sõltuvalt sellest, kuidas ühendus on minevikus käitunud) ning vastavalt suurendab või vähendab tagasisaatmise latentsust.

Need mehhanismid iseenesest on üsna lihtsad, kuid kui nad töötavad koos (mis sageli juhtub ühenduse probleemide korral), muutub koodi loogika keeruliseks ja täis piirjuhtumeid. Lisaks, kui need mehhanismid peavad sekkuma, peavad server ja viivituste järjekord õigesti rakendama erilist Sisendi tegevus nimetusega StopMovementInTheNextTick. Tänu sellele, kui esinevad ühenduse probleemid, ei jookse tegelane iseenesest (näiteks rongi alla).

Nüüd on vaja selgitada, kuidas olendite valimine töötab. Üks edastatavatest tüüpidest Sisendi tegevus on olendi valimise oleku muutmine. See teatab kõigile, millisele olendile mängija hiirekursor osutab. Nagu võib aru saada, on see üks kõige sagedasemaid sisendite tehinguid, mida kliendid saadavad, seega oleme selle kanali ribalaiuse kokkuhoiu huvides optimeerinud, et see tooks nii vähe ruumi kui võimalik. See on rakendatud nii, et iga olendi valimisel ei salvestata mitte absoluutse, täpsete kaardikoordinaate, vaid salvestatakse madal täpsuseline suhteline nihke eelnevast valikust. See toimib hästi, kuna hiirega valimine toimub tavaliselt väga lähedal varasemale valikule. Selle tõttu on kaks olulist nõuet: Input Actions kunagi ei tohi vahele jätta ja neid tuleb täita õiges järjekorras. Need nõuded on täidetud Mängu olek. Kuid kuna ülesanne Latency state on näha välja piisavalt hea mängijale, siis viivituste ajal ei ole need täidetud. Latentsuse olek ei võta arvesse paljusid piirjuhtumeid, mis on seotud vahejuhtumite ja edasi-tagasi edastusviivitustega.

Sa võiksid juba aimata, kuhu see kõik viib. Lõfinally me hakkame nägema megapaketi probleemide põhjuseid. Probleemi juured seisnevad selles, et otsustamisel, kas edastada valiku muutmise tegu, tugineb olendi valimise loogika Latentsuse olek, kuid see seisund ei sisalda alati õiget teavet. Seetõttu genereeritakse megapakett umbes nii:

1. Mängijal on ühenduse probleemid.
2. Kasukste muutmise ja edastusviivituse regulatsiooni mehhanismid astuvad mängu.
3. Viivituste järjekord ei arvesta neid mehhanisme. See toob kaasa asjaolu, et mõned teod kustutatakse liiga varakult või esitlets toimivad vale järjekorras, mis põhjustab vale Latentsuse olek.
4. Mängijal kaob ühenduse probleem ja ta simuleerib, et järgneb serverile, kuni 400 takti.
5. Igas taktis genereeritakse ja valmistatakse serverile edastamiseks uus tegevuse muutmise tegu.
6. Kliendi megapakett koosneb üle 400 olendi valiku muutmisest (ja teiste tegevuste, nagu laskmise ja kõndimise seisundid, samuti kannatasid selle probleemi all).
7. Server saab 400 sisendi toimingut. Kuna tal ei lubata ühtegi sisenditegevust vahele jätta, käsutab ta kõiki kliente neid samme tegema ja saadab need üle võrgu.

Ironia seisneb selles, et mehhanism, mis pidi kanaliteed säästma, põhjustas tegelikult tohutuid võrgu pakette.

Lahendasime selle probleemi, parendades kõik piirjuhtumid uuendamise ja viivituste järjekorra toetamisel. Kuigi see võttis üsna palju aega, tasus lõpuks kõik õigesti ellu viia, mitte toetuda kiiretele hack'idele.

Allikas: habr.com