Under de senaste två veckorna har jag arbetat med ett nätverksmotor för mitt spel. Innan dess visste jag överhuvudtaget ingenting om nätverkstekniker i spel, så jag läste många artiklar och genomförde många experiment för att förstå alla koncept och kunna skriva min egen nätverksmotor.

I den här guiden vill jag dela med mig av olika koncept som du behöver studera innan du skriver din egen spelmotor, samt de bästa resurserna och artiklarna för att lära dig om dem.

Det finns i allmänhet två huvudsakliga typer av nätverksarkitekturer: peer-to-peer och klient-server. I peer-to-peer-arkitekturen (p2p) överförs data mellan vilken som helst av de anslutna spelarna medan i klient-server-arkitekturen överförs data endast mellan spelarna och servern.

Även om peer-to-peer-arkitektur fortfarande används i vissa spel, är klient-server-arkitekturen standard: den är enklare att genomföra, kräver mindre bandbredd och underlättar skydd mot fusk. Därför kommer vi i den här guiden att fokusera på klient-server-arkitekturen.

Specifikt är vi mest intresserade av auktoritativa servrar: i sådana system har servern alltid rätt. Till exempel, om en spelare tror att de befinner sig på koordinaterna (10, 5), men servern säger att de är på (5, 3), så måste klienten ersätta sin position med den som servern ger, och inte vice versa. Att använda auktoritativa servrar förenklar upptäckten av fusk.

I spelens nätverksystem finns det tre huvudsakliga komponenter:

• Transportprotokollet: hur data överförs mellan kunder och server.
• Applikationsprotokollet: vad som överförs från kunder till server och från server till kunder och i vilket format.
• Applikationens logik: hur de överförda uppgifterna används för att uppdatera statusen för kunder och server.

Det är väldigt viktigt att förstå rollen för varje del och de relaterade svårigheterna.

Transportprotokollet

Det första steget är att välja ett protokoll för överföring av data mellan servern och kunderna. Det finns två internetprotokoll för detta: TCP och UDP. Men du kan också skapa ditt eget transportprotokoll baserat på ett av dem eller använda ett bibliotek där de används.

Jämförelse av TCP och UDP

Både TCP och UDP baseras på IP. IP möjliggör överföring av paket från avsändare till mottagare, men ger inga garantier för att det skickade paketet så småningom når mottagaren, att det kommer fram åtminstone en gång, eller att paketens sekvens anländer i rätt ordning. Dessutom kan paketet innehålla bara en begränsad mängd data, fastställd av storleken ip a show.

UDP är bara ett tunt lager ovanpå IP. Därför har det samma begränsningar. Till skillnad från det har TCP många funktioner. Det erbjuder en pålitlig ordnad anslutning mellan två noder med felkontroll. Därför är TCP mycket praktiskt och används i många andra protokoll, till exempel i HTTP, FTP och SMTP. Men alla dessa funktioner har ett pris: fördröjning.

För att förstå varför dessa funktioner kan orsaka fördröjning måste man förstå hur TCP fungerar. När avsändarnoden skickar ett paket till mottagarnoden väntar den på att få en bekräftelse (ACK). Om den inte får den inom en viss tid (eftersom paketet eller bekräftelsen har gått förlorad, eller av andra orsaker) så sänder den paketet igen. Dessutom garanterar TCP att paketen mottas i rätt ordning, vilket innebär att tills det förlorade paketet har mottagits kan alla andra paket inte behandlas, även om de redan har mottagits av mottagarnoden.

Men som du förmodligen förstår är fördröjning i flerspelarspel mycket viktigt, särskilt i aktiva genrer som FPS. Just därför använder många spel UDP med ett eget protokoll.

Ett eget protokoll baserat på UDP kan vara mer effektivt än TCP av olika anledningar. Till exempel kan det märka vissa paket som pålitliga och andra som opålitliga. Därför bryr det sig inte om det opålitliga paketet nådde mottagaren. Eller det kan hantera flera datastreamar så att ett paket förlorat i en ström inte bromsar de andra strömmarna. Till exempel kan det finnas en ström för spelarens input och en annan ström för chattmeddelanden. Om chattmeddelandet, som inte är en brådskande data, går förlorat, så fördröjer det inte inmatningen, som är akuta. Eller så kan det egna protokollet implementera pålitlighet på ett annat sätt än TCP för att vara mer effektivt i videospelsförhållanden.

Så, om TCP är så dåligt, ska vi skapa vårt eget transportprotokoll baserat på UDP?

Det är lite mer komplicerat. Även om TCP nästan är suboptimalt för spel-nätverksystem, kan det fungera ganska bra specifikt i ditt spel och spara din värdefulla tid. Till exempel kanske fördröjningen inte är ett problem för ett turordningsbaserat spel eller ett spel som endast kan spelas på LAN-nätverk, där fördröjningar och paketförluster är mycket mindre än på internet.

