'Det er bare umulig': Utviklere forklarer hvorfor store nettspill alltid ser ut til å gå i stykker ved lansering

Mellom den fragmenterte lanseringen av Hymne , overraskelseslanseringen av Apex Legends , og den kommende lanseringen av Divisjon 2 , tidlig 2019 er stablet med store nettspill. Som BioWares siste, og utallige spill før det har demonstrert, lanseres flerspillerspill av dette omfanget sjelden i en strålende tilstand. Det virker som alle online spill har noen tekniske problemer ved lansering, enten de er mindre, som uke-en-feilene i Apex Legends, eller spillbrytere, som tilkoblingsproblemene som i utgangspunktet lammet Djevelen 3 .

Vi har hatt trøblete lanseringer så lenge vi har hatt nettspill, men det føles som om samtalen rundt lanseringsproblemer egentlig ikke har gått noen vei. Vi ser de samme spørsmålene dukke opp hver gang. Hvorfor skjedde dette? Hvorfor forutså ikke utviklerne dette? Hvorfor tok det så lang tid å fikse? Med så mange store nettspill som slippes så tett sammen, med fremveksten av Games as a Service i bransjen, virket det nå som et godt tidspunkt å bringe noen av disse spørsmålene til utviklerne i håp om å avmystifisere den fryktede nedetiden på lanseringsdagen. Hvorfor ser vi stadig de samme problemene når spill lanseres, og hvordan håndterer utviklerne dem?

'Kapasitet er svært sjelden problemet'

Når spill går ned eller er trege med å koble til, antar mange at det er fordi de gikk tom for serverplass. At utviklerne undervurderte hvor mange spillere som ville logge på, og som et resultat av dette ble serverne deres under belastningen. I så fall er alt de trenger å gjøre å betale for flere servere, ikke sant? Vel, nei, ikke nødvendigvis; som ofte er tilfellet når man lager spill, er det ikke så enkelt.

'En av tankesettene du ser mye på nettet er: 'Hvorfor har ikke Company A fått flere servere?' Alex Mann, en utviklingssjef og tidligere QA-analytiker hos EA, forteller oss. «Ved lansering ser du den største mengden trafikk på disse spillene. Alle har blitt hypet, markedsføringsteamet har gjort jobben sin bra, alle er veldig glade for å komme på nett, og i det øyeblikket spillet dukker opp, klikker alle 'Go'. Men du vil merke med livssyklusen til de fleste spill, at du har denne massive utbruddet, og så tar det slutt. Hvis alle spillselskaper der ute kjøpte maskinvaren for å dekke alt de trengte i løpet av det første utbruddet, ville de to uker senere ha 50 % av maskinvaren sin der aldri brukt.'

'Det handler ikke om 'La oss kaste masse penger på det og gjøre det større.'

Alex Mann

Dette gjør det vanskelig for utviklere å forberede seg til lansering uten å bruke for mye penger og kjøpe for mange servere. Heldigvis har utviklere nå tilgang til virtuelle servere gjennom selskaper som Amazon Web Services, og disse kan aktiveres eller deaktiveres etter behov. Denne typen servere ble også nødvendige ettersom spill flyttet bort fra peer-to-peer-forbindelsene – typen som støttet spill som Halo 2 tilbake i 2004 – til dedikerte servere som opprettholder massive, vedvarende spill som Skjebne 2 og Anthem. Virtuelle servere er imidlertid ikke en mirakelkur, og de har sine egne problemer.

'Kapasitet handler ikke nødvendigvis om antall servere,' sier Mann. «Selv om vi forventer millioner av spillere og vi har serverne, forventer vi ikke at alle skal treffe den påloggingsportalen samtidig. Det handler om å ha nok kjørefelt på motorveien til at folk kan komme gjennom. Du har to land koblet til via bro, og begge landene har massevis av plass på dem, men for å flytte fra klientlandet til serverlandet, hvor stor gjør du den broen? Det handler ikke om 'La oss kaste masse penger på det og gjøre det større.' På slutten av dagen er det ofte en flaskehals basert på teknologien og motoren du bruker.'

Vanlige misoppfatninger

En misforståelse som Mann ofte ser har å gjøre med hvordan utviklingsteam opererer - spesifikt ideen om at hvem som helst kan fikse hva som helst.

'Når du har å gjøre med komplekse kodebaser som spenner over flere filer bygget av 200 personer, hvis jeg ser på kodene mine og de har bygget dette, kjenner ikke koder A hele prosjektet,' forklarer han. «Det er dette konseptet at alle vet alt om spillkoden, så nivåartisten bør hjelpe til med å fikse nivåarkitekturen. Du vet, fellesskapsledere fikser ikke feil.'

