'To je preprosto nemogoče': Razvijalci pojasnjujejo, zakaj se zdi, da se velike spletne igre vedno zlomijo ob zagonu

Med razdrobljenim lansiranjem himna , presenetljivo lansiranje Apex Legends in prihajajoče izdaje Oddelek 2 , začetek leta 2019 je poln velikih spletnih iger. Kot je pokazala najnovejša BioWarejeva in nešteto iger pred tem, se igre za več igralcev tega obsega le redko zaženejo v briljantnem stanju. Zdi se, da ima vsaka spletna igra nekaj tehnične težave ob zagonu, ne glede na to, ali so manjše, kot so napake prvega tedna v Apex Legends, ali kršitve iger, kot so težave s povezavo, ki so sprva pokvarile Hudič 3 .

Odkar imamo spletne igre, smo imeli težave pri zagonih, vendar se zdi, da pogovor o težavah z zagonom v resnici ni šel nikamor. Vsakič vidimo, da se pojavljajo ista vprašanja. Zakaj se je to zgodilo? Zakaj razvijalci tega niso predvideli? Zakaj je popravilo trajalo tako dolgo? Ker je toliko velikih spletnih iger, ki so bile izdane tako blizu skupaj, se je z vzponom iger kot storitve v panogi zdaj zdelo pravi čas, da se nekatera od teh vprašanj obrnemo na razvijalce v upanju, da bomo demistificirali grozljive izpade na dan lansiranja. Zakaj se ob zagonu iger pojavljajo enake težave in kako jih razvijalci obravnavajo?

'Zmogljivost je zelo redko težava'

Kadar koli igre ne delujejo ali se povezujejo počasi, mnogi domnevajo, da je to zato, ker jim je zmanjkalo prostora v strežniku. Da so razvijalci podcenili, koliko igralcev se bo prijavilo, in posledično so se njihovi strežniki zvijali pod obremenitvijo. V tem primeru je vse, kar morajo storiti, plačati za več strežnikov, kajne? No, ne, ni nujno; kot se pogosto zgodi pri ustvarjanju iger, ni tako preprosto.

»Ena od miselnosti, ki jo pogosto vidite na spletu, je: »Zakaj podjetje A nima več strežnikov?« nam pove Alex Mann, vodja razvoja in nekdanji analitik QA pri EA. »Ob zagonu vidite največjo količino prometa na teh igrah. Vsi so bili navdušeni, marketinška ekipa je dobro opravila svoje delo, vsi so zelo navdušeni nad povezavo do spleta in v trenutku, ko se igra pojavi, vsi kliknejo »Pojdi«. Toda v življenjskem ciklu večine iger boste opazili, da imate ta velik izbruh in nato izgine. Če bi vsako podjetje za igre kupilo strojno opremo, da bi pokrilo vse, kar so potrebovali v tem začetnem nizu, bi dva tedna pozneje imeli 50 % svoje strojne opreme, ki bi bila tam nikoli uporabljena.«

'Ne gre za 'vrzimo na to veliko denarja in ga povečajmo.'

Alex Mann

To razvijalcem otežuje pripravo na zagon brez prevelike porabe in nakupov preveč strežniki. Na srečo imajo razvijalci zdaj dostop do virtualnih strežnikov prek podjetij, kot je Amazon Web Services, in jih je mogoče po potrebi aktivirati ali deaktivirati. Te vrste strežnikov so postale nujne tudi, ko so se igre premaknile stran od povezav enakovrednih – vrste, ki je leta 2004 podpirala igre, kot je Halo 2 – na namenske strežnike, ki podpirajo množične, vztrajne igre, kot je Usoda 2 in himna. Vendar virtualni strežniki niso čudežno zdravilo in imajo svoje težave.

