ProHoster > Blogs > Administrācija > Par tīkla modeli spēlēs iesācējiem

Par tīkla modeli spēlēs iesācējiem

Par tīkla modeli spēlēs iesācējiem
Pēdējās divas nedēļas esmu strādājis pie savas spēles tieÅ”saistes dzinēja. Pirms tam es vispār neko nezināju par tÄ«klu veidoÅ”anu spēlēs, tāpēc lasÄ«ju daudz rakstu un veicu daudz eksperimentu, lai saprastu visus jēdzienus un varētu uzrakstÄ«t savu tÄ«kla dzinēju.

Šajā rokasgrāmatā es vēlos dalīties ar jums dažādos jēdzienos, kas jums jāapgūst, pirms rakstāt savu spēles programmu, kā arī par labākajiem resursiem un rakstiem, lai tos apgūtu.

Kopumā ir divi galvenie tīkla arhitektūras veidi: vienādranga un klienta-servera. Vienādranga (p2p) arhitektūrā dati tiek pārsūtīti starp jebkuriem savienotu atskaņotāju pāriem, savukārt klienta-servera arhitektūrā dati tiek pārsūtīti tikai starp atskaņotājiem un serveri.

Lai gan dažās spēlēs joprojām tiek izmantota peer-to-peer arhitektÅ«ra, klients-serveris ir standarts: to ir vieglāk ieviest, nepiecieÅ”ams mazāks kanāla platums un atvieglo aizsardzÄ«bu pret krāpÅ”anos. Tāpēc Å”ajā apmācÄ«bā mēs koncentrēsimies uz klienta-servera arhitektÅ«ru.

Jo Ä«paÅ”i mÅ«s visvairāk interesē autoritārie serveri: Ŕādās sistēmās serverim vienmēr ir taisnÄ«ba. Piemēram, ja spēlētājs uzskata, ka atrodas koordinātēs (10, 5), un serveris viņam saka, ka viņŔ atrodas uz (5, 3), klientam ir jāaizstāj sava pozÄ«cija ar servera ziņoto, nevis vietni. otrādi. Izmantojot autoritatÄ«vus serverus, ir vieglāk identificēt krāpniekus.

Tīkla spēļu sistēmām ir trīs galvenie komponenti:

  • Transporta protokols: kā dati tiek pārsÅ«tÄ«ti starp klientiem un serveri.
  • Lietojumprogrammas protokols: kas un kādā formātā tiek pārraidÄ«ts no klientiem uz serveri un no servera uz klientiem.
  • Lietojumprogrammu loÄ£ika: kā pārsÅ«tÄ«tie dati tiek izmantoti, lai atjauninātu klientu un servera stāvokli.

Ir ļoti svarīgi saprast katras daļas lomu un ar tām saistītos izaicinājumus.

Transporta protokols

Pirmais solis ir izvēlēties protokolu datu pārsÅ«tÄ«Å”anai starp serveri un klientiem. Å im nolÅ«kam ir divi interneta protokoli: TCP Šø UDP. Bet jÅ«s varat izveidot savu transporta protokolu, pamatojoties uz kādu no tiem, vai izmantot bibliotēku, kas tos izmanto.

TCP un UDP salīdzinājums

Gan TCP, gan UDP ir balstÄ«ti uz IP. IP ļauj pārsÅ«tÄ«t paketi no avota adresātam, bet negarantē, ka nosÅ«tÄ«tā pakete agrāk vai vēlāk sasniegs adresātu, ka tā sasniegs to vismaz vienu reizi un ka pakeÅ”u secÄ«ba nonāks pareizajā pasÅ«tÄ«jums. Turklāt paketē var bÅ«t tikai ierobežots datu apjoms, ko nosaka vērtÄ«ba MTU.

UDP ir tikai plāns slānis virs IP. Tāpēc tam ir tādi paÅ”i ierobežojumi. Turpretim TCP ir daudz funkciju. Tas nodroÅ”ina uzticamu, sakārtotu savienojumu starp diviem mezgliem ar kļūdu pārbaudi. LÄ«dz ar to TCP ir ļoti ērts un tiek izmantots daudzos citos protokolos, piem. HTTP, ftp Šø SMTP. Bet visām Ŕīm funkcijām ir cena: kavÄ“Å”anās.