Jeg hørte det samme fra Fredrik Brönjemark, direktør for livetjenester i Massive Entertainment, studioet bak The Division. 'Store nettspill er ekstremt kompliserte stykker programvare, som er avhengige av en massiv nettserverinfrastruktur for å støtte det,' forklarer Brönjemark. «I tillegg har du det ekstra laget med førstepartstjenester, så det er mange forskjellige måter ting kan gå galt på! For oss på The Division var hovedtypene hendelser som kunne forårsake nedetid eller tilkoblingsproblemer ustabilitet i spillprogramvaren som kjører på serverne, eller problemer med vertsleverandører. Å gå tom for serverkapasitet er svært sjelden problemet. På The Division 2 skaleres serverne våre automatisk avhengig av antall spillere som ønsker å spille spillet.'

En rekke ting kan gå galt på lanseringsdagen, og oftere enn ikke er det store antallet spillere relativt lavt på overvåkningslisten. Det kan være en minnelekkasje, en enkelt, men katastrofal linje med feil kode, eller en flekk av etterslep begravd et sted i den enorme serverrørledningen. Et spill kan ha et problem med en bestemt ISP, eller som Brönjemark nevnte, førstepartstjenestene som et spill er avhengig av kan gå ned. Problemet kan være hvor som helst, men uansett hvor det er, er det alles problem. Ingen er en øy når det kommer til nettspill, og det kan gjøre det utrolig vanskelig og tidkrevende å svare på problemer.

'Hver lansering er forskjellig'

Alle utviklerne jeg snakket med beskrev en lignende triage-prosess for å fikse problemer. Mann ga en oversikt over hvordan en løsning kan se ut fra start til slutt. Først må en utvikler sile gjennom symptomene på problemet for å identifisere den faktiske årsaken. Deretter henter de inn folkene som er ansvarlige for det området av spillet for å finne en løsning. Er det noe de kan oppdatere på sin side, eller må de utstede en oppdatering? Når de finner en løsning, må de teste den for å sikre at den ikke ødelegger noe annet, spesielt hvis det er et plaster.

'Det er en sjekk før noe går live,' sier Mann. «Det er mye frem og tilbake med plattformholdere [som Sony og Microsoft] for å sikre at vi jobber mot suksess sammen; vi må gå gjennom QA-trinn. Og mens vi går gjennom den lappen, hvis vi reagerer på kne og fikser dette nå, men en halvtime senere må vi gjøre en ny lapp samme dag, blir det rot. Så vi må si: 'Vi gjør denne oppdateringen; hvilke andre kritiske problemer kan vi fikse som en del av dette? Hvilke andre ting er galt? Du kan ikke bare lage en lapp på en halvtime. Du må sørge for at du er smart med hvordan du lapper det innholdet.'

Når alt dette er gjort, hvis universet tillater det, kan utviklerne presse oppdateringen gjennom og begynne å overvåke den og kommunisere effektene gjennom sine sosiale kanaler. Men 'det er ikke en halvtimes tur,' sier Mann, og legger til, 'det er kanskje hundrevis av mennesker som vil røre det før det slukkes.'

Frank Sanchez, en tidligere BioWare og Gazillion Entertainment-fellesskapsrepresentant med ingeniørerfaring, kjenner dette paradigmet godt. Som en som har brukt mye tid på å samle svar og utarbeide oppdateringsnotater, har han sett begge sider av oppdateringsprosessen, fra tilbakemeldinger fra spillere til innsending av oppdateringer. Han vet også bedre enn de fleste hvor kompliserte reparasjoner kan bli, og hvor frustrerende lanseringsproblemer kan være for både spillere og utviklere.

'Vi er de siste som ønsker å se en server gå opp og deretter to timer senere halte så dårlig at folk ikke kan logge på,' forklarer Sanchez. «Jeg garanterer deg at hvis [utviklerne] tar opp en server for en beta og den ikke fungerer som den skal, er det sannsynligvis i bakkanten av noen som har lagt inn tid utover det de allerede knaser på for å få den til en tilstand der den kunne lansere. Så når noen på nettet sier «Vel, de er bare late», er det fullstendig og åpenbart usant. Arbeidet er lagt ned, utfordringen er hvordan man skal reagere på problemer og kommunisere til spillere når de skjer. Det er en ufullkommen vitenskap … hver lansering er forskjellig. Selv om to spill er utviklet på Unity eller hva som helst, selv om sjangeren er den samme, er prosessen annerledes. Du kan ikke si 'Dette spillet var bra, hva er problemet med dette spillet', fordi det er mye unikt ved hvert spill.