Många framgångsrika spel, inklusive World of Warcraft, Minecraft och Terraria, använder TCP. Men i de flesta FPS-spel används egna protokoll baserade på UDP, så nedan pratar vi mer om dem.

Om du bestämmer dig för att använda TCP, se till att Nagle-algoritmen, är avstängd, eftersom den buffrar paket innan de skickas, vilket ökar fördröjningen.

För att få mer information om skillnaderna mellan UDP och TCP i sammanhanget av flerspelarspel kan du läsa Glenn Fidlers artikel UDP vs. TCP.

Eget protokoll

Så, du vill skapa ditt eget transportprotokoll, men vet inte vart du ska börja? Du är lycklig, för Glenn Fidler har skrivit två fantastiska artiklar om detta. I dem hittar du massor av kloka tankar.

Den första artikeln, Networking for Game Programmers från 2008 är enklare än den andra, Building A Game Network Protocol från 2016. Jag rekommenderar att du börjar med den äldre.

Observera att Glenn Fidler är en stor förespråkare för att använda ett eget protokoll baserat på UDP. Och efter att ha läst hans artiklar kommer du förmodligen att anta hans åsikt att TCP har allvarliga brister i videospel och vilja implementera ditt eget protokoll.

Men om du är ny på nätverksarbete, gör dig själv en tjänst och använd TCP eller en bibliotek. För att framgångsrikt implementera ett eget transportprotokoll behöver du först lära dig mycket.

Nätverksbibliotek

Om du behöver något mer effektivt än TCP, men inte vill krångla med att implementera ditt eget protokoll och gå in i många detaljer, kan du använda ett nätverksbibliotek. Det finns många av dem:

• yojimbo Glenn Fidler
• RakNet, som inte längre stöds, men dess fork SLikeNet verkar fortfarande vara aktiv.
• ENet är ett bibliotek som skapades för flerspelar-FPS Cube
• GameNetworkingSockets från Valve

Jag har inte provat alla, men jag föredrar ENet eftersom det är enkelt att använda och pålitligt. Dessutom har det tydlig dokumentation och en handledning för nybörjare.

Transportprotokoll: slutsats

Sammanfattningsvis finns det två grundläggande transportprotokoll: TCP och UDP. TCP har flera användbara egenskaper: pålitlighet, paketordning och felupptäckning. UDP saknar allt detta, men TCP har å sin sida högre latens, vilket är oacceptabelt för vissa spel. Så för att säkerställa låg latens kan man skapa ett eget protokoll baserat på UDP eller använda ett bibliotek som implementerar transportprotokollet över UDP och är anpassat för flerspelarvideospel.

Valet mellan TCP, UDP och biblioteket beror på flera faktorer. För det första, på spelets behov: kräver det låg latens? För det andra, på applikationens protokollkrav: behövs ett pålitligt protokoll? Som vi kommer att se i nästa del kan man skapa ett applikationsprotokoll som fungerar bra med ett opålitligt protokoll. Slutligen måste man även ta hänsyn till erfarenheten hos utvecklaren av nätverksmotorn.

Jag har två råd:

• Abstrahera transportprotokollet från resten av applikationen så mycket som möjligt så att det enkelt kan bytas ut utan att behöva skriva om hela koden.
• Undvik prematur optimering. Om du inte är nätverksspecialist och inte är säker på om du behöver ett eget transportprotokoll baserat på UDP, kan du börja med TCP eller ett bibliotek som erbjuder pålitlighet och sedan testa och mäta prestandan. Om problem uppstår och du är säker på att det beror på transportprotokollet, kan det vara dags att skapa ett eget transportprotokoll.

Avslutningsvis rekommenderar jag att du läser Introduction to Multiplayer Game Programming av Brian Hook, där många av de ämnen som diskuteras här behandlas.

Applikationsprotokoll

Nu när vi kan utbyta data mellan klienterna och servern behöver vi bestämma vilka data som ska skickas och i vilket format.

Den klassiska modellen är att klienterna skickar input eller handlingar till servern, och servern skickar det aktuella spelståndet till klienterna.

Servern skickar en filtrerad version av tillståndet med enheter som finns i närheten av spelaren. Detta görs av tre anledningar. För det första kan det fullständiga tillståndet vara för stort för att överföras med hög frekvens. För det andra är det mesta av intresset för visuella och ljuddata, eftersom större delen av spel-logiken simuleras på spelservern. För det tredje får spelaren inte veta vissa data i vissa spel, som positionen av fienden på andra sidan kartan, eftersom detta skulle göra det möjligt för spelaren att sniffa paketen och exakt veta vart de ska röra sig för att döda fienden.

Serialisering