Lai saprastu, kāpēc Ŕīs funkcijas var izraisÄ«t latentumu, mums ir jāsaprot, kā darbojas TCP. Kad sÅ«tÄ«Å”anas mezgls pārsÅ«ta paketi saņēmējam mezglam, tas sagaida, ka saņems apstiprinājumu (ACK). Ja pēc noteikta laika tas to nesaņem (jo pakete vai apstiprinājums ir pazaudēts, vai kāda cita iemesla dēļ), tad tas nosÅ«ta paketi atkārtoti. Turklāt TCP garantē, ka paketes tiek saņemtas pareizā secÄ«bā, tāpēc, kamēr nav saņemta pazaudētā pakete, visas pārējās paketes nevar apstrādāt, pat ja tās jau ir saņēmis saņēmējs resursdators.

Bet, kā jÅ«s droÅ”i vien varat iedomāties, latentums vairāku spēlētāju spēlēs ir ļoti svarÄ«gs, jo Ä«paÅ”i tādos žanros kā FPS. Tāpēc daudzas spēles izmanto UDP ar savu protokolu.

Vietējais UDP protokols dažādu iemeslu dēļ var bÅ«t efektÄ«vāks par TCP. Piemēram, tas var atzÄ«mēt dažas paketes kā uzticamas un citas kā neuzticamas. Tāpēc tam ir vienalga, vai neuzticamā pakete sasniedz adresātu. Vai arÄ« tā var apstrādāt vairākas datu straumes, lai pazaudēta pakete vienā straumē nepalēninātu atlikuŔās straumes. Piemēram, var bÅ«t pavediens atskaņotāja ievadei un cits pavediens tērzÄ“Å”anas ziņojumiem. Ja tiek pazaudēts tērzÄ“Å”anas ziņojums, kas nav steidzams, tas nepalēninās ievadi, kas ir steidzama. Vai arÄ« patentēts protokols var ieviest uzticamÄ«bu citādi nekā TCP, lai tas bÅ«tu efektÄ«vāks videospēļu vidē.

Tātad, ja TCP tik ļoti iesÅ«cas, tad mēs izveidosim paÅ”i savu transporta protokolu, pamatojoties uz UDP?

Tas ir nedaudz sarežģītāk. Lai gan TCP ir gandrÄ«z neoptimāls spēļu tÄ«kla sistēmām, tas var diezgan labi darboties jÅ«su konkrētajā spēlē un ietaupÄ«t dārgo laiku. Piemēram, latentums var nebÅ«t problēma uz gājieniem balstÄ«tai spēlei vai spēlei, ko var spēlēt tikai LAN tÄ«klos, kur latentums un pakeÅ”u zudumi ir daudz mazāki nekā internetā.

Daudzas veiksmīgas spēles, tostarp World of Warcraft, Minecraft un Terraria, izmanto TCP. Tomēr lielākā daļa FPS izmanto savus protokolus, kuru pamatā ir UDP, tāpēc tālāk par tiem runāsim vairāk.

Ja nolemjat izmantot TCP, pārliecinieties, vai tas ir atspējots Nagles algoritms, jo tas buferē paketes pirms nosÅ«tÄ«Å”anas, kas nozÄ«mē, ka tas palielina latentumu.

Lai uzzinātu vairāk par atŔķirÄ«bām starp UDP un TCP vairāku spēlētāju spēļu kontekstā, varat izlasÄ«t Glena FÄ«dlera rakstu UDP vs. TCP.

Savs protokols

Tātad vēlaties izveidot savu transporta protokolu, bet nezināt, ar ko sākt? Jums ir paveicies, jo Glens FÄ«dlers par to ir uzrakstÄ«jis divus pārsteidzoÅ”us rakstus. Tajās atradÄ«si daudz gudru domu.

Pirmais raksts TÄ«kloÅ”ana spēļu programmētājiem 2008. gads, vieglāks par otro, Spēļu tÄ«kla protokola izveide 2016. gads. Iesaku sākt ar vecāko.

Ņemiet vērā, ka Glens FÄ«dlers ir liels pielāgota protokola, kura pamatā ir UDP, izmantoÅ”anas atbalstÄ«tājs. Un pēc viņa rakstu izlasÄ«Å”anas jÅ«s, iespējams, pieņemsit viņa viedokli, ka TCP ir nopietni trÅ«kumi videospēlēs, un jÅ«s vēlaties ieviest savu protokolu.

Bet, ja esat iesācējs tÄ«klu veidoÅ”anā, izdariet sev labu un izmantojiet TCP vai bibliotēku. Lai veiksmÄ«gi ieviestu savu transporta protokolu, jums ir daudz jāapgÅ«st iepriekÅ”.

