Viimased kaks nädalat olen töötanud oma mängu võrgu mootoriga. Enne seda ei saanud ma üldse aru mängude võrgutehnoloogiatest, seetõttu lugesin palju artikleid ja tegin hulganisti katseid, et mõista kõiki kontseptsioone, et suuta kirjutada oma võrgu mootor.

Selles juhendis soovin jagada teiega erinevaid kontseptsioone, mida peate uurima enne oma mängu mootori kirjutamist, samuti parimaid ressursse ja artikleid nende uurimiseks.

Üldiselt on olemas kaks peamist tüüpi võrgu arhitektuure: peer-to-peer ja kliendiserver. Peer-to-peer (p2p) arhitektuuris edastatakse andmed igasuguste ühendatud mängijate vahel, kuid kliendiserveri arhitektuuris edastatakse andmeid ainult mängijate ja serveri vahel.

Kuigi peer-to-peer arhitektuuri kasutatakse endiselt mõnedes mängudes, on standardiks kliendiserver: see on lihtsam teostada, vajab väiksemat ribalaiust ja lihtsustab petmisvastase kaitse rakendamist. Seetõttu keskendume selles juhendis kliendiserveri arhitektuurile.

Eriti huvitavad meid autoriteetsed serverid: sellistes süsteemides on server alati õigus. Näiteks, kui mängija arvab, et ta asub koordinaatides (10, 5), kuid server ütleb talle, et ta on koordinaatides (5, 3), siis peab klient asendama oma positsiooni serveri edastatud positsiooniga, mitte vastupidi. Autoriteetsete serverite kasutamine lihtsustab petjate tuvastamist.

Mängude võrgusüsteemides on kolm peamist komponenti:

• Transpordiprotokoll: kuidas andmeid edastatakse klientide ja serveri vahel.
• Rakendusprotokoll: mida edastatakse klientidelt serverile ja serverilt klientidele ning millises formaadis.
• Rakenduse loogika: kuidas edastatud andmeid kasutatakse klientide ja serveri oleku uuendamiseks.

On väga oluline mõista iga osa rolli ja nendega seotud raskusi.

Transpordiprotokoll

Esimene samm on valida protokoll andmete edastamiseks serveri ja klientide vahel. Selleks on kaks Interneti-protokolli: TCP ja UDP. Kuid saate luua ka oma transpordiprotokolli selle põhjal või kasutada raamatukogu, kus need on kasutusel.

TCP ja UDP võrdlus

N tanto TCP kui UDP põhinevad IP. IP võimaldab paketti edastada allikast saajale, kuid ei garanteeri, et saadetud pakk jõuab saajani varem või hiljem, või et see saabub vähemalt korra ja et paketid jõuavad õiges järjekorras. Veelgi enam, pakk võib sisaldada ainult piiratud suuruses andmeid, mis on määratud suurusega MTU.

UDP on lihtsalt õhuke kiht IP kohal. Seetõttu on tal samad piirangud. Erinevalt sellest, TCP-l on mitmeid omadusi. See tagab usaldusväärse järjekorraga ühenduse kahe sõlme vahel koos veakontrolliga. Seega on TCP väga mugav ja seda kasutatakse paljus muudes protokollides, näiteks HTTP, FTP ja SMTP. Kuid kõik need funktsioonid tulevad oma hinnaga: viivitus.

Mõistmaks, miks need funktsioonid võivad põhjustada viivitust, tuleb aru saada, kuidas TCP töötab. Kui saatja sõlm edastab paketi vastuvõtjale, ootab ta kinnitust (ACK). Kui ta teatud aja pärast ei saa kinnitust (kuna pakk või kinnitus on kadunud või mõnel muul põhjusel), saadab ta paki uuesti. Veelgi enam, TCP garanteerib, et paketid saadakse õiges järjekorras, seega kuni kadunud paketti ei ole saadud, ei saa kõik teised paketid töötlemiseks lahti võtta, isegi kui need on juba vastuvõtja sõlme jõudnud.

Kuid nagu ilmselt mõistate, on viivitus mitme mängija mängudes väga oluline, eriti sellistes aktiivsetes žanrites nagu FPS. Just sellepärast kasutavad paljud mängud UDP-d koos oma protokolliga.

