Megapakett: kuidas Factorio arendajad suutsid lahendada 200 mängijaga mitmikmängu probleemi

Käesoleva aasta mail osalesin mängijana MMO-üritusel KatherineOfSky. Märkasin, et kui mängijate arv jõuab teatud numbrini, viskab osa neist igal paaril minutil mängust välja. Teie rõõmuks (aga mitte minu jaoks) olin mina üks neist mängijatest, kes igakord "kukkus välja" igal korral, isegi hea ühenduse olemasolul. Võtsin seda isikliku väljakutsena ja hakkasin probleemi põhjuseid uurima. Kolme nädala debugimise, testimise ja parandamise järel saime lõpuks vea kõrvaldada, kuid see reis ei olnud sugugi lihtne.

Mitmikmängu probleemide jälgimine on väga keeruline. Need tekivad tavaliselt väga spetsiifilistes võrguparametrites ja mängu spetsiifilistes olukordades (antud juhul – üle 200 mängija olemasolul). Ja isegi kui probleemi suudetakse replikeerida, on selle nõuetekohane debugeerimine peaaegu võimatu, kuna kontrollpunktide lisamine peatab mängu, segab taimerid ja põhjustab tavaliselt ühenduse katkemise, kuna ooteaeg on ületatud. Kuid tänu visadusele ja suurepärasele tööriistale nimega clumsy suutsin välja selgitada, mis juhtub.

Lühidalt: vea ja semi-funktsionaalse viivituse simulatsiooni rakendamise tõttu sattus klient mõnikord olukorda, kus pidi ühe käiguga saatma võrku paketi, mis koosnes mängija valitud umbes 400 mängujuhtimisest (me nimetame seda "megapakettideks"). Pärast seda peab server õigesti vastu võtma kõik need sisenditegevused ja saatma need kõigile teistele klientidele. Kui sul on 200 klienti, muutub see kiiresti probleemiks. Serveri kanal kipub kiiresti ummistuma, mis toob kaasa pakettide kaotuse ja uuesti nõutud paketide kaskaadi. Sisenditegevuste viivitamine toob seejärel kaasa rohkemate klientide saatmise megapakettidena, ja nende laviin muutub veelgi tugevamaks. Õnnelikud kliendid suudavad taastuda, kõik teised "kukuvad välja".


Probleem oli piisavalt põhjalik ning selle lahendamine võttis mul kaks nädalat. See on üsna tehniline, seega selgitan allpool üksikasjalikult. Kuid kõigepealt peate teadma, et alates versioonist 0.17.54, mis ilmus 4. juunil, on mitmikmängu ühendus problemaatilisemates tingimustes palju stabiilsem ja viivituste varjamine on oluliselt sujuvam (vähem viivitusi ja teleportimist). Lisaks muudab ma viivituste varjamise meetodit lahingus ja loodan, et see teeb need veidi sujuvamaks.

Mitmikmängu megapakett - tehnilised üksikasjad

Lihtsalt öeldes töötab mängus mitmikmäng järgmiselt: kõik kliendid simuleerivad mängu seisundit, saades ja edastades ainult mängija sisendeid (nimetatakse "sisendite tegevusteks", Input Actions). Peamine ülesanne serveri puhul on edastada Input Actions ja kontrollida, et kõik kliendid teevad sama tegevust ühes voorus. Selle kohta saab rohkem lugeda postitusest FFF-149.

Kuna server peab langetama otsuseid, milliseid tegevusi läbi viia, liigub mängija tegevus umbes sellist teed: mängija tegevus -> mängikliendi -> võrk -> server -> võrk -> mängikliendi. See tähendab, et iga mängija tegevus toimub alles pärast seda, kui see on võrgus edasi-tagasi rändanud. Selle tõttu näiks mäng hirmsasti viivitav, seega peaaegu kohe pärast mitmikmängu ilmumist mängu, kasutusele viidud viivituste varjamise mehhanism. Viivituste varjamine imiteerib mängija sisendit, ignoreerides teiste mängijate tegevusi ja serveri otsuseid.

Factorios on mängu olek Game State – see on kaardi, mängija, olendite ja muu täielik olek. Seda simuleeritakse kõikides klientides deterministlikult serverilt saadud tegevuste põhjal. Mängu olek on püha ja kui see kunagi serverist või mõnest teisest kliendist erineb, tekib desünkroniseerimine.

Lisaks Game State on meil viivituste olek Latency State. See sisaldab väikest alamosade kogumit põhiolukorrast. Latency State see ei ole püha ja lihtsalt kujutab ette, milline mängu seisund tulevikus välja näeb mängija sisendi põhjal. Input Actions.

Selleks hoiame me järjekorras toodetud Input Actions viivituste koopiat.

Seega, protsessi lõpus näeb kliendi pool välja umbes nii:

1. Rakendame Input Actions kõiki mängijaid Game State niimoodi, nagu need sisestamise toimingud on serverilt saadud.
2. Kustutame viivituste järjekorrast kõik Input Actions, mis, serveri andmete kohaselt, on juba rakendatud Game State.
3. Kustutame Latency State ja lähtestame selle, et see näeks välja täpselt nagu Game State.
4. Rakendame kõik viivituste järjekorra toimingud Latency State.
5. Serveri andmete põhjal Game State ja Latency State kujundame mängu mängijale.