Du kan ikke si 'Dette spillet var bra, hva er problemet med dette spillet', fordi det er mye unikt ved hvert spill.

Frank Sanchez

Sanchez sine kommentarer berører et annet vanlig spørsmål som dukker opp rundt lanseringstidspunktet: hvorfor forutså du ikke dette? Kanskje spilte X fikk problemer for noen måneder siden. Utviklerne av spill Y kunne sikkert se det og iverksette tiltak for å unngå de samme problemene, ikke sant?

Bortsett fra forskjeller i individuelle spill, sa alle jeg snakket med at noen problemer ikke kan forutses. Intern testing kan bare gjøre så mye, og det kan aldri sammenlignes med å faktisk lansere et spill.

'Det er bare ingen simulering for live'

«Du kan ikke planlegge for live [samtidige spillere],» fortsetter Sanchez. «Det er bare umulig. Det er ingen erstatning. Jeg har sett alle metoder for stresstesting av noe internt før du legger det ut der, og det er bare ingen simulering for live.'

Det er her pre-lansering stresstester og betaperioder kommer inn i bildet. De er ikke perfekte, men de er den beste måten å måle hvordan et spills lansering vil se ut og hva som må fikses før beste sendetid. 'Betaer er enormt nyttige,' sier Mann. «Du kan ikke få den størrelsen og skalaen du gjør med en beta-test internt. Du kan bare ikke ansette så mange mennesker til å treffe serverne dine. Den beste måten å teste live på er ved å være live. Hvis du ser på mange alfaer og betaer, er det dette konseptet at det ikke er nok servere, at det er feil og andre problemer, men i løpet av en uke har de triaget og den siste eller siste utgivelsen har ikke disse problemene . Det er bare fordi det er opplevd [live] og undersøkt under disse betaene.'

«Nylig kjørte et studio en beta for spillet sitt, og en gjeng av vennene mine hoppet i begeistret for å spille, og de traff en feil der de sitter fast i opplæringen fordi et nøkkelelement ikke har oppstått på serveren, forteller Mann meg, og legger merke til hvor vanskelig det kan være å forutse feil i en lansering av nettspill. «Jeg garanterer i all QA-testing på det spillet, at elementet alltid var der. Den eneste måten du kommer til å finne det på er ved å teste denne flyten i massiv skala. Jeg mistenker at de gutta nå er godt klar over det og hele problemet for å få det fikset for lansering, alt på grunn av det betaarbeidet.'

Du kan ikke fikse alt

Hvis betaer er så gode, hvorfor har ikke utviklere flere av dem, og hvorfor ikke holde dem måneder før lansering? Som ofte er tilfellet i spill, lar teknologi og tid ikke alltid utviklere gjøre akkurat det de vil. På grunn av måten de fleste spill er laget på, kommer de ikke sammen før rett på slutten, og det er generelt grunnen til at betaversjoner vises så nærme lansering. Og uavhengig av hva utviklere lærer av en beta, uansett hvilke problemer den kan avsløre, kan de ikke realistisk utsette spillet som svar på dem. En nettjenesteleverandør vil ikke at et team skal gå glipp av serverstartdatoen lenger enn en utgiver ønsker å gå glipp av lanseringsdatoen. Dette er grunnen til at, akkurat som noen problemer ikke kan forutses, kan noen feil bare ikke fikses i tide før lansering.

Divisjon 2 Betas

De Divisjon 2 beta timeplanen var ganske omfattende, med private og åpne betaversjoner samt en mer målrettet stresstest. Ikke alle spill kan svinge det, men de som har stor nytte av det Brönjemark kaller den siste øvelsen. Den første åpne betaen er planlagt 1. til 4. mars, to uker etter lansering.

'Jeg vil gjerne sende uten feil,' vurderer Sanchez, en kommentar du vil høre fra enhver utviklere som har gått gjennom helvete og tilbake for å faktisk sende et produkt. «Men hvilket som helst lag vil fortelle deg at det er veldig vanskelig å gjøre. Det er bare realiteten. Listen over ting som må fikses er i stadig endring. Du må forstå at når det gjelder feil, er det feil som potensielt sendes, og det er feil oppdaget etter lansering. Alt det må bli prioritert og planlagt opp mot og snakket om. Det er triage. De heldigere lanseringene er de som har feil, men som ikke har lammende feil.'

