'Se on yksinkertaisesti mahdotonta': Kehittäjät selittävät, miksi suuret verkkopelit näyttävät aina katkeavan julkaisun yhteydessä

Hajanaisen käynnistämisen välillä Hymni , Apex Legendsin yllätysjulkaisu ja tuleva julkaisu Divisioona 2 , vuoden 2019 alku on täynnä suuria verkkopelejä. Kuten BioWaren uusin ja lukemattomat pelit ennen ovat osoittaneet, tämän laajuuden moninpelit julkaistaan ​​harvoin loistavassa kunnossa. Näyttää siltä, ​​​​että jokaisessa online-pelissä on jonkin verran teknisiä ongelmia julkaisun yhteydessä, olivatpa ne pieniä, kuten Apex Legendsin viikko-ykkösvirheet, tai pelin katkaisijoita, kuten alun perin lamauttaneet yhteysongelmat Paholainen 3 .

Meillä on ollut ongelmia lanseerauksissa niin kauan kuin meillä on ollut verkkopelejä, mutta tuntuu, että keskustelu julkaisuun liittyvistä ongelmista ei ole mennyt mihinkään. Näemme samat kysymykset esiin joka kerta. Miksi näin kävi? Miksi kehittäjät eivät odottaneet tätä? Miksi korjaus kesti niin kauan? Koska niin monia suuria verkkopelejä julkaistiin niin lähellä toisiaan, Games as a Servicen noustessa alalle, nyt näytti olevan hyvä aika tuoda joitain näistä kysymyksistä kehittäjille, jotta saataisiin selville pelätty julkaisupäivän seisokki. Miksi näemme jatkuvasti samoja ongelmia pelien julkaisun yhteydessä, ja miten kehittäjät käsittelevät niitä?

'Kapasiteetti on hyvin harvoin ongelma'

Aina kun pelit katkeavat tai muodostavat hitaita yhteyden, monet olettavat, että se johtuu siitä, että niiden palvelintila loppui. Että kehittäjät aliarvioivat kuinka monta pelaajaa kirjautuisi sisään ja sen seurauksena heidän palvelimensa taipuivat rasituksen alla. Siinä tapauksessa heidän tarvitsee vain maksaa enemmän palvelimia, eikö niin? No ei, ei välttämättä; kuten usein pelejä tehtäessä, se ei ole niin yksinkertaista.

'Yksi verkossa usein näkevistä ajattelutavoista on: 'Miksi yrityksellä A ei ole lisää palvelimia?' Alex Mann, kehityspäällikkö ja entinen laadunvarmistusanalyytikko EA:sta, kertoo meille. 'Näet julkaisun yhteydessä eniten liikennettä näissä peleissä. Kaikki ovat olleet hypettyjä, markkinointitiimi on tehnyt työnsä hyvin, kaikki ovat todella innoissaan päästäkseen verkkoon, ja heti, kun peli ponnahtaa, kaikki napsauttavat 'Go'. Mutta useimpien pelien elinkaaren aikana huomaat, että sinulla on tämä massiivinen purske ja sitten se loppuu. Jos jokainen peliyhtiö ostaisi laitteiston kattamaan kaiken, mitä he tarvitsivat tuon ensimmäisen purskeen aikana, kaksi viikkoa myöhemmin heillä olisi 50 % laitteistostaan ​​siellä, joita ei koskaan käytetty.

'Kyse ei ole siitä, että heitetään paljon rahaa siihen ja tehdään siitä isompi.'

Alex Mann

Tämä tekee kehittäjien vaikeaksi valmistautua julkaisuun ilman ylikulutusta ja ostoa liian monta palvelimia. Onneksi kehittäjillä on nyt pääsy virtuaalisiin palvelimiin Amazon Web Servicesin kaltaisten yritysten kautta, ja ne voidaan aktivoida tai deaktivoida tarpeen mukaan. Tällaisista palvelimista tuli myös tarvetta, kun pelit siirtyivät pois vertaisyhteyksistä – tyypistä, joka tuki pelejä, kuten Halo 2 jo vuonna 2004 – omistetuille palvelimille, jotka tukevat massiivisia, pysyviä pelejä, kuten Kohtalo 2 ja Hymni. Virtuaalipalvelimet eivät kuitenkaan ole mikään ihmelääke, ja niissä on omat ongelmansa.