Det första steget är att omvandla de data vi vill skicka (inmatning eller spelstånd) till ett format som är lämpligt för överföring. Denna process kallas serialisering.

Man kommer genast på att använda ett människoläsbart format som JSON eller XML. Men detta skulle vara helt ineffektivt och ta upp en stor del av kanalen.

Istället rekommenderas att använda ett binärt format, som är mycket mer kompakt. Det vill säga att paketen bara innehåller några få byte. Här måste man ta hänsyn till problemet med byteordning, som kan vara olika på olika datorer.

För att serialisera data kan man använda ett bibliotek, till exempel:

• FlatBuffers från Google
• Cap’n Proto från Sandstorm
• cereal av Shane Grant och Randolph Vurhis

Se bara till att biblioteken skapar portabla arkiv och hanterar byteordningen.

Ett alternativ kan vara att implementera det själv, vilket inte är särskilt svårt, särskilt om du använder ett datadrivet tillvägagångssätt i din kod. Dessutom ger det dig möjlighet att göra optimeringar som inte alltid är möjliga med ett bibliotek.

Glenn Fidler har skrivit två artiklar om serialisering: Reading and Writing Packets och Serialization Strategies.

Kompression

Mängden data som överförs mellan klienterna och servern är begränsad av kanalens bandbredd. Datakomprimering gör att man kan skicka mer data i varje snapshot, öka uppdateringsfrekvensen eller helt enkelt minska kraven på kanalen.

Bitpackning

Den första tekniken är bitpackning. Det handlar om att använda exakt det antal bitar som behövs för att beskriva den nödvändiga storleken. Om du till exempel har en uppräkning som kan ha 16 olika värden, kan du använda bara 4 bitar istället för en hel byte (8 bitar).

Glenn Fiedler förklarar hur man implementerar detta i andra delen av artikeln. Reading and Writing Packets.

Bitpackning fungerar särskilt bra med diskretisering, vilket kommer att vara ämnet för nästa avsnitt.

Diskretisering

Diskretisering är en teknik för komprimering med förlust, som går ut på att använda endast en delmängd av de möjliga värdena för kodning av storleken. Det är lättast att genomföra diskretisering genom att avrunda flyttal.

Glenn Fiedler (igen!) visar hur man praktiskt tillämpar diskretisering i sin artikel. Snapshot-komprimering.

Komprimeringsalgoritmer

Den nästa tekniken kommer att vara förlustfria komprimeringsalgoritmer.

Här är, enligt min mening, tre av de mest intressanta algoritmerna som man bör känna till:

• Huffman-kodning med förberäknad kod som är extremt snabb och kan ge bra resultat. Den användes för att komprimera paket i nätverksmotorn Quake3.
• zlib är en allmän komprimeringsalgoritm som aldrig ökar datamängden. Som man kan se här, har den använts i många tillämpningar. För att uppdatera tillstånd kan den vara överflödig, men den kan vara användbar om du behöver skicka tillgångar, långa texter eller terräng från servern till klienterna.
• Kopiering av långa serier är kanske den enklaste komprimeringsalgoritmen, men den är väldigt effektiv för vissa typer av data och kan användas som ett förbearbetningssteg innan zlib. Den är särskilt lämplig för att komprimera terräng bestående av tiles eller voxels där många angränsande element upprepas.

Delta-komprimering

Den sista komprimeringsmetoden är delta-komprimering. Det handlar om att endast överföra skillnaderna mellan det aktuella spelstatuset och det senaste statuset som mottagits av klienten.

Den användes första gången i nätverksmotorn Quake3. Här är två artiklar som förklarar hur den används:

• Quake3-nätverksmodellen Brian Hook
• Quake 3-källkodens granskning: Nätverksmodell Fabien Sanglard [översättning artiklar på Habré, se avsnittet "Nätverksmodell"].

Glenn Fidler har också använt den i den andra delen av sin artikel Snapshot-komprimering.

Kryptering

Dessutom kan det vara nödvändigt att kryptera dataöverföring mellan klienter och servrar. Det finns flera anledningar till detta:

• integritet: meddelandena kan endast läsas av mottagaren, och ingen annan person som övervakar nätet kan läsa dem.
• autentisering: en person som vill agera som spelare måste känna till sin nyckel.
• förhindra fusk: illvilliga spelare kommer att ha mycket svårare att skapa egna paket för fusk, eftersom de måste återskapa krypteringsschemat och hitta nyckeln (som ändras vid varje anslutning).

Jag rekommenderar starkt att använda ett bibliotek för detta. Jag föreslår att använda libsodium, eftersom det är särskilt enkelt och har utmärkta handledningar. Det är särskilt intressant med handledningen för nyckelutbyte, som gör det möjligt att generera nya nycklar vid varje ny anslutning.

Applikationsprotokoll: sammanfattning

