Megapaket: Hur utvecklarna av Factorio lyckades lösa problemet med multiplayer för 200 spelare

I maj månad deltog jag som spelare i MMO-evenemanget KatherineOfSky. Jag märkte att när antalet spelare når ett visst antal, så kopplar en del av dem "bort" var några minuter. Lyckligtvis för er (men inte för mig) var jag en av de spelare som kopplades bort varje gång, trots att jag hade en bra uppkoppling. Jag tog detta som en personlig utmaning och började leta efter orsaken till problemet. Efter tre veckors felsökning, testning och reparationer var felet äntligen åtgärdat, men denna resa var inte så enkel.

Problem i multiplayer-spel är väldigt svåra att spåra. De uppstår vanligtvis under mycket specifika förhållanden i nätverksinställningar och under väldigt specifika spelsituationer (i det här fallet – mer än 200 spelare). Och även när man lyckas återskapa problemet kan det vara omöjligt att debugga det ordentligt, eftersom insättning av kontrollpunkter stoppar spelet, förvirrar tidtagarna och vanligtvis leder till att anslutningen avslutas på grund av tidsöverskridning. Men tack vare ihärdighet och ett fantastiskt verktyg som heter clumsy , lyckades jag lista ut vad som hände.

Kort sagt: på grund av ett fel och ofullständig implementering av simuleringsförhållandet för fördröjning hamnade klienten ibland i en situation där den måste skicka ett nätverkspaket bestående av spelarinmatningar som involverar cirka 400 spelstruktur (vi kallar det "megapaket"). Efter detta måste servern inte bara ta emot alla dessa inmatningar korrekt, utan också skicka dem till alla andra klienter. Om du har 200 klienter blir detta snabbt ett problem. Kanalen till servern blir snabbt överfull, vilket leder till paketförlust och en kaskad av begärda paket på nytt. Fördröjningen av inmatningar leder sedan till att ännu fler klienter börjar skicka megapaket, och deras lavin blir ännu starkare. Lyckas kunderna återhämta sig går alla andra "bort".


Problemet var ganska grundläggande och jag tog två veckor för att åtgärda det. Det är ganska tekniskt, så nedan kommer jag att förklara detaljerna. Men först behöver du veta att med version 0.17.54 som släpptes den 4 juni, har multiplayer blivit mer stabilt under tidsproblem med anslutning, och fördröjningsdoldning är mycket mindre glitchigt (mindre lagg och teleportering). Dessutom har jag ändrat sättet att dölja fördröjningar i strid och hoppas att de kommer att vara lite mer smidiga.

Multiplayer Megapaket – tekniska detaljer

Förenklat kan man säga att multiplayer i spelet fungerar så här: alla klienter simulerar spelets tillstånd, genom att ta emot och skicka endast spelarens inmatning (kallas "inmatningsåtgärder", Input Actions). Huvuduppgiften för servern är att överföra Input Actions och kontrollera att alla klienter utför samma åtgärder under ett taktslag. Mer om detta kan du läsa i inlägget FFF-149.

Eftersom servern måste fatta beslut om vilka åtgärder som ska utföras, rör sig spelarens åtgärd ungefär enligt denna väg: spelarens åtgärd -> spelklienten -> nätverk -> server -> nätverk -> spelklienten. Det betyder att varje spelaråtgärd utförs först efter att den har gjort resan fram och tillbaka genom nätverket. På grund av detta skulle spelet verka fruktansvärt laggigt, så nästan omedelbart efter att multiplayer introducerades i spelet, implementerades en mekanism för att dölja fördröjningar. Död fördröjning simulerar spelarens inmatning utan att ta hänsyn till andra spelares åtgärder eller serverns beslut.

I Factorio finns det ett speltilstånd Game State – det fullständiga tillståndet av kartan, spelaren, enheterna och allt annat. Det simuleras deterministiskt i alla klienter baserat på åtgärder som tas emot från servern. Spelståndet är heligt, och om det någonsin börjar skilja sig från servern eller någon annan klient uppstår det en desynkronisering.

Förutom Game State har vi ett fördröjnings tillstånd Latency State. Det innehåller en liten delmängd av det grundläggande tillståndet. Latency State det är inte heligt och representerar helt enkelt en bild av hur spelets tillstånd kommer att se ut i framtiden baserat på spelarens inmatningar. Input Actions.

För detta lagrar vi en kopia av skapade Input Actions i fördröjningskön.

Det vill säga, i slutet av processen ser bilden på klientsidan ut ungefär så här:

