ProHoster > blog > Utawala > Kuhusu mfano wa mtandao katika michezo kwa Kompyuta

Kuhusu mfano wa mtandao katika michezo kwa Kompyuta

Kuhusu mfano wa mtandao katika michezo kwa Kompyuta
Kwa wiki mbili zilizopita nimekuwa nikifanya kazi kwenye injini ya mtandaoni ya mchezo wangu. Kabla ya hili, sikujua chochote kuhusu mitandao katika michezo, kwa hiyo nilisoma makala nyingi na kufanya majaribio mengi kuelewa dhana zote na kuweza kuandika injini yangu ya mtandao.

Katika mwongozo huu, ningependa kushiriki nawe dhana mbalimbali unazohitaji kujifunza kabla ya kuandika injini yako ya mchezo, pamoja na nyenzo bora na makala za kujifunza.

Kwa ujumla, kuna aina mbili kuu za usanifu wa mtandao: peer-to-peer na mteja-server. Katika usanifu wa peer-to-peer (p2p), data huhamishwa kati ya jozi zozote za wachezaji waliounganishwa, wakati katika usanifu wa seva ya mteja, data huhamishwa kati ya wachezaji na seva pekee.

Ingawa usanifu wa kati-kwa-rika bado unatumika katika baadhi ya michezo, seva-teja ndiyo kiwango cha kawaida: ni rahisi kutekeleza, inahitaji upana wa kituo kidogo, na hurahisisha kulinda dhidi ya udanganyifu. Kwa hiyo, katika somo hili tutazingatia usanifu wa seva ya mteja.

Hasa, tunavutiwa zaidi na seva za mamlaka: katika mifumo kama hiyo, seva ni sawa kila wakati. Kwa mfano, ikiwa mchezaji anafikiria yuko kwenye kuratibu (10, 5), na seva inamwambia kuwa yuko (5, 3), basi mteja anapaswa kubadilisha nafasi yake na ile iliyoripotiwa na seva, na sio makamu. kinyume chake. Kutumia seva zilizoidhinishwa hurahisisha kutambua walaghai.

Mifumo ya michezo ya mtandao ina vipengele vitatu kuu:

  • Itifaki ya usafiri: jinsi data inavyohamishwa kati ya wateja na seva.
  • Itifaki ya maombi: ni nini kinachopitishwa kutoka kwa wateja hadi kwa seva na kutoka kwa seva hadi kwa wateja na kwa muundo gani.
  • Mantiki ya programu: jinsi data iliyohamishwa inatumiwa kusasisha hali ya wateja na seva.

Ni muhimu sana kuelewa jukumu la kila sehemu na changamoto zinazohusiana nazo.

Itifaki ya usafiri

Hatua ya kwanza ni kuchagua itifaki ya kusafirisha data kati ya seva na wateja. Kuna itifaki mbili za mtandao kwa hii: TCP ΠΈ UDP. Lakini unaweza kuunda itifaki yako ya usafiri kulingana na mojawapo au kutumia maktaba inayozitumia.

Ulinganisho wa TCP na UDP

TCP na UDP zote zinatokana na IP. IP inaruhusu pakiti kupitishwa kutoka chanzo hadi kwa mpokeaji, lakini haihakikishi kwamba pakiti iliyotumwa itafikia mpokeaji mapema au baadaye, kwamba itaifikia angalau mara moja, na kwamba mlolongo wa pakiti utafika katika sahihi. agizo. Aidha, pakiti inaweza tu kuwa na kiasi kidogo cha data, iliyotolewa na MTU.

UDP ni safu nyembamba tu juu ya IP. Kwa hiyo, ina vikwazo sawa. Kwa kulinganisha, TCP ina sifa nyingi. Inatoa muunganisho wa kuaminika, wa utaratibu kati ya nodi mbili na ukaguzi wa makosa. Kwa hivyo, TCP ni rahisi sana na inatumika katika itifaki zingine nyingi, k.m. HTTP, FTP ΠΈ SMTP. Lakini vipengele hivi vyote vinakuja kwa bei: kuchelewesha.

