Viimased kaks nädalat olen töötanud oma mängu võrgumootori kallal. Enne seda ei teadnud ma mängude võrgutehnoloogiatest mitte midagi, seega lugesin hulk artikleid ja tegin palju katseid, et mõista kõiki kontseptsioone ja suuta kirjutada oma võrgumootor.

Selles juhendis soovin jagada teiega erinevaid kontseptsioone, mida peate õppima enne oma mängumootori kirjutamist, samuti parimaid ressursse ja artikleid nende õppimiseks.

Üldiselt on olemas kaks peamist tüüpi võrgusüsteeme: peer-to-peer ja kliendi-server. Peer-to-peer (p2p) arhitektuuris edastatakse andmed mis tahes ühendatud mängijate paaride vahel, samas kui kliendi-server arhitektuuris edastatakse andmed ainult mängijate ja serveri vahel.

Kuigi peer-to-peer arhitektuuri kasutatakse endiselt mõnedes mängudes, on standardiks kliendi-server arhitektuur: see on kergemini teostatav, nõuab vähem ribalaiust ja lihtsustab petmise kaitset. Seetõttu keskendume selles giidis kliendi-server arhitektuurile.

Eelkõige huvitavad meid autoriteetsed serverid: sellistes süsteemides on server alati õigus. Näiteks, kui mängija arvab, et ta asub koordinaatides (10, 5), aga server ütleb talle, et ta on (5, 3), peab klient asendama oma positsiooni selle, mille server edastab, mitte vastupidi. Autoriteetsete serverite kasutamine lihtsustab petiste tuvastamist.

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

• Transportprotokoll: kuidas andmeid edastatakse klientide ja serveri vahel.
• Rakenduse protokoll: mis edastatakse klientidelt serverile ja serverilt klientidele ning millises formaadis.
• Rakenduse loogika: kuidas edastatud andmeid kasutatakse klientide ja serveri oleku värskendamiseks.

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

Transportprotokoll

Esimene samm on valida protokoll andmete edastamiseks serveri ja klientide vahel. Selleks on kaks Interneti-protokolli: TCP ja UDP. Kuid võite luua ka oma transportprotokolli, mis põhineb ühel neist, või kasutada raamatukogu, milles need on kasutusel.

TCP ja UDP võrdlemine

N nii TCP kui ka UDP põhinevad IP. IP võimaldab paketti saata allikast saajani, kuid ei garanteeri, et saadetud pakk jõuab saajani varem või hiljem, et see jõuab temani vähemalt korra ja et pakettide järjestus saabub õigel viisil. Rohkemgi veel, pakett võib sisaldada ainult piiratud suurusega andmeid, mille määrab MTU.

UDP on lihtsalt õhuke kiht IP kohal. Seega on tal samad piirangud. Erinevalt sellest, TCP-l on palju omadusi. See tagab usaldusväärse järjestatud ühenduse kahe sõlme vahel koos vigade kontrollimisega. Seega on TCP väga mugav ning seda kasutatakse paljude teiste protokollide, näiteks, HTTP, FTP ja SMTP. Kuid kõik need funktsioonid tulevad oma hinna: latentsus.

Kuna mõista, miks need funktsioonid võivad viivitusi tekitada, on oluline aru saada, kuidas TCP töötab. Kui saatja sõlme saadab paketi vastuvõtjale, ootab ta kinnitusvastust (ACK). Kui ta ei saa seda teatud aja jooksul (sest paketid või kinnitus on kadunud või muudel põhjustel), saadab ta paketi uuesti. Veelgi enam, TCP tagab pakettide kättesaamise õiges järjekorras, seega ei saa kõik teised paketid, kuigi need on juba vastuvõetud, jääda töödeldud, kuni kadunud pakett on kätte saadud.