'Zmogljivost ni nujno odvisna od števila strežnikov,' pravi Mann. »Tudi če pričakujemo milijone igralcev in imamo strežnike, ne pričakujemo, da bodo vsi hkrati zagnali ta portal za prijavo. Gre za to, da bi imeli na avtocesti dovolj pasov, da bi lahko ljudje prišli skozi. Imate dve državi, povezani preko mostu, in obe državi imata na tone prostora, a če želite preiti iz države stranke v državo strežnika, kako velik naredite ta most? Ne gre za 'vrzimo na to veliko denarja in ga naredimo večjega'. Konec koncev je to pogosto ozko grlo, ki temelji na tehnologiji in motorju, ki ga uporabljate.'

Pogoste napačne predstave

Eno napačno prepričanje, ki ga Mann pogosto vidi, je povezano s tem, kako delujejo razvojne ekipe – natančneje z idejo, da lahko vsak popravi karkoli.

'Ko imate opravka s kompleksnimi kodnimi bazami, ki zajemajo več datotek, ki jih je zgradilo 200 ljudi, če pogledam svoje kodirnike in so to zgradili, koder A ne pozna celotnega projekta,' pojasnjuje. 'Obstaja koncept, da vsi vedo vse o kodi igre, zato bi moral umetnik nivojev pomagati pri popravku za arhitekturo nivojev. Veste, upravitelji skupnosti ne popravljajo napak.'

Enako sem slišal od Fredrika Brönjemarka, direktorja storitev v živo pri Massive Entertainmentu, studiu za The Division. „Velike spletne igre so izjemno zapleteni kosi programske opreme, ki se zanašajo na obsežno spletno strežniško infrastrukturo za podporo,“ pojasnjuje Brönjemark. „Povrh tega imate tudi dodatno plast storitev prve osebe, zato obstaja veliko različnih načinov, kako lahko gredo stvari narobe! Za nas v The Division so bile glavne vrste incidentov, ki bi lahko povzročile izpade ali težave s povezljivostjo, nestabilnost programske opreme za igre, ki se izvaja na strežnikih, ali težave ponudnika gostovanja. Zelo redko je težava pomanjkanje zmogljivosti strežnika. Na The Division 2 se naši strežniki samodejno spreminjajo glede na število igralcev, ki želijo igrati igro.'

Na dan lansiranja lahko gre karkoli narobe in pogosteje kot ne, je samo število igralcev na seznamu za spremljanje razmeroma malo. Lahko bi prišlo do puščanja pomnilnika, ene same, a katastrofalne vrstice napačne kode ali do zamika, ki je zakopan nekje v ogromnem strežniškem cevovodu. Igra bi lahko imela težave z določenim ponudnikom internetnih storitev ali, kot je omenil Brönjemark, bi lahko izpadle storitve prve osebe, na katere se igra zanaša. Težava je lahko kjer koli, a ne glede na to, kje je, je problem vseh. Nihče ni otok, ko gre za spletne igre, zato je lahko odzivanje na vprašanja izjemno težko in dolgotrajno.

'Vsaka lansiranja je drugačna'

Vsi razvijalci, s katerimi sem govoril, so opisali podoben postopek triaže za odpravljanje težav. Mann je ponudil pregled, kako bi lahko izgledal popravek od začetka do konca. Najprej mora razvijalec pregledati simptome težave, da ugotovi dejanski vzrok. Nato pripeljejo ljudi, ki so odgovorni za to področje igre, da najdejo rešitev. Je to nekaj, kar lahko posodobijo na svoji strani ali morajo izdati popravek? Ko najdejo rešitev, jo bodo morali preizkusiti, da se prepričajo, da ne pokvari ničesar drugega, še posebej, če gre za obliž.