Ili kuelewa ni kwa nini vipengele hivi vinaweza kusababisha muda wa kusubiri, tunahitaji kuelewa jinsi TCP inavyofanya kazi. Wakati nodi ya kutuma inasambaza pakiti kwa nodi ya kupokea, inatarajia kupokea kukiri (ACK). Ikiwa baada ya muda fulani haipati (kwa sababu pakiti au uthibitisho ulipotea, au kwa sababu nyingine), basi hutuma tena pakiti. Zaidi ya hayo, TCP inahakikisha kwamba pakiti hupokelewa kwa utaratibu sahihi, hivyo mpaka pakiti iliyopotea ipokewe, pakiti nyingine zote haziwezi kusindika, hata ikiwa tayari zimepokelewa na mwenyeji anayepokea.

Lakini kama unavyoweza kufikiria, utulivu katika michezo ya wachezaji wengi ni muhimu sana, haswa katika aina zilizojaa vitendo kama FPS. Hii ndiyo sababu michezo mingi hutumia UDP na itifaki yao wenyewe.

Itifaki asili ya UDP inaweza kuwa bora zaidi kuliko TCP kwa sababu mbalimbali. Kwa mfano, inaweza kuashiria baadhi ya pakiti kama zinazoaminika na nyingine kama zisizoaminika. Kwa hivyo, haijalishi ikiwa pakiti isiyoaminika inamfikia mpokeaji. Au inaweza kuchakata mitiririko mingi ya data ili pakiti iliyopotea katika mtiririko mmoja isipunguze mitiririko iliyosalia. Kwa mfano, kunaweza kuwa na thread kwa ajili ya ingizo la mchezaji na thread nyingine ya ujumbe wa gumzo. Ikiwa ujumbe wa gumzo ambao sio wa dharura utapotea, hautapunguza kasi ya kuingiza ambayo ni ya dharura. Au itifaki ya umiliki inaweza kutekeleza kutegemewa tofauti na TCP kuwa bora zaidi katika mazingira ya mchezo wa video.

Kwa hivyo, ikiwa TCP inasumbua sana, basi tutaunda itifaki yetu ya usafiri kulingana na UDP?

Ni ngumu zaidi kidogo. Ingawa TCP inakaribia kuwa ndogo kwa mifumo ya mtandao wa michezo ya kubahatisha, inaweza kufanya kazi vyema kwa mchezo wako mahususi na kukuokoa wakati muhimu. Kwa mfano, muda wa kusubiri hauwezi kuwa suala la mchezo wa zamu au mchezo ambao unaweza kuchezwa tu kwenye mitandao ya LAN, ambapo muda wa kusubiri na upotevu wa pakiti ni wa chini zaidi kuliko kwenye Mtandao.

Michezo mingi yenye mafanikio, ikiwa ni pamoja na World of Warcraft, Minecraft na Terraria, hutumia TCP. Hata hivyo, Ramprogrammen nyingi hutumia itifaki zao zenye msingi wa UDP, kwa hivyo tutazungumza zaidi kuzihusu hapa chini.

Ukiamua kutumia TCP, hakikisha imezimwa Algorithm ya Nagle, kwa sababu huhifadhi pakiti kabla ya kutuma, ambayo inamaanisha inaongeza muda wa kusubiri.

Ili kupata maelezo zaidi kuhusu tofauti kati ya UDP na TCP katika muktadha wa michezo ya wachezaji wengi, unaweza kusoma makala ya Glenn Fiedler. UDP dhidi ya TCP.

Itifaki mwenyewe

Kwa hivyo unataka kuunda itifaki yako ya usafiri, lakini hujui pa kuanzia? Una bahati kwa sababu Glenn Fiedler ameandika makala mbili za kushangaza kuhusu hili. Utapata mawazo mengi ya busara ndani yao.

Makala ya kwanza Mitandao kwa Waandaaji Programu wa Michezo 2008, rahisi kuliko ya pili, Kuunda Itifaki ya Mtandao wa Mchezo 2016. Ninapendekeza uanze na wakubwa.