'Kapasiteetti ei välttämättä riipu palvelimien määrästä', Mann sanoo. 'Vaikka odotamme miljoonia pelaajia ja meillä on palvelimet, emme odota heidän kaikkien osuvan sisäänkirjautumisportaaliin samanaikaisesti. Kyse on siitä, että moottoritiellä on tarpeeksi kaistaa, jotta ihmiset pääsevät läpi. Sinulla on kaksi maata yhdistettynä sillan kautta, ja molemmissa maissa on tonneittain tilaa, mutta kuinka suuren sillan teet siirtyäksesi asiakasmaasta palvelinmaahan? Kyse ei ole siitä, että 'heitetään siihen paljon rahaa ja tehdään siitä isompi'. Loppujen lopuksi se on usein pullonkaula, joka perustuu käyttämääsi tekniikkaan ja moottoriin.

Yleisiä väärinkäsityksiä

Yksi Mannin usein näkemä väärinkäsitys liittyy kehitystiimien toimintaan - erityisesti ajatukseen, että kuka tahansa voi korjata mitä tahansa.

'Kun olet tekemisissä monimutkaisten koodikantojen kanssa, jotka kattavat useita 200 ihmisen rakentamia tiedostoja, jos katson koodaajiani ja he ovat rakentaneet tämän, kooderi A ei tunne koko projektia', hän selittää. 'On olemassa sellainen käsite, että kaikki tietävät kaiken pelin koodista, joten tasoartistin pitäisi auttaa tasoarkkitehtuurin korjaamisessa. Tiedätkö, yhteisön ylläpitäjät eivät korjaa vikoja.

Kuulin saman Fredrik Brönjemarkilta, The Divisionin takana olevan studion Massive Entertainmentin live-palveluiden johtajalta. 'Suuret verkkopelit ovat erittäin monimutkaisia ​​ohjelmistoja, jotka tukevat valtavaa verkkopalvelininfrastruktuuria', Brönjemark selittää. 'Sen lisäksi sinulla on myös ylimääräinen ensimmäisen osapuolen palvelukerros, joten asiat voivat mennä pieleen monella eri tavalla! Meille The Divisionilla tärkeimmät häiriötyypit, jotka saattoivat aiheuttaa seisokkeja tai yhteysongelmia, olivat palvelimilla käynnissä olevan peliohjelmiston epävakaus tai isännöintipalveluntarjoajan ongelmat. Palvelimen kapasiteetin loppuminen on hyvin harvoin ongelma. Division 2:ssa palvelimemme skaalautuvat automaattisesti peliin haluavien pelaajien lukumäärän mukaan.

Monet asiat voivat mennä pieleen julkaisupäivänä, ja useimmiten pelkkä pelaajien määrä on suhteellisen alhainen katselulistalla. Siellä voi olla muistivuoto, yksi, mutta katastrofaalinen virheellisen koodin rivi tai viive, joka on haudattu jonnekin valtavaan palvelinputkeen. Pelissä voi olla ongelma tietyn Internet-palveluntarjoajan kanssa, tai kuten Brönjemark mainitsi, pelin tukemat ensimmäisen osapuolen palvelut voivat kaatua. Ongelma voi olla missä tahansa, mutta riippumatta siitä, missä se on, se on kaikkien ongelma. Kukaan ei ole saari verkkopeleissä, ja se voi tehdä ongelmiin vastaamisesta uskomattoman vaikeaa ja aikaa vievää.

'Jokainen julkaisu on erilainen'

Kaikki kehittäjät, joiden kanssa puhuin, kuvasivat samanlaista triage-prosessia ongelmien korjaamiseksi. Mann tarjosi yleiskatsauksen siitä, miltä korjaus voisi näyttää alusta loppuun. Ensinnäkin kehittäjän on seulottava ongelman oireet tunnistaakseen todellisen syyn. Sitten he tuovat ihmiset, jotka ovat vastuussa kyseisestä pelialueesta, kehittämään ratkaisua. Voivatko he päivittää jotain, vai pitääkö heidän julkaista korjaustiedosto? Kun he löytävät ratkaisun, heidän on testattava se varmistaakseen, ettei se riko mitään muuta, varsinkin jos se on korjaustiedosto.

'Siellä on tarkastus ennen kuin mitään julkaistaan', Mann sanoo. 'Alustapitimien [kuten Sony ja Microsoft] kanssa on paljon edestakaisin, jotta voimme varmistaa, että työskentelemme menestyksen eteen yhdessä; meidän on käytävä läpi laadunvarmistusvaiheet. Ja kun käymme läpi tätä korjaustiedostoa, jos reagoimme ja korjaamme tämän nyt, mutta sitten puoli tuntia myöhemmin meidän on tehtävä toinen korjaus samana päivänä, siitä tulee sotku. Joten meidän on sanottava: 'Teemme tätä korjausta; mitä muita kriittisiä ongelmia voimme korjata osana tätä? Mikä muu on vialla?' Et voi tehdä laastaria puolessa tunnissa. Sinun on varmistettava, että olet älykäs sisällön korjaamisessa.