Tīkla bibliotēkas

Ja jums ir nepiecieÅ”ams kaut kas efektÄ«vāks par TCP, bet nevēlaties iet cauri sava protokola ievieÅ”anai un daudzām detaļām, varat izmantot tÄ«kla bibliotēku. To ir daudz:

  • yojimbo Glens FÄ«dlers
  • RakNet, kas vairs netiek atbalstÄ«ts, bet dakÅ”a no tā SLikeNet Å Ä·iet, ka tas joprojām ir aktÄ«vs.
  • ENet ir bibliotēka, kas izveidota vairāku spēlētāju FPS Kubs
  • GameNetworkingSockets Vārsts

Es neesmu izmēģinājis tos visus, bet es dodu priekÅ”roku ENet, jo tas ir viegli lietojams un uzticams. Turklāt tajā ir skaidra dokumentācija un apmācÄ«ba iesācējiem.

Transporta protokols: Secinājums

Rezumējot: ir divi galvenie transporta protokoli: TCP un UDP. TCP ir daudz noderÄ«gu funkciju: uzticamÄ«ba, pakeÅ”u pasÅ«tÄ«jumu saglabāŔana, kļūdu noteikÅ”ana. UDP tā visa nav, bet TCP pēc savas bÅ«tÄ«bas ir palielinājis latentumu, kas dažām spēlēm ir nepieņemami. Tas ir, lai nodroÅ”inātu zemu latentumu, varat izveidot savu protokolu, pamatojoties uz UDP, vai izmantot bibliotēku, kas ievieÅ” UDP transporta protokolu un ir pielāgota vairāku spēlētāju videospēlēm.

Izvēle starp TCP, UDP un bibliotēku ir atkarÄ«ga no vairākiem faktoriem. Pirmkārt, no spēles vajadzÄ«bām: vai tai ir nepiecieÅ”ams zems latentums? Otrkārt, no lietojumprogrammas protokola prasÄ«bām: vai tam ir nepiecieÅ”ams uzticams protokols? Kā redzēsim nākamajā daļā, ir iespējams izveidot lietojumprogrammas protokolu, kuram diezgan piemērots ir neuzticams protokols. Visbeidzot, jāņem vērā arÄ« tÄ«kla dzinēja izstrādātāja pieredze.

Man ir divi padomi:

  • Cik vien iespējams, noņemiet transporta protokolu no pārējās lietojumprogrammas, lai to varētu viegli nomainÄ«t, nepārrakstot visu kodu.
  • NepārmērÄ«gi optimizējiet. Ja neesat tÄ«klu eksperts un neesat pārliecināts, vai jums ir nepiecieÅ”ams pielāgots uz UDP balstÄ«ts transporta protokols, varat sākt ar TCP vai bibliotēku, kas nodroÅ”ina uzticamÄ«bu, un pēc tam pārbaudÄ«t un novērtēt veiktspēju. Ja rodas problēmas un esat pārliecināts, ka iemesls ir transporta protokols, iespējams, ir pienācis laiks izveidot savu transporta protokolu.

Å Ä«s daļas beigās iesaku izlasÄ«t Ievads vairāku spēlētāju spēļu programmÄ“Å”anā Braiens Huks, kas aptver daudzas no Å”eit apspriestajām tēmām.

Lietojumprogrammas protokols

Tagad, kad mēs varam apmainīties ar datiem starp klientiem un serveri, mums ir jāizlemj, kādus datus pārsūtīt un kādā formātā.

Klasiskā shēma ir tāda, ka klienti nosÅ«ta ievadi vai darbÄ«bas uz serveri, un serveris nosÅ«ta klientiem paÅ”reizējo spēles stāvokli.

Serveris nosÅ«ta nevis pilnu stāvokli, bet gan filtrētu stāvokli ar entÄ«tijām, kas atrodas atskaņotāja tuvumā. ViņŔ to dara trÄ«s iemeslu dēļ. Pirmkārt, pilnais stāvoklis var bÅ«t pārāk liels, lai to pārraidÄ«tu augstā frekvencē. Otrkārt, klientus galvenokārt interesē vizuālie un audio dati, jo lielākā daļa spēles loÄ£ikas tiek simulēta spēles serverÄ«. TreÅ”kārt, dažās spēlēs spēlētājam nav jāzina noteikti dati, piemēram, ienaidnieka atraÅ”anās vieta kartes otrā pusē, pretējā gadÄ«jumā viņŔ var Ŕņaukt paciņas un precÄ«zi zināt, kur pārvietoties, lai viņu nogalinātu.