Oma UDP-põhine protokoll võib olla efektiivsem kui TCP mitmetel põhjustel. Näiteks võib see märgistada mõned paketid usaldusväärseteks ja teised — usaldamatuteks. Seetõttu ei huvita see, kas usaldamatu pakk jõuab saajani. Või võib see hallata mitmeid andmevooge, et ühes voos kadunud pakk ei aeglustaks teisi vooge. Näiteks võib olla voog mängija sisendi jaoks ja veel üks voog jututoas. Kui jututoas kadus sõnum, mis ei ole hädavajalik andmestik, ei aeglusta see sisendi aktiveerimist, mis on kriitiline. Või võib oma protokoll rakendada usaldusväärsust teistmoodi kui TCP, et olla efektiivsem videomängude tingimustes.

Nii et, kui TCP on nii halb, siis kas me hakkame looma oma transportprotokolli UDP põhjal?

Asjad on veidi keerulisemad. Isegi kui TCP on peaaegu suboptimaalne mängu veebisüsteemide jaoks, võib see teie mängus siiski väga hästi töötada ja säästa teie väärtuslikku aega. Näiteks ei pruugi viivitus olla probleem käigupõhises mängus või mängus, mida saab mängida ainult LAN-võrkudes, kus viivitused ja pakettide kaotus on palju väiksemad kui Internetis.

Paljudes edukates mängudes, sealhulgas World of Warcraft, Minecraft ja Terraria, kasutatakse TCP-d. Kuid enamikes FPS-idest kasutatakse oma UDP-põhiseid protokolle, seega räägime neist allpool lähemalt.

Kui otsustate kasutada TCP-d, veenduge, et oleks välja lülitatud Nagle'i algoritm, sest see puhastab pakette enne saatmist, mis tähendab viivituse suurenemist.

UDP ja TCP erinevuste kohta mitmängijamängude kontekstis saate lugeda Glen Fidler'i artiklit UDP vs. TCP.

Oma protokoll

Nii et soovite luua oma transportprotokolli, kuid ei tea, kust alustada? Teil on vedanud, kuna Glen Fidler on selle kohta kirjutanud kaks fantastilist artiklit. Neis on palju nutikaid mõtteid.

Esimene artikkel, Networking for Game Programmers on 2008. aastast ja lihtsam kui teine, Building A Game Network Protocol on 2016. aastast. Soovitan alustada vanemast.

Pange tähele, et Glen Fidler on suur oma UDP-põhise protokolli kasutamise toetaja. Ja pärast tema artiklite lugemist võtate tõenäoliselt tema seisukoha, et TCP-l on videomängudes tõsiseid puudusi ja soovite ellu viia oma protokolli.

Kuid kui olete võrgu töödes uus, siis tehke endale teene ja kasutage TCP-d või mõnda raamatukogu. Oma transportprotokolli edukaks rakendamiseks peate eelnevalt palju õppima.

Võrguraamatukogud

Kui vajate midagi tõhusamat kui TCP, kuid ei soovi oma protokolli rakendamisega vaeva näha ja paljudesse üksikasjadesse süveneda, saate kasutada võrguraamatukogu. Neid on väga palju:

• yojimbo Glen Fidler
• RakNet, mis ei saa enam toetust, kuid selle forks SLikeNet paistab endiselt aktiivne.
• ENet on raamatukogu, mis loodi mitmängijamängu FPS-i jaoks. Cube
• GameNetworkingSockets Valve'i ettevõttest

Ma ei ole neid kõiki proovinud, kuid eelistan ENet'i, kuna see on kasutajasõbralik ja usaldusväärne. Samuti on sellel arusaadav dokumentatsioon ja algajatele mõeldud juhend.

Transportprotokoll: kokkuvõte

Kokkuvõttes on olemas kaks peamist transportprotokolli: TCP ja UDP. TCP-l on palju kasulikke omadusi: usaldusväärsus, pakettide järjekorra säilitamine, vigade tuvastamine. UDP-l seda ei ole, kuid TCP-l on loomulikult suuremad viivitused, mis ei sobi mõnede mängude jaoks. Seega, et tagada madalad viivitused, võib luua oma protokolli UDP põhjal või kasutada teeki, mis rakendab UDP-l põhinevat transportprotokolli ja on kohandatud mitmikmängude jaoks.

Valik TCP, UDP ja teeki vahel sõltub mitmest tegurist. Esiteks mängu vajadustest: kas on vajalikud madalad viivitused? Teiseks rakenduse protokolli nõuetest: kas on vaja usaldusväärset protokolli? Nagu näeme järgmistest osadest, võib luua rakenduse protokolli, mille jaoks sobib täiesti usaldusväärne protokoll. Lõpuks tuleb arvestada ka võrgu mootori arendaja kogemustega.