Kumbuka kuwa Glenn Fiedler ni mtetezi mkuu wa kutumia itifaki maalum kulingana na UDP. Na baada ya kusoma nakala zake, labda utakubali maoni yake kwamba TCP ina mapungufu makubwa katika michezo ya video, na utataka kutekeleza itifaki yako mwenyewe.

Lakini kama wewe ni mgeni kwenye mitandao, jifanyie upendeleo na utumie TCP au maktaba. Ili kutekeleza kwa ufanisi itifaki yako ya usafiri, unahitaji kujifunza mengi kabla.

Maktaba za mtandao

Ikiwa unahitaji kitu bora zaidi kuliko TCP, lakini hutaki kupitia shida ya kutekeleza itifaki yako mwenyewe na kuingia kwa undani zaidi, unaweza kutumia maktaba ya mtandao. Kuna mengi yao:

Sijajaribu zote, lakini napendelea ENet kwa sababu ni rahisi kutumia na inategemewa. Kwa kuongeza, ina nyaraka wazi na mafunzo kwa Kompyuta.

Itifaki ya Usafiri: Hitimisho

Kwa muhtasari: kuna itifaki kuu mbili za usafiri: TCP na UDP. TCP ina vipengele vingi muhimu: kuegemea, uhifadhi wa utaratibu wa pakiti, kugundua makosa. UDP haina haya yote, lakini TCP kwa asili yake imeongeza muda wa kusubiri, jambo ambalo halikubaliki kwa baadhi ya michezo. Hiyo ni, ili kuhakikisha muda wa kusubiri wa chini, unaweza kuunda itifaki yako mwenyewe kulingana na UDP au kutumia maktaba inayotumia itifaki ya usafiri kwenye UDP na inachukuliwa kwa michezo ya video ya wachezaji wengi.

Chaguo kati ya TCP, UDP na maktaba inategemea mambo kadhaa. Kwanza, kutoka kwa mahitaji ya mchezo: inahitaji latency ya chini? Pili, kutoka kwa mahitaji ya itifaki ya maombi: inahitaji itifaki ya kuaminika? Kama tutakavyoona katika sehemu inayofuata, inawezekana kuunda itifaki ya maombi ambayo itifaki isiyoaminika inafaa kabisa. Hatimaye, unahitaji pia kuzingatia uzoefu wa msanidi wa injini ya mtandao.

Nina vidokezo viwili:

  • Futa itifaki ya usafiri kutoka kwa programu nyingine kadri iwezekanavyo ili iweze kubadilishwa kwa urahisi bila kuandika upya msimbo wote.
  • Usiboresha zaidi. Iwapo wewe si mtaalamu wa mitandao na huna uhakika kama unahitaji itifaki maalum ya usafiri inayotegemea UDP, unaweza kuanza na TCP au maktaba ambayo hutoa utegemezi, kisha ujaribu na kupima utendakazi. Ikiwa matatizo yanatokea na una uhakika kwamba sababu ni itifaki ya usafiri, basi inaweza kuwa wakati wa kuunda itifaki yako ya usafiri.

Mwishoni mwa sehemu hii, ninapendekeza usome Utangulizi wa Kupanga Michezo ya Wachezaji Wengi na Brian Hook, ambayo inashughulikia mada nyingi zinazojadiliwa hapa.

Itifaki ya maombi

Kwa kuwa sasa tunaweza kubadilishana data kati ya wateja na seva, tunahitaji kuamua ni data gani ya kuhamisha na katika muundo gani.

Mpango wa kawaida ni kwamba wateja hutuma ingizo au vitendo kwa seva, na seva hutuma hali ya sasa ya mchezo kwa wateja.

Seva haitumi hali kamili, lakini hali iliyochujwa na huluki ambazo ziko karibu na kichezaji. Anafanya hivi kwa sababu tatu. Kwanza, hali kamili inaweza kuwa kubwa sana kupitishwa kwa mzunguko wa juu. Pili, wateja wanavutiwa zaidi na data ya kuona na sauti, kwa sababu mantiki nyingi za mchezo huigwa kwenye seva ya mchezo. Tatu, katika baadhi ya michezo mchezaji haitaji kujua data fulani, kwa mfano, nafasi ya adui upande wa pili wa ramani, vinginevyo anaweza kunusa pakiti na kujua mahali hasa pa kuhamia ili kumuua.

