Síðustu tvær vikur hef ég verið að vinna í netvélinni fyrir leikinn minn. Fyrir það vissi ég ekkert um netkerfi í leikjum, svo ég las fullt af greinum og gerði margar tilraunir til að skilja öll hugtökin og geta skrifað mína eigin netvél.
Í þessari handbók langar mig að deila með þér hinum ýmsu hugtökum sem þú þarft að læra áður en þú skrifar þína eigin leikjavél, sem og bestu úrræði og greinar til að læra þau.
Almennt séð eru tvær megingerðir netarkitektúra: jafningi-til-jafningi og biðlari-þjónn. Í peer-to-peer (p2p) arkitektúr eru gögn flutt á milli hvaða par sem er af tengdum spilurum, en í arkitektúr viðskiptavinar-miðlara eru gögn aðeins flutt á milli leikmanna og netþjóns.
Þó að jafningi-til-jafningi arkitektúr sé enn notaður í sumum leikjum, er biðlaraþjónn staðallinn: hann er auðveldari í framkvæmd, krefst minni rásarbreiddar og auðveldar vörn gegn svindli. Þess vegna, í þessari handbók, munum við einbeita okkur að arkitektúr viðskiptavinar-miðlara.
Sérstaklega höfum við mestan áhuga á auðvaldsþjónum: í slíkum kerfum hefur þjónninn alltaf rétt fyrir sér. Til dæmis, ef spilarinn heldur að hann sé á (10, 5) og þjónninn segir honum að hann sé á (5, 3), þá ætti viðskiptavinurinn að skipta út stöðu sinni fyrir þá sem þjónninn er að tilkynna, ekki öfugt. Notkun opinberra netþjóna gerir það auðveldara að þekkja svindlara.
Það eru þrír meginþættir í leikjanetkerfum:
- Flutningasamskiptareglur: hvernig gögn eru flutt á milli viðskiptavina og netþjóns.
- Umsóknarsamskiptareglur: hvað er sent frá viðskiptavinum til þjónsins og frá þjóninum til viðskiptavina og á hvaða sniði.
- Umsóknarrökfræði: hvernig send gögn eru notuð til að uppfæra stöðu viðskiptavina og netþjóns.
Það er mjög mikilvægt að gera sér grein fyrir hlutverki hvers hluta og þeim erfiðleikum sem þeim tengjast.
Samgöngubókun
Fyrsta skrefið er að velja samskiptareglur til að flytja gögn á milli netþjónsins og viðskiptavina. Það eru tvær netsamskiptareglur fyrir þetta: и . En þú getur búið til þína eigin samskiptareglur byggða á einni þeirra eða notað bókasafn sem notar þær.
Samanburður á TCP og UDP
Bæði TCP og UDP eru byggðar á . IP gerir kleift að senda pakka frá uppruna til móttakara, en það tryggir ekki að sendur pakkinn berist fyrr eða síðar, að hann komist að honum að minnsta kosti einu sinni og að röð pakka berist í réttri röð. Þar að auki getur pakki aðeins innihaldið takmarkaða gagnastærð, gefin út af gildinu .
UDP er bara þunnt lag ofan á IP. Þess vegna hefur það sömu takmarkanir. Aftur á móti hefur TCP marga eiginleika. Það veitir áreiðanlega skipaða tengingu milli tveggja hnúta með villuskoðun. Þess vegna er TCP mjög þægilegt og er notað í mörgum öðrum samskiptareglum, til dæmis í , и . En allir þessir eiginleikar eru á verði: .
Til að skilja hvers vegna þessar aðgerðir geta valdið leynd þurfum við að skilja hvernig TCP virkar. Þegar sendandi gestgjafi sendir pakka til móttökuhýsilsins býst hann við að fá staðfestingu (ACK). Ef það fær hann ekki eftir ákveðinn tíma (vegna þess að pakkinn eða staðfestingin týndist, eða af einhverjum öðrum ástæðum), þá sendir hann pakkann aftur. Þar að auki tryggir TCP að pakkar séu mótteknir í réttri röð, þannig að þangað til tapaður pakki er móttekinn er ekki hægt að vinna alla aðra pakka, jafnvel þótt þeir hafi þegar verið mótteknir af móttökuhnútnum.
En eins og þú sennilega skilur er leynd í fjölspilunarleikjum mjög mikilvæg, sérstaklega í svo virkum tegundum eins og FPS. Þess vegna nota margir leikir UDP með eigin samskiptareglum.
Innfædd samskiptaregla byggð á UDP getur verið skilvirkari en TCP af ýmsum ástæðum. Til dæmis getur það merkt suma pakka sem trausta og aðra sem ótrausta. Því er honum alveg sama þótt óáreiðanlegi pakkinn hafi borist viðtakanda. Eða það getur unnið úr mörgum gagnastraumum þannig að pakki sem tapast í einum straumi hægir ekki á öðrum straumum. Til dæmis gæti verið þráður fyrir inntak spilara og annar þráður fyrir spjallskilaboð. Ef spjallskilaboð sem eru ekki brýn gögn glatast, mun það ekki hægja á inntakinu sem er brýnt. Eða sérsamskiptareglur gætu innleitt áreiðanleika öðruvísi en TCP til að vera skilvirkari í tölvuleikjaumhverfi.
Svo, ef TCP sjúga, þá erum við að fara að byggja okkar eigin flutningssamskiptareglur byggðar á UDP?
Allt er aðeins flóknara. Jafnvel þó að TCP sé næstum óákjósanlegur fyrir leikjanetkerfi, getur það virkað nokkuð vel fyrir þinn sérstaka leik og sparað þér dýrmætan tíma. Til dæmis gæti leynd ekki verið vandamál fyrir leik sem byggir á röð eða leik sem aðeins er hægt að spila á staðarnetum, þar sem leynd og pakkatap eru mun minni en á netinu.
Margir vel heppnaðir leikir, þar á meðal World of Warcraft, Minecraft og Terraria, nota TCP. Hins vegar nota flestir FPS-ar eigin UDP-undirstaða samskiptareglur, svo við munum tala meira um þær hér að neðan.
Ef þú velur að nota TCP skaltu ganga úr skugga um að það sé óvirkt , vegna þess að það bætir pakka fyrir sendingu, sem þýðir að það eykur seinkunina.
Til að læra meira um muninn á UDP og TCP í samhengi við fjölspilunarleiki, sjá grein Glenn Fiedler .
Eiginbókun
Svo þú vilt búa til þína eigin flutningsreglur en veist ekki hvar á að byrja? Þú ert heppinn, því Glenn Fiedler skrifaði tvær ótrúlegar greinar um það. Þú munt finna fullt af snjöllum hugmyndum í þeim.
Fyrsta grein 2008, auðveldara en annað 2016. Ég mæli með því að þú byrjir á þeim eldri.
Vertu meðvituð um að Glenn Fiedler er mikill talsmaður þess að nota eigin samskiptareglur byggðar á UDP. Og eftir að hafa lesið greinar hans muntu líklega taka upp þá skoðun hans að TCP hafi alvarlega galla í tölvuleikjum og þú munt vilja innleiða þína eigin siðareglur.
En ef þú ert nýr í netkerfi skaltu gera þér greiða og nota TCP eða bókasafn. Til að innleiða eigin flutningsreglur með góðum árangri þarftu að læra mikið fyrirfram.
Netsöfn
Ef þú þarft eitthvað skilvirkara en TCP, en vilt ekki nenna að innleiða þína eigin samskiptareglur og fara í fullt af smáatriðum, geturðu notað netsafnið. Það eru fullt af þeim:
- Glenn Fiedler
- , sem er ekki lengur studd, heldur gaffli hennar virðist vera virkur.
- er bókasafn búið til fyrir fjölspilunar FPS
- eftir Valve
Ég hef ekki prófað þá alla, en ég vil frekar ENet vegna þess að það er auðvelt í notkun og áreiðanlegt. Að auki hefur það skýr skjöl og kennsluefni fyrir byrjendur.
Niðurstaða samgöngubókunar
Til að draga saman, þá eru tvær helstu flutningsreglur: TCP og UDP. TCP hefur marga gagnlega eiginleika: áreiðanleika, varðveislu pakkanöðunar, villugreining. UDP hefur ekki allt þetta, en TCP, eðli málsins samkvæmt, hefur mikla leynd sem er óviðunandi fyrir suma leiki. Það er að segja, til að tryggja litla leynd geturðu búið til þína eigin samskiptareglur byggða á UDP eða notað bókasafn sem útfærir flutningssamskiptaregluna á UDP og er aðlagað fyrir fjölspilunar tölvuleiki.
Valið á milli TCP, UDP og bókasafnsins fer eftir nokkrum þáttum. Í fyrsta lagi, út frá þörfum leiksins: þarf hann litla leynd? Í öðru lagi, út frá kröfum umsóknarsamskiptareglunnar: þarf hún áreiðanlega siðareglur? Eins og við munum sjá í næsta hluta er hægt að búa til forritasamskiptareglur sem óáreiðanlegar samskiptareglur henta vel. Að lokum þarftu líka að huga að reynslu netvélarframleiðandans.
Ég er með tvö ráð:
- Dragðu flutningssamskiptaregluna eins mikið og mögulegt er úr restinni af forritinu þannig að auðvelt sé að skipta um hana án þess að endurskrifa allan kóðann.
- Ekki ofhagræða. Ef þú ert ekki sérfræðingur í netkerfi og ert ekki viss um hvort þú þurfir þína eigin UDP-undirstaða flutningssamskiptareglur geturðu byrjað með TCP eða bókasafni sem veitir áreiðanleika og síðan prófað og mælt árangur. Ef þú átt í vandræðum og þú ert viss um að þetta sé flutningssamskiptareglur, þá gæti verið kominn tími til að búa til þína eigin flutningsreglu.
Í lok þessa hluta mæli ég með að þú lesir Brian Hook, sem fjallar um mörg efni sem fjallað er um hér.
Umsóknarbókun
Nú þegar við getum skipt gögnum á milli viðskiptavina og netþjónsins þurfum við að ákveða hvaða gögn á að flytja og á hvaða sniði.
Klassíska kerfið er að viðskiptavinir senda inntak eða aðgerðir til netþjónsins og þjónninn sendir núverandi leikjastöðu til viðskiptavinanna.
Miðlarinn sendir ekki allt, heldur síað ástand með einingum sem eru nálægt spilaranum. Hann gerir þetta af þremur ástæðum. Í fyrsta lagi gæti heildarástandið verið of stórt til að senda á háum tíðni. Í öðru lagi hafa viðskiptavinir aðallega áhuga á sjón- og hljóðgögnum, vegna þess að mestur hluti leikjafræðinnar er hermdur á leikjaþjóninum. Í þriðja lagi, í sumum leikjum þarf leikmaðurinn ekki að vita tiltekin gögn, eins og staðsetningu óvinarins hinum megin á kortinu, því annars getur hann þefað af pökkum og vitað nákvæmlega hvert hann á að færa sig til að drepa hann.
Serialization
Fyrsta skrefið er að breyta gögnunum sem við viljum senda (inntak eða leikjaástand) í snið sem hentar til sendingar. Þetta ferli er kallað .
Hugmyndin kemur strax upp í hugann að nota læsilegt snið, eins og JSON eða XML. En þetta verður algjörlega óhagkvæmt og mun taka mestan hluta rásarinnar fyrir ekki neitt.
Þess í stað er mælt með því að nota tvöfalda sniðið, sem er mun þéttara. Það er að pakkarnir innihalda aðeins nokkur bæti. Hér verðum við að taka tillit til vandans , sem getur verið mismunandi á mismunandi tölvum.
Til að raðgreina gögn geturðu notað bókasafn, til dæmis:
- Sandstormur
- Shane Grant og Randolph Voorhees
Gakktu úr skugga um að bókasafnið búi til færanleg skjalasafn og sjái um endianness.
Önnur lausn væri að innleiða það sjálfur, það er ekki svo erfitt, sérstaklega ef þú ert að nota gagnamiðaða nálgun í kóðanum þínum. Að auki mun það gera þér kleift að framkvæma hagræðingar sem eru ekki alltaf mögulegar þegar þú notar bókasafnið.
Glenn Fiedler hefur skrifað tvær greinar um serialization: и .
Þjöppun
Magn gagna sem flutt er á milli viðskiptavina og netþjóns er takmarkað af bandbreidd rásarinnar. Gagnaþjöppun gerir þér kleift að flytja fleiri gögn í hverri skyndimynd, auka hressingarhraðann eða einfaldlega draga úr bandbreiddarkröfum.
Bita pakkning
Fyrsta tæknin er bitapökkun. Það felst í því að nota nákvæmlega þann fjölda bita sem er nauðsynlegur til að lýsa æskilegu gildi. Til dæmis, ef þú ert með upptalningu sem getur haft 16 mismunandi gildi, þá geturðu notað aðeins 8 bita í stað heils bæti (4 bita).
Glenn Fiedler útskýrir hvernig eigi að útfæra þetta í seinni hluta greinarinnar. .
Bitapökkun virkar sérstaklega vel með greiningu, sem verður umfjöllunarefni næsta kafla.
Sýnataka
er tapsbundin þjöppunartækni sem notar aðeins undirmengi mögulegra gilda til að umrita gildi. Auðveldasta leiðin til að innleiða misskilning er með því að námunda fljótandi tölur.
Glenn Fiedler (aftur!) sýnir hvernig eigi að beita sérvisku í verki í grein sinni .
Þjöppunaralgrím
Næsta tækni verður taplaus þjöppunaralgrím.
Hér eru að mínu mati þrjú áhugaverðustu reiknirit sem þú þarft að vita:
- með fyrirfram reiknuðum kóða, sem er einstaklega fljótur og getur skilað góðum árangri. Það var notað til að þjappa pakka í Quake3 netvélinni.
- er almennt þjöppunaralgrím sem eykur aldrei gagnamagnið. Hvernig geturðu séð , það hefur verið notað í ýmsum forritum. Fyrir uppfærsluríki gæti það verið óþarfi. En það getur komið sér vel ef þú þarft að senda eignir, langan texta eða landslag til viðskiptavina frá þjóninum.
- er líklega einfaldasta þjöppunaralgrímið, en það er mjög skilvirkt fyrir ákveðnar tegundir gagna og hægt að nota það sem forvinnsluskref fyrir zlib. Það er sérstaklega hentugur til að þjappa landslagi sem samanstendur af flísum eða voxels þar sem margir nálægir þættir eru endurteknir.
delta þjöppun
Lokaþjöppunartæknin er deltaþjöppun. Það liggur í þeirri staðreynd að aðeins munurinn á núverandi leikjaástandi og síðasta ástandi sem viðskiptavinurinn fékk er sendur.
Það var fyrst notað í Quake3 netvélinni. Hér eru tvær greinar sem útskýra hvernig á að nota það:
- Brian Hook
- Fabien Sanglars [ greinar um Habré, sjá kaflann „Netkerfi“]
Glenn Fiedler notaði það líka í seinni hluta greinar sinnar. .
Dulkóðun
Að auki gætir þú þurft að dulkóða sendingu upplýsinga milli viðskiptavina og netþjóns. Það eru nokkrar ástæður fyrir þessu:
- Persónuvernd/trúnaður: Aðeins viðtakandinn getur lesið skilaboð og enginn annar netsnipper getur lesið þau.
- auðkenning: einstaklingur sem vill leika hlutverk leikmanns verður að þekkja lykilinn hans.
- svindlforvarnir: það verður mun erfiðara fyrir illgjarna leikmenn að búa til sína eigin svindlpakka, þeir verða að endurtaka dulkóðunarkerfið og finna lykilinn (sem breytist á hverri tengingu).
Ég mæli eindregið með því að nota bókasafn fyrir þetta. Ég mæli með að nota , vegna þess að það er sérstaklega einfalt og hefur frábær kennsluefni. Sérstaklega áhugavert er námskeiðið um , sem gerir þér kleift að búa til nýja lykla fyrir hverja nýja tengingu.
Umsóknarbókun: Niðurstaða
Þetta lýkur umsóknarreglunum. Ég tel að þjöppun sé algjörlega valfrjáls og ákvörðunin um að nota hana fer aðeins eftir leiknum og nauðsynlegri bandbreidd. Dulkóðun er að mínu mati skylda, en í fyrstu frumgerðinni geturðu verið án hennar.
Umsókn rökfræði
Við getum nú uppfært stöðuna í biðlaranum, en við gætum lent í leynd vandamálum. Spilarinn, eftir að hafa lagt inn, þarf að bíða eftir uppfærslu leikstöðu frá þjóninum til að sjá hvaða áhrif það hefur haft á heiminn.
Þar að auki, á milli tveggja ríkisuppfærslna, er heimurinn algjörlega kyrrstæður. Ef ástand uppfærsluhraða er lágt, þá verða hreyfingarnar mjög rykktar.
Það eru nokkrar aðferðir til að draga úr áhrifum þessa vandamáls og ég mun fjalla um þær í næsta kafla.
Töf sléttunartækni
Allar þær aðferðir sem lýst er í þessum hluta eru ræddar í smáatriðum í röðinni. Gabríel Gambetta. Ég mæli eindregið með því að lesa þessa ágætu greinaröð. Það inniheldur einnig gagnvirka kynningu til að sjá hvernig þessar aðferðir virka í reynd.
Fyrsta aðferðin er að beita inntaksniðurstöðunni beint án þess að bíða eftir svari frá þjóninum. Það er kallað spá viðskiptavinarhliðar. Hins vegar, þegar viðskiptavinurinn fær uppfærslu frá þjóninum, verður hann að staðfesta að spá hans hafi verið rétt. Ef þetta er ekki raunin, þá þarf hann bara að breyta ástandi sínu í samræmi við það sem hann fékk frá þjóninum, því þjónninn er valdsmannslegur. Þessi tækni var fyrst notuð í Quake. Þú getur lesið meira um það í greininni. Fabien Sanglars [ á Habré].
Annað sett af aðferðum er notað til að jafna hreyfingu annarra aðila á milli tveggja ríkisuppfærslu. Það eru tvær leiðir til að leysa þetta vandamál: innreikningur og framreikningur. Ef um er að ræða innskot eru síðustu tvö stöðurnar teknar og skiptingin frá einu til annars sýnd. Ókostur þess er að það veldur litlu broti af töfinni, því viðskiptavinurinn sér alltaf hvað gerðist í fortíðinni. Framreikningur snýst um að spá fyrir um hvar einingarnar ættu að vera núna miðað við síðasta ástand sem viðskiptavinurinn fékk. Ókostur þess er sá að ef einingin breytir algjörlega stefnu hreyfingar, þá verður mikil skekkja á milli spár og raunverulegrar stöðu.
Síðasta, fullkomnasta tæknin, sem er aðeins gagnleg í FPS, er töf bætur. Þegar töf bætur eru notaðar tekur þjónninn mið af töfum viðskiptavinarins þegar hann skýtur á skotmarkið. Til dæmis, ef leikmaður gerði höfuðskot á skjánum sínum, en í raun var skotmark hans á öðrum stað vegna seinkunarinnar, þá væri ósanngjarnt að neita leikmanninum um réttinn til að drepa vegna seinkunarinnar. Þannig að þjónninn spólar tímanum til baka til þess þegar leikmaðurinn skaut til að líkja eftir því sem leikmaðurinn sá á skjánum sínum og athuga hvort árekstur sé á milli skots hans og skotmarksins.
Glenn Fiedler (eins og alltaf!) skrifaði grein árið 2004 , þar sem hann lagði grunninn að samstillingu eðlisfræðihermuna milli netþjónsins og viðskiptavinarins. Árið 2014 skrifaði hann nýja röð greina , þar sem hann lýsti öðrum aðferðum til að samstilla eðlisfræðilíkingar.
Það eru líka tvær greinar á wiki Valve, и fjalla um dráttarbætur.
Forvarnir gegn svindli
Það eru tvær helstu aðferðir til að koma í veg fyrir svindl.
Í fyrsta lagi að gera það erfiðara fyrir svindlara að senda illgjarna pakka. Eins og getið er hér að ofan er dulkóðun góð leið til að innleiða það.
Í öðru lagi ætti opinberi þjónninn aðeins að fá skipanir/inntak/aðgerðir. Viðskiptavinurinn ætti ekki að geta breytt stöðunni á þjóninum öðruvísi en með því að senda inntak. Síðan verður þjónninn, í hvert skipti sem hann fær inntak, að athuga hvort það sé réttmætt áður en það er notað.
Umsókn rökfræði: Niðurstaða
Ég mæli með því að þú innleiðir leið til að líkja eftir mikilli leynd og lágum endurnýjunartíðni svo þú getir prófað hegðun leiksins þíns við slæmar aðstæður, jafnvel þegar biðlarinn og þjónninn eru í gangi á sömu vélinni. Þetta einfaldar mjög innleiðingu tafasléttunartækni.
Önnur gagnleg úrræði
Ef þú vilt kanna önnur netkerfismódel geturðu fundið þau hér:
- — það er þess virði að lesa allt bloggið hans, það eru margar frábærar greinar í því. öllum greinum um nettækni er safnað.
- eftir M. Fatih MAR er yfirgripsmikill listi yfir greinar og myndbönd um tölvuleikjanetvélar.
- В Það eru líka margir gagnlegir tenglar.
Heimild: www.habr.com