Mul on kaks soovitust:

• Maksimaalselt abstraktselt transportprotokolli ülejäänud rakendusest, et seda oleks võimalik lihtsalt vahetada, ilma et peaksite kogu koodi ümber kirjutama.
• Ärge tegelege enneaegse optimeerimisega. Kui te pole võrgu spetsialist ja ei ole kindel, kas vajate UDP põhist oma transportprotokolli, siis võite alustada TCP-st või teegist, mis tagab usaldusväärsuse, ning seejärel testida ja mõõta jõudlust. Kui tekivad probleemid ja olete kindel, et põhjuseks on transportprotokoll, siis võib-olla on aeg luua oma transportprotokoll.

Käesoleva osa lõpetuseks soovitan lugeda Multiplayer Mängu Programmeerimise Sissejuhatus Bryan Hook'i poolt, kus käsitletakse palju siin arutatud teemasid.

Rakenduse protokoll

Nüüd, kui me saame andmeid vahetada kliendi ja serveri vahel, tuleb otsustada, milliseid andmeid edastada ja millises formaadis.

Klassikaline skeem on see, et kliendid saadavad serverile sisendi või toimingud, samas kui server saadab klientidele nüüdse mängu oleku.

Server saadab mitte täielikku, vaid filtreeritud olekut koos mängijaga lähedal asuvate objektidega. Ta teeb seda kolmel põhjusel. Esiteks võib täielik olek edastamisel olla liiga suur, et seda sagedasti edastada. Teiseks huvitavad kliente peamiselt visuaalsed ja helidata, kuna suurem osa mängulogikast simuleeritakse mängu serveris. Kolmandaks, mõnedes mängudes ei tohiks mängija teada teatud andmeid, näiteks vastase positsiooni kaardi teises otsas, sest vastasel juhul võib ta pakette nuhkida ja täpselt teada, kuhu liikuda, et teda ära tappa.

Serialiseerimine

Esimene samm on andmete, mida soovime edastada (sisend või mänguolek), teisendamine edastamiseks sobivasse formaati. Seda protsessi nimetatakse serialiseerimiseks.

Esimesena tuleb meelde mõte kasutada inimloetavat formaati, näiteks JSON või XML. Kuid see oleks täiesti ebatõhus ja raiskaks suure osa kanalist.

Seetõttu on soovitatav kasutada binaarfaili formaati, mis on palju kompaktsem. See tähendab, et paketid sisaldavad vaid mõnda bitti. Siin tuleb arvesse võtta bitti järjekorda, mis võib erinevates arvutites erineda.

Andmete serialiseerimiseks võib kasutada erinevaid teeke, näiteks:

• FlatBuffers Google'ilt
• Cap’n Proto Sandstorm'ilt
• cereal Shane Granti ja Randolph Voorhisi

Lihtsalt veenduge, et teek loob kantavaid arhiive ja hoolitseb bitti järjekorra eest.

Alternatiivne lahendus võiks olla ise teostamine, see ei ole eriti keeruline, eriti kui teie koodis kasutatakse andmeorienteeritud lähenemist. Lisaks võimaldab see teil teostada optimeerimisi, mis ei pruugi alati olla võimalik teegi kasutamise korral.

Glenn Fidler on kirjutanud serialiseerimisest kaks artiklit: Pakettide lugemine ja kirjutamine ja Serialiseerimisstrateegiad.

Kompressioon

Andmete hulk, mis edastatakse klientide ja serveri vahel, on piiratud kanali läbilaskevõimega. Andmete tihendamine võimaldab edastada igas snapshots rohkem andmeid, suurendada värskendussagedust või lihtsalt vähendada kanali nõudeid.

Biti pakkimine

Esimene tehnika on bitipakendamine. See seisneb just nii palju bite kasutamises, kui on vajalik soovitud väärtuse kirjeldamiseks. Näiteks, kui teil on loend, mis võib omada 16 erinevat väärtust, siis võib ühe täisbaiti (8 bitti) asemel kasutada vaid 4 bitti.

Glenn Fiddler selgitab, kuidas seda ellu viia, artikli teises osas. Pakettide lugemine ja kirjutamine.

Bitipakendamine toimib eriti hästi diskreetsuse korral, mis on järgmise osa teema.