Kusasisha

Hatua ya kwanza ni kubadilisha data tunayotaka kutuma (ingizo au hali ya mchezo) kuwa umbizo linalofaa kutumwa. Utaratibu huu unaitwa kufululiza.

Wazo linalokuja akilini mara moja ni kutumia umbizo linaloweza kusomeka na binadamu, kama vile JSON au XML. Lakini hii haitafanya kazi kabisa na itapoteza chaneli nyingi.

Inapendekezwa kutumia umbizo la binary badala yake, ambalo ni compact zaidi. Hiyo ni, pakiti zitakuwa na ka chache tu. Kuna tatizo la kuzingatia hapa utaratibu wa byte, ambayo inaweza kutofautiana kwenye kompyuta tofauti.

Ili kusawazisha data, unaweza kutumia maktaba, kwa mfano:

Hakikisha tu kwamba maktaba inaunda kumbukumbu zinazobebeka na inajali uthabiti.

Suluhisho mbadala ni kutekeleza mwenyewe; sio ngumu sana, haswa ikiwa unatumia mbinu ya kuzingatia data kwa nambari yako. Kwa kuongeza, itakuruhusu kufanya uboreshaji ambao hauwezekani kila wakati unapotumia maktaba.

Glenn Fiedler aliandika nakala mbili kuhusu utayarishaji wa mfululizo: Pakiti za Kusoma na Kuandika ΠΈ Mikakati ya Uratibu.

Π Π”Π ΒΆΠ  Β° Π‘, Π Ρ‘Π ΞΌ

Kiasi cha data inayohamishwa kati ya wateja na seva hupunguzwa na kipimo data cha kituo. Mfinyazo wa data utakuruhusu kuhamisha data zaidi katika kila muhtasari, kuongeza marudio ya sasisho, au kupunguza tu mahitaji ya kituo.

Ufungaji kidogo

Mbinu ya kwanza ni kufunga kidogo. Inajumuisha kutumia idadi kamili ya bits ambazo ni muhimu kuelezea thamani inayotakiwa. Kwa mfano, ikiwa una enum ambayo inaweza kuwa na maadili 16 tofauti, basi badala ya baiti nzima (biti 8), unaweza kutumia biti 4 tu.

Glenn Fiedler anaeleza jinsi ya kutekeleza hili katika sehemu ya pili ya makala Pakiti za Kusoma na Kuandika.

Ufungashaji mdogo hufanya kazi vizuri na sampuli, ambayo itakuwa mada ya sehemu inayofuata.

Sampuli

Sampuli ni mbinu ya kubana yenye hasara ambayo hutumia tu sehemu ndogo ya thamani zinazowezekana kusimba thamani. Njia rahisi zaidi ya kutekeleza utaftaji ni kwa kuzungusha nambari za sehemu zinazoelea.

Glenn Fiedler (tena!) anaonyesha jinsi ya kuweka sampuli katika vitendo katika makala yake Mfinyazo wa Picha.

Algorithms ya ukandamizaji

Mbinu inayofuata itakuwa algorithms ya compression isiyo na hasara.

Hapa, kwa maoni yangu, kuna algorithms tatu za kuvutia zaidi unahitaji kujua:

  • Huffman coding na msimbo uliokokotwa awali, ambao ni haraka sana na unaweza kutoa matokeo mazuri. Ilitumika kukandamiza pakiti kwenye injini ya mtandao ya Quake3.
  • zlib ni kanuni ya mfinyazo ya madhumuni ya jumla ambayo haiongezi kamwe kiasi cha data. Unawezaje kuona hapa, imetumika katika matumizi mbalimbali. Inaweza kuwa haihitajiki kwa kusasisha majimbo. Lakini inaweza kuwa muhimu ikiwa unahitaji kutuma mali, maandishi marefu au eneo kwa wateja kutoka kwa seva.
  • Kunakili urefu wa kukimbia - Labda hii ndiyo algoriti rahisi zaidi ya ukandamizaji, lakini inafaa sana kwa aina fulani za data, na inaweza kutumika kama hatua ya kuchakata kabla ya zlib. Inafaa hasa kwa kukandamiza ardhi ya eneo inayojumuisha vigae au voxels ambamo vipengele vingi vya karibu hurudiwa.