Serializācija

Pirmais solis ir konvertēt datus, ko vēlamies nosÅ«tÄ«t (ievades vai spēles stāvokli), pārsÅ«tÄ«Å”anai piemērotā formātā. Å o procesu sauc serializācija.

Doma, kas uzreiz nāk prātā, ir izmantot cilvēkam lasāmu formātu, piemēram, JSON vai XML. Bet tas būs pilnīgi neefektīvs un izniekos lielāko daļu kanāla.

Tā vietā ieteicams izmantot bināro formātu, kas ir daudz kompaktāks. Tas nozÄ«mē, ka paketēs bÅ«s tikai daži baiti. Å eit ir jāņem vērā problēma baitu secÄ«ba, kas dažādos datoros var atŔķirties.

Lai serializētu datus, varat izmantot bibliotēku, piemēram:

VienkārÅ”i pārliecinieties, ka bibliotēka veido pārnēsājamus arhÄ«vus un rÅ«pējas par to, lai tā bÅ«tu pabeigta.

AlternatÄ«vs risinājums ir to ieviest paÅ”am; tas nav Ä«paÅ”i sarežģīti, it Ä«paÅ”i, ja kodam izmantojat uz datiem orientētu pieeju. Turklāt tas ļaus veikt optimizācijas, kas ne vienmēr ir iespējamas, izmantojot bibliotēku.

Glens FÄ«dlers uzrakstÄ«ja divus rakstus par serializāciju: LasÄ«Å”anas un rakstÄ«Å”anas paketes Šø Serializācijas stratēģijas.

saspieŔana

Starp klientiem un serveri pārsÅ«tÄ«to datu apjomu ierobežo kanāla joslas platums. Datu saspieÅ”ana ļaus pārsÅ«tÄ«t vairāk datu katrā momentuzņēmumā, palielināt atjaunināŔanas biežumu vai vienkārÅ”i samazināt kanāla prasÄ«bas.

Bitu iepakojums

Pirmā tehnika ir bitu iepakoÅ”ana. Tas sastāv no tieÅ”i tāda bitu skaita izmantoÅ”anas, kāds nepiecieÅ”ams, lai aprakstÄ«tu vēlamo vērtÄ«bu. Piemēram, ja jums ir enum, kurā var bÅ«t 16 dažādas vērtÄ«bas, tad vesela baita (8 bitu) vietā varat izmantot tikai 4 bitus.

Glens Fīdlers raksta otrajā daļā paskaidro, kā to īstenot LasīŔanas un rakstīŔanas paketes.

Bitu iepakoÅ”ana Ä«paÅ”i labi darbojas ar paraugu ņemÅ”anu, kas bÅ«s nākamās sadaļas tēma.

Paraugu ņemÅ”ana

Paraugu ņemÅ”ana ir zudumu saspieÅ”anas paņēmiens, kas vērtÄ«bas kodÄ“Å”anai izmanto tikai iespējamo vērtÄ«bu apakÅ”kopu. VienkārŔākais veids, kā ieviest diskretizāciju, ir peldoŔā komata skaitļu noapaļoÅ”ana.

Glens FÄ«dlers (atkal!) savā rakstā parāda, kā paraugu ņemÅ”anu Ä«stenot praksē Momentuzņēmuma saspieÅ”ana.

Kompresijas algoritmi

Nākamais paņēmiens bÅ«s bezzudumu saspieÅ”anas algoritmi.

Šeit, manuprāt, ir trīs interesantākie algoritmi, kas jums jāzina:

  • Hafmena kodÄ“Å”ana ar iepriekÅ” aprēķinātu kodu, kas ir ārkārtÄ«gi ātrs un var dot labus rezultātus. To izmantoja pakeÅ”u saspieÅ”anai Quake3 tÄ«kla dzinējā.
  • zlib ir vispārējas nozÄ«mes saspieÅ”anas algoritms, kas nekad nepalielina datu apjomu. Kā var redzēt Å”eit, tas ir izmantots dažādās lietojumprogrammās. Tas var bÅ«t lieks statusu atjaunināŔanai. Bet tas var bÅ«t noderÄ«gi, ja klientiem no servera ir jānosÅ«ta lÄ«dzekļi, gari teksti vai reljefs.
  • Notiek darbÄ«bas garumu kopÄ“Å”ana - Å is, iespējams, ir vienkārŔākais saspieÅ”anas algoritms, taču tas ir ļoti efektÄ«vs noteiktiem datu veidiem, un to var izmantot kā pirmapstrādes darbÄ«bu pirms zlib. Tas ir Ä«paÅ”i piemērots, lai saspiestu reljefu, kas sastāv no flÄ«zēm vai vokseļiem, kuros atkārtojas daudzi blakus esoÅ”ie elementi.