Härmed avslutar vi med applikationsprotokollet. Jag anser att komprimering är helt onödig och att beslutet om att använda det endast beror på spelet och den nödvändiga bandbredden. Kryptering, anser jag, är obligatorisk, men i den första prototypen kan vi klara oss utan det.

Applikationslogik

Nu kan vi uppdatera tillståndet i klienten, men vi kan möta problem med fördröjningar. När spelaren gör en insats måste hen vänta på att se spelets tillstånd uppdateras från servern för att förstå vilken påverkan hen har haft på världen.

Dessutom förblir världen helt statisk mellan två tillståndsuppdateringar. Om uppdateringsfrekvensen är låg kommer rörelserna att vara väldigt ryckiga.

Det finns flera tekniker som kan minska påverkan av detta problem, och i nästa avsnitt kommer jag att berätta om dem.

Tekniker för att jämna ut fördröjningar

Alla tekniker som beskrivs i det här avsnittet behandlas ingående i serien Fast-Paced Multiplayer av Gabriel Gambetta. Jag rekommenderar starkt att läsa denna utmärkta serie artiklar. Den inkluderar också en interaktiv demo som visar hur dessa tekniker fungerar i praktiken.

Den första tekniken handlar om att tillämpa resultatet av insatsen direkt utan att vänta på svar från servern. Detta kallas klientbaserad förutsägelse. Men när klienten får en uppdatering från servern måste den säkerställa att dess förutsägelse var korrekt. Om så inte är fallet, behöver den bara ändra sitt tillstånd baserat på det som mottagits från servern, eftersom servern är auktoritär. Denna teknik användes först i Quake. Mer om detta kan läsas i artikeln Quake Engine kodgranskning Fabien Sanglard [översättning på Habr].

Ett andra set av tekniker används för att jämna ut rörelsen av andra entiteter mellan två uppdateringar av tillstånd. Det finns två sätt att lösa denna uppgift: interpolation och extrapolation. Vid interpolation tas de två senaste tillstånden och övergången från ett till ett annat visas. Dess nackdel är att det orsakar en liten fördröjning eftersom klienten alltid ser vad som hände i det förflutna. Extrapolation handlar om att förutsäga var entiteterna nu borde befinna sig baserat på det senaste tillståndet som klienten mottagit. Dess nackdel är att om en entitet helt ändrar rörelseriktning, så uppstår det en stor felmarginal mellan förutsägelsen och den verkliga positionen.

Den senaste, mest avancerade tekniken, användbar endast i FPS — är fördröjningskompensation. Vid användning av fördröjningskompensation tar servern hänsyn till klientens latens när denne skjuter mot ett mål. Till exempel, om en spelare gjorde ett headshot på sin skärm, men i verkligheten befann sig målet på grund av latensen på ett annat ställe, skulle det vara orättvist att neka spelaren rätten till ett dödligt skott på grund av latens. Därför spolar servern tillbaka tiden till det ögonblick då spelaren sköt, för att simulera vad spelaren såg på sin skärm och kontrollera kollisionen mellan hans skott och målet.

Glenn Fiedler (som alltid!) skrev 2004 en artikel Network Physics (2004), där han la grunden för synkronisering av fysiksimulering mellan servern och klienten. 2014 skrev han en ny serie artiklar Networking Physics, där han beskrev andra tekniker för synkronisering av fysiksimulering.

Det finns också två artiklar på företagets wiki Valve, Source Multiplayer Networking och Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization där fördröjningskompensation behandlas.

Förebyggande av fusk

Det finns två huvudsakliga tekniker för att förebygga fusk.

Första: försvårande av att cheaters skickar skadliga paket. Som nämnts ovan, ett bra sätt att implementera detta är kryptering.

Andra: den auktoritära servern ska endast ta emot kommandon/input/åtgärder. Klienten ska inte ha möjlighet att ändra tillståndet på servern, annat än att skicka input. Då bör servern kontrollera giltigheten hos input varje gång den mottar det innan det tillämpas.

Applikationens logik: slutsats

Jag rekommenderar att du implementerar en metod för att simulera stora fördröjningar och låga uppdateringsfrekvenser för att kunna testa spelets beteende under dåliga förhållanden, även när klienten och servern körs på samma dator. Detta kommer att förenkla implementeringen av metoder för att smidiga fördröjningar.

Andra användbara resurser

Om du vill utforska andra resurser kring nätverksmodeller kan du hitta dem här:

• Glenn Fiedlers blogg — värt att läsa hela hans blogg, den innehåller många utmärkta artiklar. Här alla artiklar om nätverksteknologier är samlade.
• Awesome Game Networking av M. Fatih MAR — en omfattande lista över artiklar och videor om nätverksmotorer för videospel.
• I wiki för subreddit r/gamedev har också många användbara länkar.

Källa: habr.com