Diskreetsus

Diskreetsus on kaotusega kompressioonitehnika, mis seisneb selles, et väärtuse kodeerimiseks kasutatakse ainult osade valikute alamhulka. Diskreetsuse rakendamine on kõige lihtsam ujukoma numbrite ümardamise teel.

Glenn Fiddler (taas!) näitab, kuidas rakendada diskreetsust praktikas, oma artiklis. Snapshot Compression.

Kompressioonialgoritmid

Järgmine tehnika on kaotusteta kompressioonialgoritmid.

Siin on minu arvates kolm kõige huvitavamat algoritmi, millest peaks teadma:

• Nüüd, kui oleme tutvunud muutuva pikkusega kodeerimise ja eelseisva reegliga, räägime Huffmani kodeerimisest. eelnevalt arvutatud koodiga, mis on äärmiselt kiire ja võib anda häid tulemusi. Seda on kasutatud pakettide kompressiooniks Quake3 võrgu mootoris.
• zlib on üldotstarbeline kompressioonialgoritm, mis ei suurenda kunagi andmete mahtu. Kuidas näha siin, on seda rakendatud paljudes rakendustes. Oleks see võib-olla ülearune olekute värskendamiseks. Aga see võib ka osutuda kasulikuks, kui peate serverilt klientidele edastama varasid, pikki tekste või maanõgusid.
• Pikkade jadade kopeerimine on tõenäoliselt kõige lihtsam kompressioonialgoritm, kuid see on teatud tüüpi andmete jaoks väga tõhus ja seda saab kasutada eeltöötluse etapina enne zlib-i. See sobib eriti hästi maanõgude kompressiooniks, mis koosneb plaadist või vookidest, kus palju naaber-elemente kordub.

Delta-kompressioon

Viimane kompressioonimeetod on delta-kompressioon. See seisneb selles, et edastatakse ainult erinevused praeguse mängu oleku ja viimase seisundi vahel, mille klient on saanud.

Esmakordselt rakendati seda Quake3 võrgu mootoris. Siin on kaks artiklit, mis selgitavad selle kasutamise viisi:

• The Quake3 Networking Model Bryan Hook
• Quake 3 Source Code Review: Network Model Fabien Sanglar [tõlge artikkel Habr, vt jaotist „Võrgu mudel”]

Glenn Fiddler kasutas seda ka oma artikli teises osas. Snapshot Compression.

Krüpteerimine

Lisaks peate võib-olla krüpteerima teabe edastamise klientide ja serveri vahel. Sellel on mitu põhjust:

• privaatsus: sõnumeid saavad lugeda ainult vastReceiving, ja mitte ükski teine isik, kes teostab võrgu nuhkimist, ei saa neid lugeda.
• autentimine: isik, kes soovib mängija rolli täita, peab teadma tema võtit.
• pettuste vältimine: pahatahtlikel mängijatel on palju keerulisem luua oma pakette petmiseks, nad peavad paljundama krüptimise skeemi ja leidma võtme (mis muutub iga ühenduse korral).

Soovitan tungivalt kasutada selleks raamatukogu. Soovitan kasutada libsodium, kuna see on eriti lihtne ja sellel on suurepärased õpetused. Erakordselt huvitav on õpetus võtmevahetusest, mis võimaldab genereerida uusi võtmeid iga uue ühenduse korral.

Rakenduse protokoll: kokkuvõte

Sellega lõpetame rakenduse protokolli. Arvan, et tihendamine ei ole sugugi vajalik ja otsus selle kasutamiseks sõltub ainult mängust ja nõutud ribalaiusest. Krüptimine on minu arust hädavajalik, kuid esimeses prototüübis saab sellest loobuda.

Rakenduse loogika

Nüüd oleme võimelised värskendama olekut kliendis, kuid võime toime tulla viivituste probleemidega. Mängijal, kes teostab sisestamise, tuleb oodata serverilt mängu oleku värskendust, et näha, millist mõju ta maailmale avaldas.

Veelgi enam, kahe oleku värskenduse vahel on maailm täiesti staatiline. Kui oleku värskendamise sagedus on madal, on liikumine väga hüplik.

On mitmeid tehnikaid, mis aitavad seda probleemi leevendada, ja järgmises peatükis räägin nendest.

Viivituste silumise tehnikad