'Preden je karkoli objavljen, je treba preveriti,' pravi Mann. »Z nosilci platform [kot sta Sony in Microsoft] se veliko pogovarjamo naprej in nazaj, da zagotovimo, da si skupaj prizadevamo za uspeh; iti moramo skozi korake QA. In ko gremo skozi ta popravek, če se koleno odzovemo in to popravimo zdaj, potem pa bomo morali pol ure pozneje narediti drugi popravek v istem dnevu, bo zmešnjava. Zato moramo reči: 'Ta popravek delamo; katere druge kritične težave lahko odpravimo v okviru tega? Kaj je še narobe?' Ne morete narediti obliža v pol ure. Prepričati se moraš, da si pameten pri tem, kako pokrpaš to vsebino.«

Ko je vse to opravljeno, če vesolje dopušča, lahko razvijalci potisnejo popravek skozi in ga začnejo spremljati in sporočati njegove učinke preko svojih družbenih kanalov. Toda 'ni pol ure obrata,' pravi Mann in dodaja, 'morda se bo na stotine ljudi tega dotaknilo, preden ugasne.'

Frank Sanchez, nekdanji predstavnik skupnosti BioWare in Gazillion Entertainment z inženirskimi izkušnjami, dobro pozna to paradigmo. Kot nekdo, ki je porabil veliko časa za zbiranje odgovorov in pripravo opomb o popravkih, je videl obe strani postopka posodabljanja, od povratnih informacij igralcev do oddaje popravkov. Prav tako bolje kot večina ve, kako zapleteni lahko postanejo popravki in kako frustrirajoče so lahko težave z zagonom tako za igralce kot za razvijalce.

'Smo zadnji ljudje, ki želijo videti, da se strežnik dvigne in nato dve uri pozneje zamuja, tako da se ljudje ne morejo prijaviti,' pojasnjuje Sanchez. „Zagotavljam vam, da če [razvijalci] pripravijo strežnik za beta različico in ta ne deluje pravilno, je to verjetno na repu nekoga, ki je vložil čas, ki presega tisto, kar so že hrupali, da bi ga spravil v stanje, v katerem je bi lahko zagnali. Torej, ko nekdo na spletu reče 'No, oni so samo leni', je to popolnoma in očitno napačno. Delo je vloženo, izziv je, kako se odzvati na težave in komunicirati z igralci, ko se zgodijo. To je nepopolna znanost ... vsaka izstrelitev je drugačna. Tudi če sta dve igri razviti na Unity ali karkoli drugega, tudi če je žanr enak, je proces drugačen. Ne morete reči 'Ta igra je bila v redu, kaj je problem s to igro', ker je v vsaki igri veliko edinstvenosti.'

Ne morete reči 'Ta igra je bila v redu, kaj je problem s to igro', ker je v vsaki igri veliko edinstvenosti.

Frank Sanchez

Sanchezovi komentarji se dotikajo še enega pogostega vprašanja, ki se pojavi ob času lansiranja: zakaj tega niste pričakovali? Morda je igra X pred nekaj meseci naletela na težave. Zagotovo bi razvijalci igre Y to lahko videli in sprejeli ukrepe, da bi se izognili istim težavam, kajne?

Razlike v posameznih igrah ob strani so vsi, s katerimi sem govoril, rekli, da nekaterih težav ni mogoče pričakovati. Notranje testiranje lahko naredi le toliko in se nikoli ne more zares primerjati z dejanskim zagonom igre.

'Ni simulacije v živo'

'Ne morete načrtovati za [sočasne igralce] v živo,' nadaljuje Sanchez. 'To je preprosto nemogoče. Nadomestka ni. Videl sem vse metode internega testiranja izjemnih situacij, preden jih daš tam, in preprosto ni simulacije v živo.'

Tu pridejo v poštev testi izjemnih situacij pred zagonom in obdobja beta. Niso popolni, vendar so najboljši način za oceno, kako bo izgledal začetek igre in kaj je treba popraviti pred glavnim časom. 'Beta so v veliko pomoč,' pravi Mann. 'Ne morete dobiti velikosti in obsega, kot ga naredite z internim testom beta. Enostavno ne morete najeti toliko ljudi, da bi zadeli vaše strežnike. Najboljši način za testiranje v živo je, da ste v živo. Če pogledate veliko alfa in beta, obstaja ta koncept, da ni dovolj strežnikov, da so hrošči in druge težave, vendar so v enem tednu triagirali in zadnja ali zadnja izdaja nima teh težav. . To je samo zato, ker je bil izkušen [v živo] in raziskan med temi beta različicami.'