Ukandamizaji wa Delta

Mbinu ya mwisho ya ukandamizaji ni ukandamizaji wa delta. Inajumuisha ukweli kwamba tofauti tu kati ya hali ya sasa ya mchezo na hali ya mwisho iliyopokelewa na mteja hupitishwa.

Ilitumiwa kwanza kwenye injini ya mtandao ya Quake3. Hapa kuna nakala mbili zinazoelezea jinsi ya kuitumia:

Glenn Fiedler pia aliitumia katika sehemu ya pili ya makala yake Mfinyazo wa Picha.

Usimbuaji fiche

Kwa kuongeza, unaweza kuhitaji kusimba uhamisho wa habari kati ya wateja na seva. Kuna sababu kadhaa za hii:

  • faragha/usiri: ujumbe unaweza kusomwa na mpokeaji pekee, na hakuna mtu mwingine anayenusa mtandao ataweza kuzisoma.
  • authentication: uthibitisho: mtu anayetaka kucheza nafasi ya mchezaji lazima ajue ufunguo wake.
  • Uzuiaji wa kudanganya: Itakuwa ngumu zaidi kwa wachezaji hasidi kuunda vifurushi vyao vya kudanganya, watalazimika kuzaliana mpango wa usimbuaji na kupata ufunguo (ambao hubadilika kwa kila unganisho).

Ninapendekeza sana kutumia maktaba kwa hili. Ninapendekeza kutumia libsodiamu, kwa sababu ni rahisi sana na ina mafunzo bora. Kinachovutia zaidi ni mafunzo juu ya kubadilishana muhimu, ambayo hukuruhusu kutoa funguo mpya kwa kila muunganisho mpya.

Itifaki ya Maombi: Hitimisho

Hii inahitimisha itifaki yetu ya maombi. Ninaamini kuwa ukandamizaji ni wa hiari kabisa na uamuzi wa kuitumia unategemea tu mchezo na bandwidth inayohitajika. Usimbaji fiche, kwa maoni yangu, ni ya lazima, lakini katika mfano wa kwanza unaweza kufanya bila hiyo.

Mantiki ya maombi

Sasa tunaweza kusasisha hali katika mteja, lakini huenda tukakumbwa na matatizo ya muda wa kusubiri. Mchezaji, baada ya kukamilisha ingizo, anahitaji kusubiri hali ya mchezo kusasisha kutoka kwa seva ili kuona athari yake kwa ulimwengu.

Zaidi ya hayo, kati ya sasisho mbili za serikali, ulimwengu ni tuli kabisa. Ikiwa kiwango cha sasisho cha hali ni cha chini, basi harakati zitakuwa za jerky sana.

Kuna mbinu kadhaa za kupunguza athari za tatizo hili, na nitazifunika katika sehemu inayofuata.

Mbinu za Kulainisha Kuchelewa

Mbinu zote zilizoelezwa katika sehemu hii zinajadiliwa kwa kina katika mfululizo Wachezaji Wengi Wenye Haraka Gabriel Gambetta. Ninapendekeza sana kusoma mfululizo huu bora wa makala. Pia inajumuisha onyesho shirikishi ambalo hukuruhusu kuona jinsi mbinu hizi zinavyofanya kazi kwa vitendo.

Mbinu ya kwanza ni kutumia matokeo ya ingizo moja kwa moja bila kungoja jibu kutoka kwa seva. Inaitwa utabiri wa upande wa mteja. Hata hivyo, mteja anapopokea sasisho kutoka kwa seva, lazima athibitishe kwamba utabiri wake ulikuwa sahihi. Ikiwa sio hivyo, basi anahitaji tu kubadilisha hali yake kulingana na kile alichopokea kutoka kwa seva, kwa sababu seva ni ya kimabavu. Mbinu hii ilitumika kwa mara ya kwanza katika Tetemeko. Unaweza kusoma zaidi juu yake katika makala Mapitio ya nambari ya Injini ya Quake Fabien Sanglars [tafsiri juu ya Habre].