Kuid nagu tõenäoliselt 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 mitmel põhjusel tõhusam kui TCP. Näiteks võib see märgistada mõned paketid usaldusväärseteks ja teised mitteusaldusväärseteks. Seetõttu ei huvita seda, kas mitteusaldusväärne paket jõudis vastuvõtjani. Või võib see hallata mitut andmevoogu, et ühe voolu kadunud pakett ei aeglustaks ülejäänud vooge. Näiteks võib olla üks voog mängija sisendi jaoks ja veel üks voog vestlusmesside jaoks. Kui vestlusteade, mis ei ole hädavajalik teave, kaob, ei aeglusta see sisendi reageerimist, mis on hädavajalik. Või võib oma protokoll rakendada usaldusväärsust teisiti kui TCP, et olla mängude tingimustes efektiivsem.

Nii et kui TCP on nii halb, kas me siis loome oma UDP-põhise ülekandeprotokolli?

Asjad on veidi keerulisemad. Isegi kui TCP on mänguvõrkude jaoks peaaegu suboptimaalne, võib see teie mängus üsna hästi toimida ja säästa teie väärtuslikku aega. Näiteks ei pruugi latentsus olla probleemiks kordusmängus või mängus, mida saab mängida ainult LAN-võrkudes, kus latentsus ja pakettide kadumine on palju madalamad kui Internetis.

Paljudes edukates mängudes, sealhulgas World of Warcraft, Minecraft ja Terraria, kasutatakse TCP-d. Siiski kasutavad enamik FPS-mänge oma UDP-põhiseid protokolle, seega räägime allpool neist üksikasjalikumalt.

Kui otsustate kasutada TCP-d, veenduge, et Nagle'i algoritmon välja lülitatud, kuna see puhverdab pakette enne saatmist ja seega suurendab latentsust.

UDP ja TCP erinevuste kohta mitmikmängu kontekstis saab lugeda Glen Fidler'i artiklit UDP vs. TCP.

Kohandatud protokoll

Nii et soovite luua oma transpordiprotokolli, kuid ei tea, kust alustada? Teil on vedanud, kuna Glen Fidler on sellest kirjutanud kaks suurepäras artiklit. Neis leiate palju nutikaid mõtteid.

Esimene artikkel, Mänguprogrammide võrguühendus 2008. Aeg on lihtsam kui teine. Mänguvõrgu protokolli loomine 2016. Soovitan alustada vanemast versioonist.

Pidage meeles, et Glenn Fiddler on suure toetaja oma UDP-põhise protokolli kasutamise. Tema artiklite lugemine võib teie arvamust TCP tõsiste puuduste kohta videomängudes muuta, ja te võite soovida rakendada oma protokolli.

Kuid kui olete algaja võrgu alal, siis tehke endale teene ja kasutage TCP-d või mõnda raamatukogu. Oma transportprotokolli edukaks väljatöötamiseks peate enne palju õppima.

Võrguraamatukogud

Kui vajate midagi tõhusamat kui TCP, kuid ei soovi oma protokolli rakendamisega vaeva näha ega kõigisse üksikasjadesse süveneda, võite kasutada võrguraamatukogu. Neid on palju:

• yojimbo Glenn Fiddler
• RakNet, mis enam ei toeta, kuid selle fork SLikeNet tundub olevat veel aktiivne.
• ENet on raamatukogu, mis on loodud mitme mängijaga FPS-i jaoks Cube
• GameNetworkingSockets ettevõttelt Valve

Ma ei ole kõiki proovinud, kuid eelistan ENet'i, kuna see on lihtne kasutada ja usaldusväärne. Lisaks on sellel arusaadav dokumendi- ja algajatele suunatud juhend.

Transpordiprotokoll: kokkuvõte

Kokkuvõtteks, on olemas kaks peamist transpordiprotokolli: TCP ja UDP. TCP-l on palju kasulikke omadusi: usaldusväärsus, paketide järjekorra säilitamine, vigade tuvastamine. UDP-l seda ei ole, kuid TCP-l on omamoodi suuremad viivitused, mis ei sobi teatud mängude jaoks. Seetõttu on madalate viivituste tagamiseks võimalik luua oma protokoll UDP põhjal või kasutada teeki, mis rakendab transpordiprotokolli UDP-l ja on kohandatud mitmikmängu videomängude jaoks.