Kõik selles peatükis kirjeldatud tehnikad on üksikasjalikult käsitletud seerias Fast-Paced Multiplayer Gabriela Gambettalt. Soovitan tungivalt lugeda seda suurepärast artiklite seeriat. Seal on ka interaktiivne demo, mis võimaldab näha, kuidas need tehnikad praktikas toimivad.

Esimene tehnika seisneb sisendi tulemuse otseses kasutamises, ootamata serverilt vastust. Seda nimetatakse kliendipoolseks prognoosimiseks.. Kuid kui klient saab serverilt uuenduse, peab ta veenduma, et tema prognoos oli õige. Kui see nii ei ole, peab ta lihtsalt muutma oma staatust vastavalt serverilt saadud teabele, kuna server on autoriteetne. Seda tehnikat kasutati esmakordselt mängus Quake. Lisainfot selle kohta on võimalik leida artiklist. Quake Enginei koodiarvustus Fabien Sanglar [tõlge Habrists].

Teine tehnikate kogum kasutatakse teiste olendite liikumise sujuvamaks muutmiseks kahe olekuuuenduse vahel. Selle ülesande lahendamiseks on kaks meetodit: interpoleerimine ja ekstrapoleerimine. Interpoleerimise korral võetakse kaks viimast staatust ja näidatakse üleminekut ühest teise. Selle puuduseks on, et see tekitab väikest viivitust, kuna klient näeb alati seda, mis juhtus minevikus. Ekstrapoleerimine seisneb selles, et ennustatakse, kus peaksid sel ajal olendid asuma, tuginedes kliendi viimasele saadud olekule. Selle puuduseks on, et kui olend muudab liikumise suunda, siis tekib suur viga prognoosi ja tegeliku positsiooni vahel.

Viimane, kõige arenenum tehnika, mis on kasulik ainult FPS-is — see on viivituse kompenseerimine. Viivituse kompenseerimise puhul arvestab server kliendi viivitusi, kui ta sihtmärki tulistab. Näiteks, kui mängija tegi hiirelöögi oma ekraanil, kuid tegelikult oli tema sihtmärg viivituse tõttu teises kohas, oleks ebaaus keelduda mängijalt tapmise õigust viivituse tõttu. Seetõttu teeb server aja tagasi kerimise hetkel, mil mängija tulistas, et simuleerida seda, mida mängija oma ekraanil nägi, ja kontrollida kokkupõrget tema tulistamise ja sihtmärgi vahel.

Glen Fiddler (nagu alati!) kirjutas 2004. aastal artikli Network Physics (2004), milles pandi alus füüsikasimulatsiooni sünkroniseerimisele serveri ja kliendi vahel. 2014. aastal kirjutas ta uue artiklite sarja Networking Physics, milles kirjeldati muid tehnikaid füüsikasimulatsiooni sünkroniseerimiseks.

Valve'i wiki-s on ka kaks artiklit, Source Multiplayer Networking ja Viivituse kompenseerimise meetodid kliendi/serveri mänguprotokolli kujunduses ja optimeerimisel , milles käsitletakse viivituste kompenseerimist.

Petmise tõkestamine

On kaks peamist tehnikat petmise ärahoidmiseks.

Esite: petukate saatmine petudelt. Nagu juba mainitud, on hea viis selle rakendamiseks krüpteerimine.

Teine: autoritaarne server peab saama ainult käske/sisestusi/tegevusi. Klient ei tohiks omada võimalust serveri olekut muuta, välja arvatud sisendi saatmise teel. Seetõttu peab server iga kord, kui see sisendi saab, enne selle rakendamist kontrollima selle lubatavust.

Rakenduse loogika: järeldus

Soovitan teil ellu viia meetodi suurte viivituste ja madalate uuendussagedustega simuleerimiseks, et testida oma mängu käitumist halvas keskkonnas, isegi kui klient ja server töötavad samal arvutis. See lihtsustab viivituste silumise meetodite rakendamist.

Teised kasulikud ressursid

Kui soovite uurida teisi ressursse, mis on pühendatud võrgumudelitele, leiate need siit:

• Glen Fiedleri blogi — tasub lugeda tema kogu blogi, kus on palju suurepäraseid artikleid. Siin kõik artiklid, mis käsitlevad võrgutehnoloogiaid.
• Awesome Game Networking autor M. Fatih MAR — see on üksikasjalik loend artiklitest ja videotest videomängude võrgumootorite kohta.
• Uues subredditi r/gamedev wiki ka on palju kasulikke linke.

Allikas: habr.com