1. Tillämpa Input Actions alla åtgärder på Game State så som dessa indata har mottagits från servern.
2. Ta bort alla åtgärder från fördröjningskön Input Actions, som enligt servern redan har tillämpats på Game State.
3. Ta bort Latency State och återställ det så att det ser exakt ut som Game State.
4. Tillämpa alla åtgärder från fördröjningskön på Latency State.
5. Baserat på data Game State och Latency State renderar vi spelet för spelaren.

Allt detta upprepas i varje takt.

För svårt? Slappna av, det är ännu inte allt. För att kompensera för den opålitliga internetanslutningen har vi skapat två mekanismer:

• Missade takter: när servern beslutar att Input Actions åtgärder kommer att genomföras i speltakten, om den inte har fått Input Actions något från en spelare (till exempel på grund av ökad fördröjning), kommer den inte att vänta, utan meddelar den klienten "jag har inte tagit hänsyn till dina Input Actions, jag ska försöka lägga till dem i nästa takt". Detta görs för att säkerställa att uppdateringen av kartan inte fördröjs för alla andra på grund av anslutningsproblem (eller en enskild spelares dator). Det är värt att notera att Input Actions inte ignoreras, utan bara skjuts upp.
• Fullständig tur-och-retur-fördröjning: servern försöker förutsäga vad fördröjningen för dataöverföring tur och retur mellan klienten och servern är för varje klient. Var femte sekund diskuterar den vid behov en ny fördröjning med klienten (beroende på hur anslutningen betett sig tidigare) och justerar tur-och-retur-fördröjningen därefter.

Själva dessa mekanismer är ganska enkla, men när de används tillsammans (vilket ofta händer vid anslutningsproblem) blir logiken i koden svårhanterlig med många gränsfall. Dessutom, när dessa mekanismer är inblandade, måste servern och fördröjningskön korrekt implementera den speciella Input Action som kallas StopMovementInTheNextTick. Tack vare detta kommer karaktären inte att springa av sig själv vid anslutningsproblem (till exempel under ett tåg).

Nu måste jag förklara för dig hur enhetsvalet fungerar. En av de överförda typerna Input Action — detta är förändringen av tillståndet för entitetsval. Det informerar alla om vilken entitet spelaren har pekat på med musen. Som man kan förstå är detta en av de vanligaste inmatningsåtgärderna som skickas av klienterna, därför har vi optimerat den så att den tar så lite bandbredd som möjligt. Detta har genomförts på det sättet att vid val av varje entitet istället för att spara absoluta, högprecisionskartkoordinater, sparar spelet lågprecisions relativa förskjutningar från den föregående valet. Detta fungerar bra eftersom musmarkeringen vanligtvis sker nära den tidigare markeringen. På grund av detta finns det två viktiga krav: Input Actions får aldrig hoppas över och måste utföras i rätt ordning. Dessa krav uppfylls för Game State. Men eftersom uppgiften Latency state är att "se tillräckligt bra ut" för spelaren, uppfylls de inte i latensläget. Latency State tar inte hänsyn till många gränsfall, relaterade till takthopp och förändringar i tvåvägs latens.

Du kan redan gissa vart det här leder. Äntligen börjar vi se orsakerna till megapaketproblemet. Roten till problemet ligger i att beslutslogiken om huruvida åtgärden för att förändra valet ska överföras, är beroende av Latency State, och detta tillstånd innehåller inte alltid korrekt information. Därför genereras megapaketet på följande sätt:

1. Spelaren har problem med anslutningen.
2. Taktjump och justering av tvåvägs latens kommer in i bilden.
3. Kö av latensstatus tar inte hänsyn till dessa mekanismer. Detta leder till att vissa åtgärder tas bort för tidigt eller utförs i fel ordning, vilket resulterar i felaktig Latency State.
4. Spelaren tappade anslutningen och simulerar upp till 400 takter för att hinna ikapp servern.
5. Vid varje takt genereras och förbereds en ny åtgärd för att förändra entitetsvalet för att skickas till servern.
6. Klienten skickar ett megapaket med över 400 förändringar av entitetsval (och andra åtgärder: tillståndet för skjutande, gång osv. led också av detta problem).
7. Servern får 400 inmatningsåtgärder. Eftersom den inte har tillåtelse att hoppa över en enda åtgärd beordrar den alla klienter att utföra dessa åtgärder och skickar dem över nätverket.

Ironin är att mekanismen som är avsedd att spara bandbredd i kanalen istället skapade enorma nätverkspaket.

Vi löste detta problem genom att åtgärda alla gränsfall för uppdatering och hantering av fördröjningsköer. Även om det tog ganska lång tid var det värt att genomföra allt korrekt istället för att förlita sig på snabba lösningar.

Källa: habr.com