Delta kompresija

Pēdējā saspieÅ”anas metode ir delta kompresija. Tas sastāv no tā, ka tiek pārraidÄ«tas tikai atŔķirÄ«bas starp paÅ”reizējo spēles stāvokli un pēdējo klienta saņemto stāvokli.

To pirmo reizi izmantoja Quake3 tīkla dzinējā. Šeit ir divi raksti, kas izskaidro, kā to izmantot:

Glens FÄ«dlers to izmantoja arÄ« sava raksta otrajā daļā Momentuzņēmuma saspieÅ”ana.

ŠifrēŔana

Turklāt jums var bÅ«t nepiecieÅ”ams Å”ifrēt informācijas pārsÅ«tÄ«Å”anu starp klientiem un serveri. Tam ir vairāki iemesli:

  • privātums/konfidencialitāte: ziņojumus var lasÄ«t tikai adresāts, un neviena cita persona, kas smeļas tÄ«klā, nevarēs tos izlasÄ«t.
  • autentifikācija: personai, kura vēlas spēlēt spēlētāja lomu, ir jāzina viņa atslēga.
  • KrāpÅ”anās novērÅ”ana: Ä»aunprātÄ«gajiem spēlētājiem bÅ«s daudz grÅ«tāk izveidot savas krāpÅ”anās pakotnes, viņiem bÅ«s jāreproducē Å”ifrÄ“Å”anas shēma un jāatrod atslēga (kas mainās ar katru savienojumu).

Es ļoti iesaku Å”im nolÅ«kam izmantot bibliotēku. Iesaku lietot libnātrijs, jo tas ir Ä«paÅ”i vienkārÅ”s un tajā ir lieliskas apmācÄ«bas. ÄŖpaÅ”i interesanta ir apmācÄ«ba par atslēgu apmaiņa, kas ļauj Ä£enerēt jaunas atslēgas ar katru jaunu savienojumu.

PieteikŔanās protokols: Secinājums

Tas noslēdz mÅ«su lietojumprogrammas protokolu. Es uzskatu, ka saspieÅ”ana ir pilnÄ«gi neobligāta, un lēmums par tās izmantoÅ”anu ir atkarÄ«gs tikai no spēles un nepiecieÅ”amā joslas platuma. Å ifrÄ“Å”ana, manuprāt, ir obligāta, bet pirmajā prototipā var iztikt bez tās.

Lietojumprogrammas loģika

Tagad mēs varam atjaunināt klienta statusu, taču var rasties latentuma problēmas. Spēlētājam pēc ievades pabeigÅ”anas jāgaida spēles stāvokļa atjaunināŔana no servera, lai redzētu, kāda ir tā ietekme uz pasauli.

Turklāt starp diviem stāvokļa atjauninājumiem pasaule ir pilnīgi statiska. Ja stāvokļa atjaunināŔanas ātrums ir zems, kustības būs ļoti saraustītas.

Å Ä«s problēmas ietekmes mazināŔanai ir vairāki paņēmieni, un es tos apskatÄ«Å”u nākamajā sadaļā.

Latenta izlīdzināŔanas metodes

Visas Å”ajā sadaļā aprakstÄ«tās metodes ir detalizēti aplÅ«kotas sērijā Ātrgaitas vairāku spēlētāju spēle Gabriels Gambeta. Es ļoti iesaku izlasÄ«t Å”o lielisko rakstu sēriju. Tas ietver arÄ« interaktÄ«vu demonstrāciju, kas ļauj redzēt, kā Ŕīs metodes darbojas praksē.

Pirmais paņēmiens ir ievadÄ«t ievades rezultātu tieÅ”i, negaidot atbildi no servera. Tas tiek saukts klienta puses prognozÄ“Å”ana. Tomēr, kad klients saņem atjauninājumu no servera, tam ir jāpārbauda, ā€‹ā€‹vai tā prognoze bija pareiza. Ja tas tā nav, tad viņam vienkārÅ”i jāmaina stāvoklis atbilstoÅ”i tam, ko viņŔ saņēma no servera, jo serveris ir autoritārs. Å o paņēmienu pirmo reizi izmantoja Quake. Vairāk par to varat lasÄ«t rakstā Quake Engine koda apskats Fabiens Sanglārs [tulkojums par Habrē].