Kun kaikki on tehty, jos universumi sallii, kehittäjät voivat työntää korjaustiedoston läpi ja alkaa seurata sitä ja viestiä sen vaikutuksista sosiaalisten kanaviensa kautta. Mutta 'ei ole puolen tunnin kiertoa', Mann sanoo ja lisää, 'on ehkä satoja ihmisiä, jotka koskettavat sitä ennen kuin se sammuu.'

Frank Sanchez, entinen BioWare- ja Gazillion Entertainment -yhteisön edustaja, jolla on insinöörikokemusta, tuntee tämän paradigman hyvin. Koska hän on käyttänyt paljon aikaa vastausten kokoamiseen ja korjausmuistiinpanojen laatimiseen, hän on nähnyt päivitysprosessin molemmat puolet pelaajien palautteesta korjaustiedoston lähettämiseen. Hän myös tietää paremmin kuin useimmat, kuinka monimutkaisia ​​korjauksia voi tulla ja kuinka turhauttavia käynnistysongelmat voivat olla pelaajille ja kehittäjille.

'Olemme viimeiset ihmiset, jotka haluavat nähdä palvelimen nousevan ja sitten kaksi tuntia myöhemmin niin paljon viivettä, että ihmiset eivät voi kirjautua sisään', Sanchez selittää. 'Takaan sinulle, jos [kehittäjät] tuovat palvelimen beta-vaiheeseen ja se ei toimi oikein, se on luultavasti jonkun perässä, joka on käyttänyt enemmän aikaa kuin mitä hän jo yritti saada palvelimen tilaan, jossa se voisi käynnistää. Joten kun joku verkossa sanoo 'No, he ovat vain laiskoja', se on täysin ja räikeän väärä. Työtä on tehty, haasteena on reagoida ongelmiin ja kommunikoida pelaajille, kun niitä tapahtuu. Se on epätäydellinen tiede… jokainen laukaisu on erilainen. Vaikka kaksi peliä kehitetään Unityssa tai missä tahansa, vaikka genre olisi sama, prosessi on erilainen. Et voi sanoa 'Tämä peli oli hyvä, mikä tässä pelissä on ongelma', koska jokaisessa pelissä on paljon ainutlaatuisuutta.

Et voi sanoa 'Tämä peli oli hyvä, mikä tässä pelissä on ongelma', koska jokaisessa pelissä on paljon ainutlaatuisuutta.

Frank Sanchez

Sanchezin kommentit koskettavat toista yleistä kysymystä, joka nousee esiin julkaisun aikaan: miksi et odottanut tätä? Ehkä peli X joutui ongelmiin muutama kuukausi sitten. Varmasti pelin Y kehittäjät voisivat nähdä tämän ja ryhtyä toimiin välttääkseen samat ongelmat, eikö niin?

Yksittäisten pelien eroja lukuun ottamatta kaikki, joiden kanssa puhuin, sanoivat, että joitain ongelmia ei voida ennakoida. Sisäinen testaus voi tehdä vain niin paljon, eikä sitä voi koskaan verrata pelin todelliseen käynnistämiseen.

'Ei ole vain simulaatiota livenä'

'Et voi suunnitella live-lähetyksiä [samanaikaisia ​​pelaajia]', Sanchez jatkaa. 'Se on vain mahdotonta. Korvaavaa ei ole. Olen nähnyt kaikki menetelmät stressitestaamiseksi sisäisesti ennen kuin julkaiset sen, eikä live-simulaatiota ole olemassa.

Tässä vaiheessa julkaisua edeltävät stressitestit ja beta-jaksot tulevat esiin. Ne eivät ole täydellisiä, mutta ne ovat paras tapa mitata, miltä pelin julkaisu näyttää ja mitä on korjattava ennen parasta aikaa. 'Beetoista on valtavasti apua', Mann sanoo. 'Et voi saada sisäisesti sitä kokoa ja mittakaavaa kuin beta-testillä. Et vain voi palkata niin montaa ihmistä osumaan palvelimiisi. Paras tapa testata livenä on olla livenä. Jos tarkastellaan monia alfa- ja betaversioita, on käsitys, että palvelimia ei ole tarpeeksi, että siellä on bugeja ja muita ongelmia, mutta viikon sisällä ne on testattu ja uusimmassa tai lopullisessa julkaisussa ei ole näitä ongelmia. . Tämä johtuu vain siitä, että se on koettu [live] ja tutkittu näiden beta-vaiheiden aikana.