Valiku tegemine TCP, UDP ja raamatukogu vahel sõltub mitmest tegurist. Esiteks mängu vajadustest: kas on vaja madalaid latentsusviise? Teiseks rakenduse protokolli nõuetest: kas on vajalik usaldusväärne protokoll? Nagu näeme järgmises osas, saab luua rakenduse protokolli, mille jaoks sobib täielikult usaldusväärne protokoll. Lõpuks tuleb arvesse võtta ka võrgu mootorite arendaja kogemust.

Mul on kaks soovitust:

• Maksimaalselt abstraktaage transportprotokoll rakenduse ülejäänud osast, et seda saaks hõlpsasti asendada, ilma et oleks vaja kogu koodi ümber kirjutada.
• Ärge tegelege enneaegse optimeerimisega. Kui te ei ole võrgu spetsialist ega ole kindel, kas vajate UDP-põhist kohandatud transportprotokolli, siis võite alustada TCP-st või raamatukogudest, mis soovivad usaldusväärsust, ning seejärel testida ja mõõta jõudlust. Kui esinevad probleemid ja olete kindel, et põhjus on transportprotokollis, siis võib-olla on aeg luua oma transportprotokoll.

Selle osa lõpetuseks soovitan teil lugeda Introduction to Multiplayer Game Programming Bryan Hooki artikkel, kus käsitletakse mitmeid siin arutatud teemasid.

Rakendusprotokoll

Kuna me saame andmeid klientide ja serveri vahel vahetada, tuleb otsustada, milliseid andmeid edastada ja millises formaadis.

Klassikaline skeem on see, et kliendid saadavad serverile sisendeid või toiminguid ning server saadab klientidele hetke mänguseisundi.

Server edastab mitte täiusliku, vaid filtreeritud seisundi koos objektidega, mis asuvad mängijaga läheduses. Ta teeb seda kolmel põhjusel. Esiteks, täiuslik seisund võib olla liiga suur edastamiseks kõrge sagedusega. Teiseks, kliente huvitavad enamasti visuaalsed ja helid, kuna suurem osa mängu loogikast simuleeritakse mängu serveris. Kolmandaks, mõnes mängus 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 tappa.

Serialiseerimine

Esimene samm on andmete, mida soovime edastada (sisend või mänguolek), muutmine edastamiseks sobivaks formaadiks. Seda protsessi nimetatakse serialiseerimiseks.

Seetõttu tuleb kohe mõelda, et kasutame inimloetavat formaati, näiteks JSON või XML. Kuid see oleks äärmiselt ebaefektiivne ja raiskab suure osa kanalist.

Selle asemel soovitatakse kasutada binaarset formaati, mis on palju kompaktsem. See tähendab, et pakettid sisaldavad vaid mõnda baiti. Siin tuleb arvesse võtta baiti järjekorda, mis võib erinevatel arvutitel erineda.

Andmete serialiseerimiseks võib kasutada teeki, näiteks:

• FlatBuffers Google'i ettevõttest
• Cap’n Proto Sandstormi ettevõttest
• cereal Shane Granti ja Randolph Voorhise

Lihtsalt veenduge, et teek genereerib kergesti kantavaid arhiive ja hoolitseb baiti järjekorra eest.

Alternatiivseks lahenduseks võib olla ka iseseisev rakendus, mis ei ole eriliselt keeruline, eriti kui kasutate koodis andmepõhist lähenemist. Lisaks võimaldab see teil teha optimeerimisi, mis ei ole alati võimalik teegi kasutamisel.

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

Kompresseerimine

Kliendi ja serveri vahel edastatavate andmete hulk on piiratud kanali läbilaskevõimega. Andmete kompressioon võimaldab edastada igas snapshots rohkem andmeid, suurendada värskenduse sagedust või lihtsalt vähendada kanali nõudmisi.

Bitipakkimine

Esimene tehnika on bitipakkimine. See seisneb just nii paljude bitide kasutamises, kui on vajalik soovitud mõõtme kirjeldamiseks. Näiteks kui teil on loetelu, mis võib sisaldada 16 erinevat väärtust, võite kasutada ühe täispika byte'i (8 bitti) asemel vaid 4 bitti.

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