»Pred kratkim je studio zagnal beta različico za svojo igro in kup mojih prijateljev je skočil navdušenih nad igro in so naleteli na hrošča, kjer so obtičali v vadnici, ker se ključni element še ni pojavil v strežniku, pravi Mann in ugotavljam, kako težko je lahko predvideti pomanjkljivosti pri zagonu spletne igre. „Zagotavljam, da je bil pri vseh testiranjih QA te igre ta predmet vedno tam. Edini način, da boste to ugotovili, je tako, da preizkusite ta tok v velikem obsegu. Sumim, da se ti fantje zdaj dobro zavedajo tega in vse te težave, da bi jo popravili za zagon, vse zaradi tega dela beta.'

Vsega ne moreš popraviti

Če so beta različice tako odlične, zakaj jih razvijalci ne obdržijo več in zakaj jih ne obdržijo več mesecev pred lansiranjem? Kot se pogosto dogaja v igrah, tehnologija in čas razvijalcem ne dovolita vedno, da počnejo točno tisto, kar želijo. Zaradi načina izdelave večine iger se ne združijo šele na koncu, kar je na splošno razlog, zakaj se beta pojavljajo tako blizu začetka. In ne glede na to, kaj se razvijalci naučijo iz beta, ne glede na težave, ki jih lahko razkrije, ne morejo realno odložiti svoje igre kot odgovor nanje. Ponudnik spletnih storitev ne želi, da ekipa zamudi začetni datum svojega strežnika, tako kot želi izdajatelj zamuditi datum začetka. Zato, tako kot nekaterih težav ni mogoče predvideti, nekaterih napak preprosto ni mogoče odpraviti pravočasno za zagon.

Divizija 2 Beta

The Divizija 2 beta urnik je bil dokaj izčrpen, z zasebnimi in odprtimi različicami beta ter bolj usmerjenim stresnim testom. Tega ne zmorejo vse igre, tiste, ki pa imajo ogromno koristi od tega, kar Brönjemark imenuje 'zadnja vaja'. Njegova prva odprta beta je načrtovana za 1. do 4. marec, dva tedna od začetka.

»Rad bi pošiljal brez napak,« meni Sanchez, komentar, ki ga boste slišali od vsakega razvijalca, ki je šel skozi pekel in se vrnil, da bi dejansko poslal izdelek. Toda vsaka ekipa vam bo povedala, da je to zelo težko narediti. To je samo realnost tega. Seznam stvari, ki jih je treba popraviti, se nenehno spreminja. Morate razumeti, da ko gre za hrošče, obstajajo hrošči, ki so potencialno poslani, in so napake, odkrite po zagonu. Vse, kar je treba dati prednost, načrtovati in govoriti o tem. To je triaža. Bolj posrečena lansiranja so tista, ki imajo hrošče, vendar nimajo hromih hroščev.'

Poleg tega je izdelava beta različice lahko sama po sebi dolgotrajna in delovno intenzivna naloga. Razvijalci ne morejo kar tako vdreti dela svoje igre in ga naložiti v Xbox Live ali PlayStation Network. Beta različica se pogosto razvija ločeno od (vendar v tandemu z) igre, kar zahteva več časa in denarja. Zato so težave, ki so bile že zdavnaj odpravljene v glavni različici igre, morda še vedno prisotne v njeni beta različici. To smo na primer videli v predstavitvah Anthem in v najnovejši beta različici za The Division 2.