'Äskettäin eräs studio suoritti pelin betaversion ja joukko ystäviäni hyppäsi innoissaan pelaamaan, ja he törmäsivät bugiin, jossa he olivat juuttuneet opetusohjelmaan, koska avainkohde ei ole syntynyt palvelimelle', Mann kertoo. minulle, huomauttaen, kuinka hankalaa voi olla ennakoida virheitä verkkopelin julkaisussa. 'Takaan kaikissa pelin laadunvarmistustesteissä, että esine oli aina siellä. Ainoa tapa löytää se on testata tätä virtausta massiivisessa mittakaavassa. Epäilen, että nuo kaverit ovat nyt hyvin tietoisia siitä ja koko ongelmasta, jotta se korjataan julkaisua varten, kaikki tuon beta-työn vuoksi.

Kaikkea ei voi korjata

Jos betaversiot ovat niin mahtavia, miksi kehittäjät eivät pidä niitä hallussaan enemmän, ja miksi eivät pidä niitä kuukausia ennen julkaisua? Kuten peleissä usein tapahtuu, tekniikka ja aika eivät aina anna kehittäjien tehdä juuri sitä, mitä he haluavat tehdä. Useimpien pelien valmistustavasta johtuen ne yhdistyvät vasta lopussa, minkä vuoksi beetat näyttävät yleensä niin lähellä julkaisua. Ja riippumatta siitä, mitä kehittäjät oppivat betasta, riippumatta siitä, mitä ongelmia se paljastaa, he eivät voi realistisesti viivyttää peliään vastauksena niihin. Verkkopalveluntarjoaja ei halua, että tiimi missaa palvelimensa aloituspäivää enempää kuin julkaisija haluaa missata julkaisupäivänsä. Tästä syystä, aivan kuten joitain ongelmia ei voida ennakoida, joitain bugeja ei vain voida korjata ajoissa julkaisua varten.

Division 2 betat

The Division 2 beta aikataulu oli melko kattava, yksityisiä ja avoimia betaversioita sekä kohdennettua stressitestiä. Kaikki pelit eivät voi muuttaa sitä, mutta ne, jotka hyötyvät valtavasti Brönjemarkin kutsumasta 'viimeisestä harjoituksesta'. Sen ensimmäinen avoin beta on suunniteltu 1.–4. maaliskuuta, kaksi viikkoa julkaisun jälkeen.

'Haluaisin lähettää ilman virheitä', Sanchez pohtii kommentin, jonka kuulet kaikilta kehittäjiltä, ​​jotka ovat käyneet läpi helvetin ja palanneet toimittaakseen tuotteen. Mutta mikä tahansa joukkue kertoo sinulle, että sen tekeminen on erittäin vaikeaa. Se on vain sen todellisuus. Korjattavien asioiden lista muuttuu jatkuvasti. Sinun on ymmärrettävä, että kun kyse on bugeista, on vikoja, jotka mahdollisesti lähetetään, ja bugeja, jotka havaitaan julkaisun jälkeen. Kaikkea sitä pitää priorisoida ja suunnitella vastaan ​​ja puhua. Se on triage. Onnellisimmat julkaisut ovat ne, joissa on virheitä, mutta ei lamauttavia bugeja.

Lisäksi betaversion tekeminen voi olla pitkä ja työvoimavaltainen tehtävä. Kehittäjät eivät voi vain hakkeroida osaa pelistään ja ladata sitä Xbox Liveen tai PlayStation Networkiin. Betat kehitetään usein erillään pelistä (mutta yhdessä) pelistä, mikä vie enemmän aikaa ja rahaa. Tästä syystä ongelmat, jotka on jo kauan sitten korjattu pelin päärakennuksessa, voivat edelleen esiintyä sen betaversiossa. Näimme tämän esimerkiksi Anthemin demoissa ja The Division 2:n uusimmassa betaversiossa.

'Melko usein kuulen ihmisten sanovan, että heidän mielestään beta-testit ovat vain markkinointikampanjoita, eivätkä kehittäjät voi oppia niistä mitään, koska peli on siinä vaiheessa jo valmis', Brönjemark kertoo. 'Haluaisin hälventää tuon myytin. Vaikka peli on jo painettu levylle ja ensimmäisen päivän korjaus on jo tehty, pystymme vielä ratkaisemaan valtavan määrän asioita palvelinpuolella, sekä tekniikan että pelattavuuden ja tasapainotuksen suhteen. .'