Bitipakkimine töötab eriti hästi diskretiseerimisega, mis on järgmise jaotise teema.

Diskretiseerimine

Diskretiseerimine on kaotanud kompressioonitehnika, mis kasutab mahu kodeerimiseks ainult osasetete kombinatsiooni võimalike väärtuste hulgast. Diskretiseerimist on kõige lihtsam rakendada ujukommade ümardamise kaudu.

Glenn Fiddler (taaskordus!) näitab, kuidas praktiliselt rakendada diskreetimist oma artiklis Snapshot Compression.

Kompresseerimisalgoritmid

Järgmine tehnika on kaotusteta kompressioonialgoritmid.

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

• Huffman'i kodeerimine ettearvutatud koodiga, mis on erakordselt kiire ja võib anda häid tulemusi. Seda on kasutatud pakettide kompressiooniks Quake3 võrgumootoris.
• zlib — üldotstarbeline kompressioonialgoritm, mis ei suurenda kunagi andmete mahutatavust. Nagu näha siit, on seda rakendatud paljudes valdkondades. Olemasoleku uuendamiseks võib see osutuda üleliigseks. Kuid see võib olla kasulik, kui peate saatma klientidele serverist varasid, pikki tekste või maastikku.
• Pikkade jadade kopeerimine — see on ilmselt lihtsaim kompressioonialgoritm, kuid see on väga tõhus teatud tüüpi andmete jaoks ja võib olla kasutatav eelprotsessina enne zlib'd. See sobib eriti hästi maastiku kompressiooniks, mis koosneb plaatidest või voolikutest, kus palju naabruses olevaid elemente kordub.

Delta-kompressioon

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

Esmakordselt rakendati seda Quake3 võrgumootoris. Siin on kaks artiklit, mis selgitavad selle kasutusviisi:

• Quake3 võrgumudeli Bryan Hook
• Quake 3 allika koodi ülevaade: Võrgumudel Fabien Sanglar [tõlge artikkel Habré, vt jaotist „Võrgumudel”]

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

Krüpteerimine

Lisaks võib teil olla vaja krüpteerida teabe edastamine klientide ja serveri vahel. Sellel on mitu põhjust:

• privaatsus/confidentsiaalsus: sõnumid saavad lugeda ainult saaja ning ükski teine, kes tehingut jälgib, ei suuda neid lugeda.
• autentimine: inimene, kes soovib mängija rolli täita, peab teadma tema võtit.
• pettuste vältimine: pahatahtlikel mängijatel on palju raskem luua oma pakette petmiseks, neil tuleb reprodutseerida krüptimisreeglid ja leida võti (mis muutub iga ühenduse korral).

Soovitan tungivalt kasutada selleks raamatukogu. Soovitan kasutada libsodium, kuna see on eriti lihtne ja tal on suurepärased õpetused. Erakordselt huvitav on õpetus võtmete vahetamiseks, mis võimaldab igal uuel ühendusel genereerida uusi võtmeid.

Rakenduse protokoll: kokkuvõte

Selle käigus lõpetame rakenduse protokolliga. Arvan, et kokkusurumine ei ole sugugi vajalik ja selle kasutamise otsus sõltub ainult mängust ja nõutavast ribalaiusest. Krüpteerimine on minu meelest kohustuslik, kuid esimeses prototüübis on sellest mööda saab.

Rakenduse loogika

Nüüd suudame klientide seisundit uuendada, kuid võime sattuda viivituse probleemide keskele. Mängija, kes on andmeid sisestanud, peab ootama mängu seisundi värskendust serverilt, et näha, millist mõju ta maailmale avaldas.

Lisaks sellele on kahe seisundi uuenduse vahel maailm täiesti staatiline. Kui seisundite värskendamise sagedus on madal, siis liikumine on väga katkendlik.

On mitmeid tehnikaid, mis aitavad selle probleemi mõju vähendada, ja järgmises osas räägin neist.

Viivituse sujuvuse tehnikad

Käesolevas jaotises kirjeldatud kõik tehnikad on põhjalikult käsitletud seerias Kiire tempoga mitmikmäng Gabriela Gambetta. Soovitan tungivalt lugeda seda suurepärast artiklite seeriat. Seal on ka interaktiivne demo, mis võimaldab näha, kuidas need tehnikad praktikas töötavad.