Kogu see protsess kordub igas taktis.

Liiga keeruline? Ärge muretsege, see ei ole veel kõik. Internetiühenduse ebastabiilsuse kompenseerimiseks oleme loonud kaks mehhanismi:

• Puuduvad taktid: kui server otsustab, et Input Actions tuleb teostada mängu taktis, kuid ei ole saanud Input Actions mõnelt mängijalt (näiteks suurenenud viivituse tõttu), siis ei oota ta, vaid teatab sellele kliendile "ma ei arvestanud sinu Input Actions, püüan need järgmises taktis lisada". See on tehtud selleks, et ühe mängija (või arvuti) ühenduse probleemide tõttu ei aeglustuks kaardi uuendamine kõigi teiste jaoks. Tuleb märkida, et Input Actions ei ignoreerita, vaid lihtsalt lükatakse edasi.
• Täieliku edasi-tagasi viivituse mõõtmine: server püüab oletada, milline on andmeedastuse viivitus edasi-tagasi kliendi ja serveri vahel iga kliendi jaoks. Iga 5 sekundi järel arutab ta vajadusel kliendiga uut viivitust (sõltuvalt ühenduse käitumisest minevikus) ning vastavalt suurendab või vähendab edasi-tagasi andmeedastuse viivitust.

Need mehhanismid on enesest üsna lihtsad, kuid kui neid kasutatakse koos (mis juhtub sageli ühendusprobleemide korral), muutub koodi loogika keeruliseks ja sisaldab palju äärmuslikke juhtumeid. Lisaks, kui need mehhanismid on mängus, peavad server ja viivituste järjekord õigesti rakendama erilist Sisendi tegevus nimega Peata järgmises taktis liikumine. Tänu sellele ei hakka ühenduse probleemide korral karakter ise liikuma (näiteks rongi alla).

Nüüd on vaja teile selgitada, kuidas toimub olendite valik. Üks ülekantud tüüpidest Sisendi tegevus — see olekse juriit tühenduse muutmine. See teavitab kõiki, millele mängija hiirega osutab. Nagu aru saada, on see üks kõige sagedasemaid sisestuste toiminguid, mida kliendid saadavad, seega oleme selle kanalivõimsuse säästmiseks optimeerinud, et see võtaks võimalikult vähe ruumi. See on ellu viidud nii: iga olendi valimise korral, mitte absoluutsete, täpsete kaardikoordinaatide salvestamise asemel, salvestab mäng suhteliselt madala täpsusega nihke eelmisest valikust. See töötab hästi, kuna hiirega valimine toimub tavaliselt eelmisest valikust väga lähedal. Sellega kaasnevad kaks olulist nõuet: Input Actions kunagi ei tohi vahele jätta ja tuleb järgida õiget järjestust. Need nõuded täidetakse Game State. Kuid kuna ülesanne Latency state on "näha piisavalt hea" mängija jaoks, ei täideta neid viivitusolukordades. Latency State ei arvesta paljusid piirjuhtumeid, mis on seotud tsüklite vahelejätmise ja edasi-tagasi edastusviivituste muutumisega.

Sa võid juba aimata, kuhu see kõik viib. Lõpuks hakkame nägema probleemide megapaketi põhjusi. Probleemi juur peitub selles, et otsuse tegemisel, kas edastada valiku muutuse toiming, tugineb loogika olendite valikule Latency State, ja see olek ei sisalda alati õiget teavet. Seetõttu genereeritakse megapakett ligikaudu nii:

1. Mängijal on ühenduse probleem.
2. Seonduvad mehhanismid tükkide vahelejätmise ja edasi-tagasi edastusviivituse reguleerimise osas sekkuvad.
3. Viivituste olekute rida ei arvesta neid mehhanisme. See toob kaasa selle, et mõned toimingud eemaldatakse liiga vara või teostatakse vale järjekorras, mis viib vale Latency State.
4. Mängijal on ühenduse probleem ja ta simuleerib serveriga sündmuste jälgimiseks kuni 400 tsüklit.
5. Igas tsüklis genereeritakse ja valmistatakse ette uus olendi valiku muutmise toiming serverile edastamiseks.
6. Klient saadab serverile megapaketi, mis koosneb üle 400 olendi valiku muutmisest (ja teiste toimingutega: tulistamis, kõndimine jne; see probleem mõjutas ka neid).
7. Server saab 400 sisendtoimet. Kuna tal ei ole lubatud ühtegi sisendtoimet vahele jätta, käsib ta kõigil klientidel need toimeted täita ja edastab need üle võrgu.

Ironia seisneb selles, et mehhanism, mis oli mõeldud kanalite sademe kokkuhoidmiseks, tekitas lõpuks tohutuid võrgu pakette.

Lahendasime selle probleemi, parendades kõik ääretaparisugused uuendamise ja järjekorra toetamise juhtumid. Kuigi see võttis üsna kaua aega, tasus see end ära, et kõik õigesti ellu viia, mitte toetuda kiiretele lahendustele.

Allikas: habr.com