Seti ya pili ya mbinu hutumiwa kulainisha harakati za vyombo vingine kati ya sasisho mbili za serikali. Kuna njia mbili za kutatua tatizo hili: tafsiri na extrapolation. Katika kesi ya kutafsiri, majimbo mawili ya mwisho yanachukuliwa na mabadiliko kutoka kwa moja hadi nyingine yanaonyeshwa. Hasara yake ni kwamba husababisha kiasi kidogo cha kuchelewa kwa sababu mteja daima huona kilichotokea huko nyuma. Extrapolation ni kuhusu kutabiri ambapo huluki zinapaswa kuwa sasa kulingana na hali ya mwisho iliyopokelewa na mteja. Hasara yake ni kwamba ikiwa chombo kinabadilisha kabisa mwelekeo wa harakati, basi kutakuwa na kosa kubwa kati ya utabiri na nafasi halisi.

Mbinu ya hivi punde, ya hali ya juu zaidi muhimu katika FPS pekee ni fidia ya kuchelewa. Wakati wa kutumia fidia ya lag, seva inazingatia ucheleweshaji wa mteja wakati inapiga kwenye lengo. Kwa mfano, ikiwa mchezaji alipiga picha ya kichwa kwenye skrini yake, lakini kwa kweli lengo lake lilikuwa katika eneo tofauti kutokana na kuchelewa, basi itakuwa si haki kumnyima mchezaji haki ya kuua kwa kuchelewa. Kwa hivyo, seva hurejesha muda nyuma hadi wakati mchezaji alipiga risasi ili kuiga kile mchezaji aliona kwenye skrini yake na kuangalia kama kuna mgongano kati ya risasi yake na lengo.

Glenn Fiedler (kama kawaida!) aliandika nakala mnamo 2004 Fizikia ya Mtandao (2004), ambamo aliweka msingi wa kulandanisha simulizi za fizikia kati ya seva na mteja. Mnamo 2014 aliandika safu mpya ya nakala Fizikia ya Mtandao, ambayo ilielezea mbinu zingine za kusawazisha masimulizi ya fizikia.

Pia kuna nakala mbili kwenye wiki ya Valve, Chanzo cha Mtandao wa Wachezaji Wengi ΠΈ Mbinu za Kufidia Muda wa Kuchelewa katika Usanifu na Uboreshaji wa Itifaki ya Mteja/Seva Ndani ya mchezo ambayo inazingatia fidia kwa ucheleweshaji.

Kuzuia kudanganya

Kuna mbinu mbili kuu za kuzuia kudanganya.

Kwanza: kufanya iwe vigumu zaidi kwa walaghai kutuma pakiti hasidi. Kama ilivyoelezwa hapo juu, njia nzuri ya kutekeleza hii ni usimbaji fiche.

Pili: seva ya kimabavu inapaswa kupokea tu amri/ingizo/vitendo. Mteja hapaswi kuwa na uwezo wa kubadilisha hali kwenye seva isipokuwa kwa kutuma ingizo. Kisha, kila wakati seva inapokea pembejeo, lazima iangalie ikiwa ni halali kabla ya kuitumia.

Mantiki ya maombi: hitimisho

Ninapendekeza utekeleze njia ya kuiga muda wa juu wa kusubiri na viwango vya chini vya kuonyesha upya ili uweze kujaribu tabia ya mchezo wako katika hali mbaya, hata wakati mteja na seva zinafanya kazi kwenye kompyuta moja. Hii itarahisisha sana utekelezaji wa mbinu za kuchelewesha laini.

Rasilimali Zingine Muhimu

Ikiwa ungependa kuchunguza nyenzo zingine kwenye miundo ya mtandao, unaweza kuzipata hapa:

Chanzo: mapenzi.com

Kuongeza maoni