Esimene tehnika seisneb selles, et rakendatakse sisendi tulemust otse, ootamata serverilt vastust. Seda nimetatakse kliendi poole prognoosimiseks. Siiski, kui klient saab serverilt värskenduse, peab ta veenduma, et tema prognoos oli õige. Kui see ei ole nii, peab ta lihtsalt muutma oma olekut vastavalt serverilt saadud teabele, sest server on autoriteetne. Seda tehnikat kasutati esmakordselt mängus Quake. Selle kohta saab rohkem lugeda artiklis Quake Engine koodi ülevaade Fabien Sanglar [tõlge Habr].

Teine tehnikate kogum kasutatakse teiste olendite liikumise sujuvamaks muutmiseks kahe olekuuuenduse vahel. Selle ülesande lahendamiseks on kaks meetodit: interpolatsioon ja ekstrapolatsioon. Interpolatsiooni puhul võetakse kaks viimast seisundit ja näidatakse üleminekut ühest teise. Selle puuduseks on see, et see tekitab väikese viivituse, kuna klient näeb alati seda, mis toimus minevikus. Ekstrapolatsioon sõltub ennustamisest, kus need olendid peaksid praegu asuma, lähtudes kliendile saadud viimasest olekust. Selle puudus on see, et kui olend muudab liikimise suunda täielikult, tekib suur erinevus prognoosi ja tegeliku asukoha vahel.

Viimane, kõige arenenum tehnika, mis on kasulik ainult FPS-ide puhul — see on viivituse kompenseerimine. Lati kompenseerida viivitust, arvestab server mängija viivitusi, kui ta sihtmärkidele tulistab. Näiteks, kui mängija tegi oma ekraanil headshot'i, kuid reaalsuses oli tema sihtmärk viivituse tõttu mujal, oleks vale keelduda mängijalt tapmise õigust viivituse tõttu. Seega keerab server aega tagasi hetkele, mil mängija lasi, et simuleerida, mida mängija oma ekraanil nägi, ja kontrollida kokkupõrget tema lasu ja sihtmargi vahel.

Glen Fiddler (nagu alati!) kirjutas 2004. aastal artikli Network Physics (2004), millega pani aluse füüsika simuleerimise sünkroniseerimisele serveri ja kliendi vahel. 2014. aastal kirjutas ta uue artiklite seeria Networking Physics, kus ta kirjeldas teisi tehnikaid füüsika simuleerimise sünkroniseerimiseks.

Ka Valve'i ettevõtte wikis on kaks artiklit, Source Multiplayer Networking ja Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization , mis käsitlevad viivituste kompenseerimist.

Petmise ennetamine

On olemas kaks peamist tehnikat petmise ennetamiseks.

Esimene: pahatahtlike pakettide saatmise keerukus. Nagu ülalmainitud, on selle rakendamiseks hea viis krüpteerimine.

Teine: autoritaarne server peab saama ainult käske/sisestusi/tegevusi. Klient ei tohiks saada võimalust muuta serveri seisundit muud moodi kui sisendi saatmise kaudu. Seega peab server iga kord sisendi saades enne selle rakendamist kontrollima selle lubatavust.

Rakenduse loogika: kokkuvõte

Soovitan teil rakendada viisi suurte viivituste ja madalate värskendussageduste simuleerimiseks, et testida oma mängu käitumist kehvades tingimustes, isegi kui klient ja server töötavad samal arvutil. See lihtsustaks viivituste silumisvõtete rakendamist.

Teised kasulikud ressursid

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

• Glenn Fiedleri blogi — tasub lugeda kogu tema blogi, seal on palju suurepäraseid artikleid. Siit sisse on kogutud kõik artiklid võrgutehnoloogiate kohta.
• Awesome Game Networking autor M. Fatih MAR — see on põhjalik nimekiri artiklitest ja videotest videomängude võrgumootoritest.
• V subredditi r/gamedev wiki on ka palju kasulikke linke.

Allikas: habr.com