I tillegg kan det være en langvarig og arbeidskrevende oppgave å lage en betakonstruksjon. Utviklere kan ikke bare hacke av en del av spillet og laste det opp til Xbox Live eller PlayStation Network. Betaer utvikles ofte separat fra (men i takt med) et spill, som tar mer tid og penger. Dette er grunnen til at problemer som for lengst er løst i hovedbygget til et spill fortsatt kan være tilstede i betaen. Vi så dette i Anthems demoer og i den siste betaversjonen for The Division 2, for eksempel.

«Ganske ofte hører jeg folk si at de tror beta-tester bare er markedsføringskampanjer, og utviklerne kan uansett ikke lære noe av dem, siden spillet allerede er ferdig på det tidspunktet,» forteller Brönjemark til meg. «Jeg vil gjerne avlive den myten. Selv når spillet allerede er trykt på plate og dag-en-oppdateringen allerede er ferdig, er det fortsatt en enorm mengde ting vi er i stand til å ta tak i serversiden, både når det gjelder teknologi, men også når det gjelder gameplay og balansering. .'

På baksiden, sier Sanchez, 'publiseringsplaner og tidslinjer for spillutvikling er veldig aggressive, noen ganger for aggressive. Når sendes noe, hvor mye finansiering har du igjen, hvor lenge har du vært i utvikling. Noen ganger avhenger suksessen med lanseringen virkelig av hvor mange ganger du har måttet skyve milepælene dine, hvor mange ganger du forsinket lanseringen fordi du hadde noe å pusse opp. Noen spill kan bare sendes med en viss mengde polish. Du kan ikke si at det er helt og aldeles greit når det først blir gull. Det er tilfeller der et spill sendes i en tilstand som er klar for lansering, men det kan være litt polering som må gjøres.'

En lansering er mer enn dag én

Utviklere og spillere vil begge at spillene deres skal fungere perfekt første gang de starter dem opp, men realiteten i spillutvikling er at det er så mange bevegelige deler og så mange ubevegelige begrensninger at noen problemer er nødt til å slippe gjennom sprekkene, og oddsen for det bare øker ettersom spillene blir større og større. Sanchez mener dette er grunnen til at vi må se på lanseringer som disse helhetlig. Et spills ytelse på lanseringsdagen er viktig, men det er ikke alt.

'Det er ikke problemene, de kommer alltid til å skje,' sier Sanchez. «Det er hvordan du adresserer disse problemene. Hvis du er treg eller ikke adresserer dem ordentlig, eller hvis du er fiendtlig mot spillerne dine, kommer det til å holde med dem. Hvis det er én ting jeg skulle ønske spillere ville forstå, så er det at problemer skjer uansett hvor godt du planlegger for dem. Du bør holde utviklere ansvarlige for hvordan de blir svart på. Hvis du har et problem en uke etter lanseringen, legg føttene til ilden og si 'Hei, jeg har ikke en god opplevelse, det er derfor jeg er bekymret for at disse problemene ikke er løst.' Det er de tingene vi ønsker å høre om.'

Problemer oppstår uansett hvor godt du planlegger for dem.

Frank Sanchez

Ingen spill starter perfekt. Det skjer bare ikke. Som Sanchez uttrykker det, 'alt du vil vurdere som en jevn lansering er bare noe som aldri steg til nivået der en spiller oppfattet at noe var galt.' Det foregår alltid rabalder bak kulissene. Mann beskrev det som en gjeng med utviklere som holdt seg sammen i et 'krigsrom' og så på en vegg av skjermer for tilbakemeldinger og potensielle problemer. Noen ganger oppdager de disse problemene tidlig, noen ganger dukker de ikke opp på noen timer, og noen ganger kan de ikke fikses på noen flere timer eller til og med noen dager.

Poenget er at massive nettspill alltid vil ha noen tekniske problemer ved lansering. Helvete, alle moderne spill har noen problemer ved lansering. Det er bare naturen til dagens teknologi og dagens industri. Det betyr ikke at spillere blindt skal gi et pass til spill som blir presset ut med katastrofal design eller andre problemer, men det setter den gjennomsnittlige lanseringen i perspektiv. Et spill kan ha mindre problemer vi ikke engang legger merke til, eller det kan ha åpenbare spillbrytere. Uansett, alt noen kan gjøre er å håpe på det beste, forberede seg på det verste, og kalle ut problemer når de uunngåelig dukker opp.