Otrā metožu kopa tiek izmantota, lai izlÄ«dzinātu citu entÄ«tiju kustÄ«bu starp diviem stāvokļa atjauninājumiem. Ir divi veidi, kā atrisināt Å”o problēmu: interpolācija un ekstrapolācija. Interpolācijas gadÄ«jumā tiek ņemti pēdējie divi stāvokļi un parādÄ«ta pāreja no viena uz otru. Tā trÅ«kums ir tāds, ka tas rada nelielu kavÄ“Å”anos, jo klients vienmēr redz, kas noticis pagātnē. Ekstrapolācijas mērÄ·is ir paredzēt, kur entÄ«tijām tagad vajadzētu bÅ«t, pamatojoties uz pēdējo klienta saņemto stāvokli. Tās trÅ«kums ir tāds, ka, ja entÄ«tija pilnÄ«bā maina kustÄ«bas virzienu, tad starp prognozi un faktisko pozÄ«ciju bÅ«s liela kļūda.

Jaunākā, vismodernākā tehnika, kas ir noderÄ«ga tikai FPS kavējuma kompensācija. Izmantojot kavējuma kompensāciju, serveris ņem vērā klienta kavÄ“Å”anos, kad tas Å”auj mērÄ·Ä«. Piemēram, ja spēlētājs izpildÄ«ja Ŕāvienu ar galvu uz sava ekrāna, bet patiesÄ«bā viņa mērÄ·is kavÄ“Å”anās dēļ atradās citā vietā, tad bÅ«tu negodÄ«gi liegt spēlētājam tiesÄ«bas nogalināt aizkavÄ“Å”anās dēļ. Tāpēc serveris attina laiku atpakaļ lÄ«dz brÄ«dim, kad spēlētājs izŔāva, lai simulētu to, ko spēlētājs redzēja savā ekrānā, un pārbaudÄ«tu, vai nav sadursmes starp Ŕāvienu un mērÄ·i.

Glens FÄ«dlers (kā vienmēr!) rakstÄ«ja rakstu 2004. gadā TÄ«kla fizika (2004), kurā viņŔ lika pamatus fizikas simulāciju sinhronizÄ“Å”anai starp serveri un klientu. 2014. gadā viņŔ uzrakstÄ«ja jaunu rakstu sēriju TÄ«kla fizika, kurā aprakstÄ«ti citi paņēmieni fizikas simulāciju sinhronizÄ“Å”anai.

Valve wiki ir arÄ« divi raksti, Avots Multiplayer Networking Šø Latenta kompensācijas metodes klienta/servera spēļu protokola izstrādē un optimizācijā kas paredz kompensāciju par kavējumiem.

KrāpÅ”anas novērÅ”ana

Ir divi galvenie krāpÅ”anas novērÅ”anas paņēmieni.

Pirmkārt: apgrÅ«tināt krāpniekiem ļaunprātÄ«gu pakeÅ”u nosÅ«tÄ«Å”anu. Kā minēts iepriekÅ”, labs veids, kā to Ä«stenot, ir Å”ifrÄ“Å”ana.

Otrkārt: autoritāram serverim vajadzētu saņemt tikai komandas/ievadi/darbÄ«bas. Klientam nevajadzētu bÅ«t iespējai mainÄ«t servera stāvokli, izņemot, nosÅ«tot ievadi. Pēc tam katru reizi, kad serveris saņem ievadi, tam pirms lietoÅ”anas jāpārbauda, ā€‹ā€‹vai tā ir derÄ«ga.

Pielietojuma loģika: secinājums

Iesaku ieviest veidu, kā simulēt lielu latentumu un zemu atsvaidzes intensitāti, lai varētu pārbaudÄ«t spēles darbÄ«bu sliktos apstākļos, pat ja klients un serveris darbojas vienā datorā. Tas ievērojami vienkārÅ”os kavÄ“Å”anās izlÄ«dzināŔanas paņēmienu ievieÅ”anu.

Citi noderīgi resursi

Ja vēlaties izpētÄ«t citus tÄ«kla modeļu resursus, varat tos atrast Å”eit:

Avots: www.habr.com

Pievieno komentāru