{"id":37812,"date":"2019-10-31T22:19:55","date_gmt":"2019-10-31T19:19:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/megapaket-kak-razrabotchikam-factorio-udalos-reshit-problemu-s-multipleerom-na-200-igrokov\/"},"modified":"2019-10-31T22:19:55","modified_gmt":"2019-10-31T19:19:55","slug":"megapaket-kak-razrabotchikam-factorio-udalos-reshit-problemu-s-multipleerom-na-200-igrokov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/megapaket-kak-razrabotchikam-factorio-udalos-reshit-problemu-s-multipleerom-na-200-igrokov","title":{"rendered":"Megapak: kako su programeri Factorio uspjeli rije\u0161iti problem s multiplayerom za 200 igra\u010da","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Megapak:
\nU svibnju ove godine sudjelovao sam kao igra\u010d na MMO doga\u0111aju KatherineOfSky<\/a><\/noindex>. Primijetio sam da kada broj igra\u010da dostigne odre\u0111eni broj, svake nekoliko minuta dio njih se 'ispu\u0161ta'. Na sre\u0107u za vas (ali ne i za mene), bio sam jedan od onih igra\u010da koji su se isklju\u010divali svaki put<\/b>, \u010dak i uz dobru vezu. Uzeo sam to kao osobni izazov i po\u010deo istra\u017eivati razloge problema. Nakon tri tjedna debagiranja, testiranja i ispravki, gre\u0161ka je nap finally ispravljena, ali to putovanje nije bilo tako jednostavno.<\/p>\n

Problemi multiplayer igara vrlo su te\u0161ki za pra\u0107enje. Obi\u010dno se javljaju u vrlo specifi\u010dnim uvjetima mre\u017enih postavki i u vrlo specifi\u010dnim stanjima igre (u ovom slu\u010daju - u prisutnosti vi\u0161e od 200 igra\u010da). \u010cak i kada se uspije reproducirati problem, nije ga mogu\u0107e pravilno debagirati, jer umetanje kontrolnih to\u010daka zaustavlja igru, zbunjuje tajmere i obi\u010dno dovodi do prekida veze zbog isteka vremena \u010dekanja. No, zahvaljuju\u0107i upornosti i izvrsnom alatu zvanom clumsy<\/a><\/noindex> , uspio sam saznati \u0161to se doga\u0111a.<\/p>\n

Ukratko: zbog gre\u0161ke i nepotpune implementacije simulacije stanja ka\u0161njenja, klijent se ponekad na\u0161ao u situaciji kada je morao u jednom ciklusu poslati mre\u017eni paket koji se sastoji od akcija igra\u010da koje odabire pribli\u017eno 400 gaming entiteta (nazivamo ga 'megapak'). Nakon toga, server ne samo da mora pravilno primiti sve te ulazne akcije, nego ih i poslati svim ostalim klijentima. Ako imate 200 klijenata, to brzo postaje problem. Kanal prema serveru brzo se zagu\u0161i, \u0161to dovodi do gubitka paketa i kaskade ponovo zatra\u017eenih paketa. Odga\u0111anje ulaznih akcija tada dovodi do jo\u0161 vi\u0161e klijenata koji po\u010dinju slati megapakete, a njihova lavina postaje sve ja\u010da. Sretnim klijentima uspijeva se oporaviti, svi ostali se 'ispu\u0161taju'.
\n<\/a><\/noindex>
\n\"Megapak:
\nProblem je bio dovoljno temeljit i trebalo mi je 2 tjedna da ga ispravim. Tehni\u010dka je priroda, pa \u0107u u nastavku objasniti so\u010dne tehni\u010dke detalje. No, prvo morate znati da je od verzije 0.17.54, objavljene 4. lipnja, multijezgarni na\u010din rada postao stabilniji, a skrivanje latencije znatno manje glitzy (manje usporavanja i teleportacija). Osim toga, promijenio sam na\u010din skrivanja latencije u borbi i nadam se da \u0107e zbog toga biti malo fluidnija.<\/p>\n

Multiplayer megapak - tehni\u010dki detalji<\/h3>\n

\nAko pojednostavim, multiplayer u igri radi na sljede\u0107i na\u010din: svi klijenti simuliraju stanje igre, primaju\u0107i i \u0161alju\u0107i samo unos igra\u010da (koji se naziva \"unosi akcije\", Input Actions<\/i>). Glavni zadatak servera je preno\u0161enje Input Actions<\/i> i kontrola toga da svi klijenti izvode iste akcije u jednom ciklusu. Vi\u0161e o tome mo\u017eete pro\u010ditati u postu FFF-149<\/a><\/noindex>.<\/p>\n

Budu\u0107i da server mora donositi odluke o tome koje akcije treba izvr\u0161iti, putanja koju akcija igra\u010da prelazi je otprilike ovakva: akcija igra\u010da -> klijent igre -> mre\u017ea -> server -> mre\u017ea -> klijent igre. To zna\u010di da se svaka akcija igra\u010da izvr\u0161ava tek nakon \u0161to napravi put prema naprijed i natrag kroz mre\u017eu. Zbog toga bi igra izgledala stra\u0161no usporeno, pa je gotovo odmah nakon pojave multijezgarni sustav uveden mehanizam za skrivanje latencije. Skrivenje latencije imituje unos igra\u010da bez uzimanja u obzir akcija drugih igra\u010da i dono\u0161enja odluka od strane servera.<\/p>\n

\"Megapak:
\nU Factorio postoji stanje igre Game State<\/i> \u2014 to je potpuno stanje mape, igra\u010da, entiteta i svega ostalog. Odre\u0111eno je deterministi\u010dki simulirano u svim klijentima na temelju akcija dobivenih od servera. Stanje igre je sveto i ako ikada po\u010dne odstupati od servera ili bilo kojeg drugog klijenta, nastaje nesinkronizacija.<\/p>\n

Osim Game State<\/i> imamo stanje latencije Latency State<\/i>. Sadr\u017ei mali podskup osnovnog stanja. Latency State<\/i> nije sveto i jednostavno predstavlja sliku o tome kako \u0107e izgledati stanje igre u budu\u0107nosti na temelju unosa igra\u010da Input Actions<\/i>.<\/p>\n

Za to \u010duvamo kopiju kreiranih Input Actions<\/i> u redu za latenciju.<\/p>\n

\"Megapak:
\nNa kraju procesa klijentova slika izgleda otprilike ovako:<\/p>\n

    \n
  1. Primjenjujemo Input Actions<\/i> sve akcije na Game State<\/i> onako kako su te ulazne radnje primljene sa servera.<\/li>\n
  2. Uklanjamo iz reda ka\u0161njenja sve Input Actions<\/i>, koje su, prema podacima sa servera, ve\u0107 primijenjene na Game State<\/i>.<\/li>\n
  3. Bri\u0161emo Latency State<\/i> i resetiramo ga kako bi izgledalo upravo onako kako i Game State<\/i>.<\/li>\n
  4. Primjenjujemo sve akcije iz reda ka\u0161njenja na Latency State<\/i>.<\/li>\n
  5. Na temelju podataka Game State<\/i> i Latency State<\/i> renderiramo igru igra\u010du.<\/li>\n<\/ol>\n

    \nSve se to ponavlja u svakom taktu.<\/p>\n

    Prekomplicirano? Ne opu\u0161tajte se, to jo\u0161 nije sve. Kako bismo nadoknadili nepouzdanost internetskih veza, stvorili smo dva mehanizma:<\/p>\n