Toisaalta Sanchez sanoo, että 'julkaisuaikataulut ja pelien kehitysaikajanat ovat erittäin aggressiivisia, joskus liian aggressiivisia. Milloin jokin toimitetaan, kuinka paljon rahoitusta sinulla on jäljellä, kuinka kauan olet ollut kehitystyössä. Joskus lanseerauksen onnistuminen riippuu todellakin siitä, kuinka monta kertaa olet joutunut siirtämään virstanpylväitäsi taaksepäin, kuinka monta kertaa lykkäät laukaisua, koska sinulla oli hiottavaa. Jotkut pelit voidaan toimittaa vain tietyn kiillotusmäärän kanssa. Et voi sanoa, että se on täysin ja täysin hieno, kun se menee kullaksi. On tapauksia, joissa peli toimitetaan julkaisuvalmiissa tilassa, mutta hieman kiillotusta saattaa olla tarpeen tehdä.

Laukaisu on enemmän kuin ensimmäinen päivä

Sekä kehittäjät että pelaajat haluavat peliensä toimivan täydellisesti, kun he käynnistävät ne ensimmäisen kerran, mutta pelikehityksen todellisuus on, että siellä on niin paljon liikkuvia osia ja niin monia liikkumattomia rajoituksia, että jotkut ongelmat lipsahtavat väistämättä halkeamien läpi. Todennäköisyys siihen vain kasvaa pelien kasvaessa ja kasvaessa. Sanchez uskoo, että tämän vuoksi meidän on tarkasteltava tällaisia ​​laukaisuja kokonaisvaltaisesti. Pelin suorituskyky julkaisupäivänä on tärkeä, mutta se ei ole kaikki kaikessa.

'Se ei ole ongelmat, niitä tulee aina tapahtumaan', Sanchez sanoo. 'Näin käsittelet näitä asioita. Jos olet hidas tai et käsittele niitä kunnolla tai jos olet vihamielinen pelaajiasi kohtaan, se pysyy heidän kanssaan. Jos toivon pelaajien ymmärtävän yhden asian, se on se, että ongelmia tapahtuu riippumatta siitä, kuinka hyvin suunnittelet ne. Sinun tulee asettaa kehittäjät vastuuseen siitä, miten heihin vastataan. Jos sinulla on ongelmia viikon kuluttua laukaisusta, laita jalat tuleen ja sano 'Hei, minulla ei ole hyviä kokemuksia, tästä syystä olen huolissani siitä, että näitä ongelmia ei ole korjattu.' Nämä ovat asioita, joista haluamme kuulla.

Ongelmia tapahtuu riippumatta siitä, kuinka hyvin suunnittelet ne.

Frank Sanchez

Mikään peli ei käynnisty täydellisesti. Se ei vain tapahdu. Sanchez sanoo, että 'kaikki mitä pitäisit sujuvana käynnistyksenä on vain jotain, joka ei koskaan noussut tasolle, jolla pelaaja havaitsi jotain olevan vialla.' Kulissien takana tapahtuu aina sekoitusta. Mann kuvaili sitä joukkona kehittäjiä, jotka olivat ryyppääneet 'sotahuoneessa' katsomassa monitorien seinää palautetta ja mahdollisia ongelmia varten. Joskus he havaitsevat ongelmat aikaisin, joskus ne eivät näy muutamaan tuntiin, ja joskus niitä ei voida korjata muutamaan tuntiin tai jopa muutamaan päivään.

Asia on siinä, että massiivisissa verkkopeleissä tulee aina olemaan teknisiä ongelmia julkaisun yhteydessä. Helvetti, kaikissa nykyaikaisissa peleissä on joitain ongelmia julkaisun yhteydessä. Se on vain tämän päivän teknologian ja teollisuuden luonne. Tämä ei tarkoita, että pelaajien pitäisi sokeasti antaa passi peleille, jotka on työnnetty ulos katastrofaalisen suunnittelun tai muiden ongelmien vuoksi, mutta se asettaa keskimääräisen julkaisun perspektiiviin. Pelissä voi olla pieniä ongelmia, joita emme edes huomaa, tai siinä voi olla ilmeisiä pelin katkaisijoita. Joka tapauksessa kuka tahansa voi vain toivoa parasta, valmistautua pahimpaan ja ilmoittaa ongelmista, kun niitä väistämättä tulee esiin.