»Precej pogosto slišim ljudi, ki pravijo, da mislijo, da so beta testi le marketinške kampanje, razvijalci pa se od njih tako ali tako ne morejo ničesar naučiti, saj je igra takrat že končana,« mi pove Brönjemark. 'Rad bi razblinil ta mit. Tudi ko je igra že natisnjena na disk in je popravek prvega dne že narejen, je še vedno ogromno stvari, ki jih lahko obravnavamo na strani strežnika, tako v smislu tehnologije kot tudi glede igranja in uravnoteženja .'

Po drugi strani pa Sanchez pravi, da so 'razporedi objave in časovni okviri razvoja iger zelo agresivni, včasih preveč agresivni.' Kdaj se kaj pošlje, koliko sredstev vam je ostalo, koliko časa ste v razvoju. Včasih je uspeh lansiranja v resnici odvisen od tega, kolikokrat ste morali premakniti svoje mejnike, kolikokrat ste odložili lansiranje, ker ste imeli kaj za polirati. Nekatere igre je mogoče dostaviti le z določeno količino laka. Ne morete reči, da je popolnoma in popolnoma v redu, ko postane zlato. Obstajajo primeri, ko bo igra dostavljena v stanju, ki je pripravljeno za zagon, vendar je morda treba narediti malo popestritve.'

Lansiranje je več kot prvi dan

Tako razvijalci kot igralci želijo, da njihove igre delujejo odlično, ko jih prvič zaženejo, vendar je realnost razvoja iger tako, da je toliko gibljivih delov in toliko nepremičnih omejitev, da bodo nekatere težave zagotovo zdrsnile skozi razpoke, in verjetnosti za to le naraščajo, ko so igre vse večje in večje. Sanchez meni, da moramo zato na tovrstna lansiranja gledati celostno. Uspešnost igre na dan zagona je pomembna, vendar ni vse.

'Niso težave, to se bodo vedno dogajale,' pravi Sanchez. »Tako rešujete ta vprašanja. Če ste počasni ali jih ne naslavljate pravilno ali če ste sovražni do svojih igralcev, se bo to držalo z njimi. Če si želim, da bi igralci razumeli eno stvar, je to, da se težave zgodijo ne glede na to, kako dobro jih načrtujete. Razvijalci bi morali odgovarjati za to, kako se nanje odzovejo. Če imate težave teden dni po lansiranju, jih postavite na ogenj in recite 'Hej, nimam dobrih izkušenj, zato me skrbi, da te težave niso odpravljene.' To so stvari, o katerih želimo slišati.'

Težave se zgodijo ne glede na to, kako dobro jih načrtujete.

Frank Sanchez

Nobena igra se ne zažene popolnoma. Enostavno se ne zgodi. Kot pravi Sanchez, 'vse, kar bi šteli za gladko lansiranje, je le nekaj, kar se nikoli ni dvignilo na raven, ko bi igralec zaznal, da je nekaj narobe.' V zakulisju se vedno dogajajo prepiri. Mann je to opisal kot kup razvijalcev, stisnjenih skupaj v 'vojni sobi', ki opazujejo steno monitorjev za povratne informacije in morebitne težave. Včasih te težave opazijo zgodaj, včasih se ne pojavijo nekaj ur, včasih pa jih ni mogoče odpraviti še nekaj ur ali celo nekaj dni.

Bistvo je, da bodo velike spletne igre ob lansiranju vedno imele nekaj tehničnih težav. Hudiča, vse sodobne igre imajo nekaj težav ob zagonu. To je samo narava današnje tehnologije in današnje industrije. To ne pomeni, da bi morali igralci slepo dati prednost igram, ki so izrinjene zaradi katastrofalne zasnove ali drugih težav, vendar postavlja povprečno zagon v perspektivo. Igra ima lahko manjše težave, ki jih sploh ne opazimo, ali pa ima očitne motnje igre. V vsakem primeru lahko vsakdo upa na najboljše, se pripravi na najslabše in opozori na težave, ko se neizogibno pojavijo.