Mellem den splittede lancering af Anthem er overraskende lanceringen af Apex Legends, og den kommende lancering af Division 2, begyndelsen af 2019 stablet med store onlinespil. Som BioWares seneste og utallige spil før det har vist, starter multiplayer spil af dette omfang sjældent i en strålende tilstand. Det lader til, at alle online spil har nogle tekniske problemer ved lancering, uanset om de er mindre, som den ugentlige fejl i Apex Legends, eller spillespærere, som forbindelsesproblemer, der oprindeligt svækkede Diablo 3.
Vi har haft urolige lanceringer, så længe vi har haft onlinespil, men det føles som om samtalen omkring lanceringsproblemer ikke rigtig er gået overalt. Vi ser de samme spørgsmål op hver gang. Hvorfor skete dette? Hvorfor forudså udviklerne ikke dette? Hvorfor tog det så lang tid at ordne? Med så mange store online-spil, der frigives så tæt sammen, med fremkomsten af Games som en service i branchen, syntes det nu som en god tid at bringe nogle af disse spørgsmål til udviklere i håb om at afmystificere den frygtede lanceringsdag nedetid. Hvorfor fortsætter vi med at se de samme problemer, når spil lanceres, og hvordan håndterer udviklere dem?
“Kapacitet er meget sjældent problemet”
Når spil går ned eller er langsomme at forbinde, antager mange, at det er fordi de løb tør for serverplads. At udviklerne undervurderede, hvor mange spillere der ville logge ind, og som følge heraf bukkede deres servere under belastningen. I så fald er alt hvad de skal gøre, betale for flere servere, ikke? Nå nej, ikke nødvendigvis; som det ofte er tilfældet ved at lave spil, er det ikke så simpelt.
“Et af de tanker, du ser online meget, er, hvorfor har ikke firma A fået flere servere?” Alex Mann, udviklingschef og tidligere QA-analytiker hos EA, fortæller os. “Ved lanceringen ser du den største trafikmængde på disse spil. Alle er blevet hyped, marketing teamet har gjort deres arbejde godt, alle er meget spændte på at komme online, og det øjeblik, hvor spillet poppper alle, der klikker ‘Go’. Men du vil bemærke med de fleste spiles livscyklus, du har denne massive burst og så falder den af. Hvis hvert spil firma derude købte hardware til at dække alt, hvad de havde brug for inden for den første burst, havde de to uger senere 50% af deres hardware sidder der aldrig brugt. ”
“Det handler ikke om” Lad os smide masser af penge på det og gøre det større. “”
Alex Mann
Dette gør det vanskeligt for udviklerne at forberede sig til lancering uden overforbrug og køb for mange servere. Heldigvis har devs nu adgang til virtuelle servere gennem virksomheder som Amazon Web Services, og disse kan aktiveres eller deaktiveres efter behov. Disse servere blev også nødvendige, da spil skiftedes væk fra peer-to-peer-forbindelserne – den type, der understøttede spil som Halo 2 tilbage i 2004 – til dedikerede servere, der opretholder massive, vedholdende spil som Destiny 2 og Anthem. Imidlertid er virtuelle servere ikke en mirakelhærdning, og de har egne problemer.
“Kapaciteten handler ikke nødvendigvis om antallet af servere,” siger Mann. “Selvom vi forventer millioner af spillere, og vi har serverne, forventer vi ikke dem alle at ramme denne login portal på samme tid. Det handler om at have nok baner på motorvejen for at folk skal komme igennem. Jeg har to lande tilsluttet via bro, og begge lande har masser af plads på dem, men for at flytte fra klientlandet til serverlandet, hvor stort laver du broen? Det handler ikke om ‘lad os smide masser af penge på det og gøre det større. ‘ I slutningen af dagen er det ofte en flaskehals baseret på den teknologi og motor, du bruger. ”
Almindelige misforståelser
En misforståelse, som Mann ofte ser, har at gøre med, hvordan udviklingsholdene fungerer – specifikt ideen om at nogen kan løse noget.
“Når du beskæftiger dig med komplekse kodebaser, der spænder over flere filer, der er bygget af 200 mennesker, hvis jeg kigger på mine kodere, og de har bygget dette, kender coder A ikke hele projektet,” forklarer han. “Der er dette koncept, at alle ved alt om spilletekoden, så niveauet kunstneren skal være med til at rette op på niveauarkitekturen. Du ved, at community managers ikke løser fejl.”
Jeg hørte det samme fra Fredrik Brönjemark, direktør for live-tjenester hos Massive Entertainment, studiet bag Divisionen. “Store onlinespil er ekstremt komplekse softwarestykker, der stole på en massiv online-serverinfrastruktur til at understøtte det,” forklarer BrÖnjemark. “Derudover har du også det ekstra lag af førstepartstjenester, så der er mange forskellige måder, ting kan gå galt! For os på Divisionen kunne de vigtigste typer af hændelser, der kunne forårsage nedetid eller forbindelsesproblemer, være ustabilitet i spilsoftwaren, der kører på serverne eller udbyderproblemer. Det er sjældent problemet at løbe ud af serverkapacitet. På Division 2 scaler vores servere automatisk afhængigt af antallet af spillere, der ønsker at spille spillet. ”
Et vilkårligt antal ting kan gå galt på lanceringsdagen, og oftere end ikke er den rene antal spillere relativt lav på urlisten. Der kan være en hukommelseslækage, en enkelt men katastrofal linje med forkert kode, eller en plet af lag begravet et eller andet sted i den enorme server pipeline. Et spil kan have et problem med en bestemt internetudbyder, eller som BrÖnjemark nævnte, kan de første-party-tjenester, som et spil stoler på, gå ned. Problemet kan være overalt, men uanset hvor det er, er det alles problem. Ingen er en ø, når det kommer til onlinespil, og det kan gøre svar på problemer utroligt vanskelige og tidskrævende.
“Hver lancering er anderledes”
Alle udviklere, jeg talte med, beskrev en lignende triage-proces til løsning af problemer. Mann gav et overblik over, hvordan en løsning kan se ud fra start til slut. For det første skal en udvikler sive gennem symptomerne på problemet for at identificere den egentlige årsag. Så kommer de ind i de mennesker, der er ansvarlige for dette område af spillet for at finde ud af en løsning. Er det noget, de kan opdatere på deres side, eller skal de udstede en patch? Når de har fundet en løsning, skal de teste det for at sikre, at det ikke bryder noget andet, især hvis det er en patch.
“Der er en check, før noget går live,” siger Mann. “Der er mange tilbage og tilbage med platformholdere [som Sony og Microsoft] for at sikre, at vi arbejder sammen for at få succes sammen, vi skal gennemgå QA-trin. Og da vi går igennem denne patch, hvis vi knækroppe reagerer og løser dette nu, men så en halv time senere skal vi lave en anden patch samme dag, det bliver et rod. Så vi må sige: “Vi laver denne patch; hvilke andre kritiske problemer kan vi løse som led i dette? Hvilke andre ting er der galt? Du kan ikke bare lave en lappe om en halv time. Du skal sørge for at være smart med, hvordan du laver det indhold. “
Når alt er gjort, kan universiteterne, hvis universet tillader det, skubbe patchen igennem og begynde at overvåge det og kommunikere dets effekter via deres sociale kanaler. Men “der er ikke en halv times vending,” siger Mann og tilføjer, “der er måske hundredvis af mennesker der vil røre ved det, før det går ud.”
Frank Sanchez, en tidligere BioWare og Gazillion Entertainment community repræsentant med ingeniør erfaring, kender dette paradigme godt. Som en, der har brugt meget tid på at samle svar og udarbejde patch noter, har han set begge sider af opdateringsprocessen, fra afspiller feedback til patch indsendelse. Han ved også bedre end de fleste, hvordan komplicerede løsninger kan blive, og hvor frustrerende lanceringsproblemer kan være for både spillere og udviklere.
“Vi er de sidste folk, der ønsker at se en server gå op og så to timer senere, så dårligt kan folk ikke logge ind,” forklarer Sanchez. “Jeg garanterer dig, hvis [udviklerne] bringer en server op til en beta, og det virker ikke rigtigt, det er sandsynligvis i haleenden af en person, der sætter tid ud over, hvad de allerede crunching for at få det til en tilstand, hvor den kunne starte, så når nogen online er som ‘Nå er de bare doven’, det er helt og blatant falsk. Arbejdet sættes i, udfordringen er hvordan man skal reagere på problemer og kommunikere til spillerne, når de sker. ufuldkommen videnskab … hver lancering er anderledes. Selvom to spil er udviklet på Unity eller hvad som helst, selvom genren er den samme, er processen anderledes. Du kan ikke sige ‘Dette spil var fint, hvad er problemet med dette spil, “fordi der er meget unikke for hvert spil.”
Du kan ikke sige ‘Dette spil var fint, hvad er problemet med dette spil’, fordi der er meget unikke for hvert spil.
Frank Sanchez
Sanchez ‘kommentarer berører et andet almindeligt spørgsmål, der opstår omkring lanceringstiden: Hvorfor forventer du ikke dette? Måske spillede X i problemer for nogle måneder siden. Sikkert udviklerne af spil Y kunne se det og træffe foranstaltninger for at undgå de samme problemer, ikke?
Forskelle i individuelle spil til side, alle jeg talte med sagde, at nogle problemer ikke kan forventes. Intern test kan kun gøre så meget, og det kan aldrig virkelig sammenlignes med faktisk at starte et spil.
“Der er bare ingen simulering for live”
“Du kan ikke planlægge for live [samtidige spillere],” fortsætter Sanchez. “Det er bare umuligt. Der er ingen erstatning. Jeg har set hver metode til stressprøvning noget internt, før du sætter det derude, og der er bare ingen simulering for live.”
Det er her, hvor stresstest og beta-perioder påbegyndes. De er ikke perfekte, men de er den bedste måde at måle, hvordan et spil lancerer vil se ud og hvad der skal løses før prime time. “Betas er massivt hjælpsomme,” siger Mann. “Du kan ikke få den størrelse og skala, du gør med en beta-test internt. Du kan bare ikke ansætte, at mange mennesker rammer dine servere. Den bedste måde at teste live på er at være levende. Hvis du ser på mange alphas og betas, der er dette koncept, at der ikke er nok servere, at der er fejl og andre problemer, men inden for en uge har de trieret, og den seneste eller endelige udgivelse har ikke disse problemer. Det er kun fordi det har oplevet [live ] og undersøgt under disse betas. “
“For nylig løb et studie en beta for sit spil, og en flok venner sprang i spænding til at spille, og de ramte en fejl, hvor de sidder fast i vejledningen, fordi et nøgleelement ikke har hentet i serveren” Mann fortæller mig og noterer mig, hvor vanskeligt det kan være at forudse fejl i en online-spil-lancering. “Jeg garanterer i alle QA-testene på dette spil, at varen altid var der. Den eneste måde, du vil finde på, er ved at teste denne strøm i massiv skala. Jeg formoder, at disse fyre nu er klar over det og over alt det problem at få det fast til lancering, alt på grund af det beta arbejde. ”
Du kan ikke rette alt
Hvis betas er så gode, hvorfor ikke udviklere holde mere af dem, og hvorfor ikke holde dem måneder før lanceringen? Som det ofte er tilfældet i spil, giver teknologi og tid ikke altid devs, hvad de vil gøre. På grund af den måde, hvorpå de fleste spil er lavet, kommer de ikke sammen til helt i slutningen, hvilket generelt er grunden til, at betas vises så tæt på lanceringen. Og uanset hvilke devs lære af en beta, uanset hvilke problemer det kan afsløre, kan de ikke realistisk forsinke deres spil som svar på dem. En webudbyder ønsker ikke et hold at savne sin startdato for serveren, end en udgiver ønsker at savne deres startdato. Det er derfor, ligesom nogle problemer ikke kan forventes, kan nogle fejl ikke rettes rettidigt til lancering.
Division 2 Betas
Division 2 beta-skemaet var ret omfattende, med private og åbne betas samt en mere målrettet stress test. Ikke alle spil kan svinge det, men dem der gør det uhyre godt af, hvad BrÖnjemark kalder “den sidste prøve”. Dens første åbne beta er planlagt til 1.-4. Marts, to uger ud fra lanceringen.
“Jeg ville elske at sende uden fejl,” mener Sanchez, en kommentar, du hører fra enhver udvikler, der har gået igennem helvede og tilbage til faktisk at sende et produkt. “Men noget hold vil fortælle dig det er meget svært at gøre. Det er bare virkeligheden af det. Listen over ting, der skal løses, ændrer sig stadig. Du skal forstå, at når det kommer til fejl, er der fejl, der er potentielt afsendt, og der er opdaget fejl efter lanceringen. Alt det skal prioriteres og planlægges imod og talte om. Det er triage. De heldigere lanceringer er dem, der har fejl, men har ikke forkrøbende bugs. ”
Derudover kan det være en lang og arbejdskrævende opgave at lave en beta-bygning. Udviklere kan ikke bare hakke et stykke af deres spil og uploade det til Xbox Live eller PlayStation Network. Betas udvikles ofte adskilt fra (men i tandem med) et spil, der tager mere tid og penge. Derfor er problemer, der længe siden er blevet rettet i hovedbygningen af et spil, stadigvæk til stede i dets beta. Vi så dette i Anthems demoer og i den seneste beta for Division 2, for eksempel.
“Sædvanligvis hører jeg folk, der siger, at de tror, at beta-tests kun er marketingkampagner, og udviklerne kan ikke lære noget fra dem alligevel, da spillet allerede er færdigt på det tidspunkt,” fortæller BrÖnjemark. “Jeg vil gerne ødelægge den myte. Selv når spillet allerede er trykt på disken, og dagen-en patch allerede er færdig, er der stadig en enorm mængde ting, som vi kan adressere server-side, både i termer af tech men også hvad angår gameplay og balance. “
På bagsiden siger Sanchez, at “udgivelsesskemaer og spiludviklingstidslinjer er meget aggressive, nogle gange for aggressive. Hvornår sker der noget, hvor meget finansiering har du forladt, hvor længe har du været i udvikling. Nogle gange er succesen med at lancere virkelig afhænger af hvor mange gange du har skubbet dine milepæle, hvor mange gange har du forsinket lanceringen, fordi du havde noget at polere. Nogle spil kan kun sendes med en vis mængde polsk. Du kan ikke sige det er helt og helt fint, når det går guld. Der er tilfælde, hvor et spil vil skibes i en tilstand, der er startsklar, men der kan være en smule polsk, der skal gøres. ”
En lancering er mere end dag et
Udviklere og spillere vil begge have deres spil til at fungere perfekt første gang de brænder dem op, men virkeligheden af spiludvikling er, at der er så mange bevægelige dele og så mange faste begrænsninger, at nogle problemer er bundet til at glide gennem revnerne og odds for det kun stigning som spil bliver større og større. Sanchez mener det er derfor, vi skal se på lanceringer som disse holistisk. Et spil præstation på lanceringsdagen er vigtigt, men det er ikke alt.
“Det er ikke problemerne, det kommer altid til at ske,” siger Sanchez. “Det er hvordan du løser disse problemer. Hvis du er langsom eller du ikke adresserer dem ordentligt, eller hvis du er fjendtlig over for dine spillere, vil det holde fast ved dem. Hvis der er en ting, jeg ønsker spillere ville forstå, er det at problemer opstår uanset hvor godt du planlægger for dem. Du bør holde udviklere ansvarlige for, hvordan de bliver reageret. Hvis du har et problem om ugen i lanceringen, skal du sætte dine fødder i ilden og sige ‘Hej, jeg er ikke har en god oplevelse, det er derfor, jeg er bekymret over, at disse problemer ikke er løst. ‘ Det er de ting, vi vil høre om. ”
Der opstår problemer uanset hvor godt du planlægger dem.
Frank Sanchez
Intet spil starter perfekt. Det sker bare ikke. Som Sanchez lægger det til, “alt hvad du overvejer at være en glat lancering er bare noget, der aldrig steg op til det niveau, hvor en spiller opfattede noget, der var forkert.” Der er altid scrambling foregår bag kulisserne. Mann beskrev det som en flok udviklere sammenblandet i et “krigsrum”, der så på en væg af skærme til tilbagemelding og potentielle problemer. Nogle gange tager de disse problemer tidligt, nogle gange opstår de ikke i et par timer, og nogle gange kan de ikke repareres i nogle få timer eller endda nogle få dage.
Pointen er, massive onlinespil vil altid have nogle tekniske problemer ved lanceringen. Helvete, alle moderne spil har nogle problemer ved lanceringen. Det er bare naturen i dagens teknologi og dagens industri. Det betyder ikke, at spillerne blindt skal give et spil til spil, der skubbes ud med katastrofalt design eller andre problemer, men det sætter den gennemsnitlige lancering i perspektiv. Et spil kan have mindre problemer vi ikke engang bemærker, eller det kan have indlysende game-breakers. Under alle omstændigheder kan alle, som alle kan gøre, håbe på det bedste, forberede sig på det værste, og løse problemer, når de uundgåeligt overflader.