'Het is gewoon onmogelijk': ontwikkelaars leggen uit waarom grote online games altijd lijken te breken bij de lancering

Tussen de gefragmenteerde lancering van Hymne , de verrassende lancering van Apex Legends en de aanstaande lancering van De Divisie 2 , begin 2019 zit boordevol grote online games. Zoals de nieuwste en talloze games van BioWare hebben aangetoond, worden multiplayer-games van deze omvang zelden in een briljante staat gelanceerd. Het lijkt alsof elke online game heeft sommige technische problemen bij de lancering, of het nu kleine problemen zijn, zoals de bugs van de eerste week in Apex Legends, of spelbrekers, zoals de verbindingsproblemen die aanvankelijk verlamden Duivel 3 .

We hebben moeilijke lanceringen gehad zolang we online games hebben gehad, maar het voelt alsof het gesprek over lanceringsproblemen nergens heen is gegaan. We zien elke keer dezelfde vragen opduiken. Waarom is dit gebeurd? Waarom hebben de ontwikkelaars hier niet op geanticipeerd? Waarom duurde het zo lang om te repareren? Met zoveel grote online games die zo dicht bij elkaar worden uitgebracht, met de opkomst van Games as a Service in de industrie, leek het nu een goed moment om een ​​aantal van deze vragen aan ontwikkelaars te stellen in de hoop de gevreesde uitvaltijd van de lanceringsdag te demystificeren. Waarom blijven we dezelfde problemen zien wanneer games worden gelanceerd, en hoe gaan ontwikkelaars ermee om?

'Capaciteit is zelden het probleem'

Wanneer games uitvallen of traag zijn om verbinding te maken, gaan velen ervan uit dat dit komt omdat ze geen serverruimte meer hebben. Dat de ontwikkelaars onderschatten hoeveel spelers zouden inloggen en als gevolg daarvan bezweek hun servers onder de druk. In dat geval hoeven ze alleen maar te betalen voor meer servers, toch? Nou, nee, niet noodzakelijk; zoals vaak het geval is bij het maken van games, is het niet zo eenvoudig.

'Een van de denkrichtingen die je veel online ziet, is: 'Waarom heeft bedrijf A niet meer servers?'', vertelt Alex Mann, ontwikkelingsmanager en voormalig QA-analist bij EA. 'Bij de lancering zie je het meeste verkeer op deze games. Iedereen is gehyped, het marketingteam heeft zijn werk goed gedaan, iedereen is erg enthousiast om online te gaan en op het moment dat de game uitkomt, klikt iedereen op 'Go'. Maar je zult merken dat met de levenscyclus van de meeste games, je een enorme uitbarsting hebt en dan stopt het. Als elk gamesbedrijf de hardware zou kopen om alles te dekken wat ze nodig hadden binnen die eerste burst, zouden ze twee weken later 50% van hun hardware daar nooit gebruikt hebben.'

'Dat gaat niet over 'Laten we er bakken met geld tegenaan gooien en het groter maken'.

Alex Mann

Dit maakt het moeilijk voor ontwikkelaars om zich voor te bereiden op de lancering zonder te veel geld uit te geven en te kopen te veel servers. Gelukkig hebben ontwikkelaars nu toegang tot virtuele servers via bedrijven zoals Amazon Web Services, en deze kunnen indien nodig worden geactiveerd of gedeactiveerd. Dit soort servers werd ook noodzakelijk toen games verschoven van de peer-to-peer-verbindingen – het type dat games als Halo 2 in 2004 ondersteunde – naar dedicated servers die enorme, hardnekkige games ondersteunen, zoals Lot 2 en volkslied. Virtuele servers zijn echter geen wondermiddel en hebben hun eigen problemen.

'Capaciteit gaat niet per se over het aantal servers', zegt Mann. 'Zelfs als we miljoenen spelers verwachten en we hebben de servers, we verwachten niet dat ze allemaal tegelijkertijd dat inlogportaal zullen bereiken. Het gaat erom dat er voldoende rijstroken op de snelweg zijn om mensen door te laten. Je hebt twee landen die via een bridge met elkaar zijn verbonden, en beide landen hebben heel veel ruimte, maar om van het klantland naar het serverland te gaan, hoe groot maak je die brug? Dat gaat niet over 'Laten we er bakken met geld tegenaan gooien en het groter maken.' Uiteindelijk is het vaak een bottleneck vanwege de technologie en engine die je gebruikt.'

Veel voorkomende misvattingen

Een misvatting die Mann vaak ziet, heeft te maken met de manier waarop ontwikkelingsteams werken, met name het idee dat iedereen alles kan repareren.

'Als je te maken hebt met complexe codebases die meerdere bestanden omvatten die door 200 mensen zijn gebouwd, als ik naar mijn programmeurs kijk en ze hebben dit gebouwd, dan kent coder A dat hele project niet', legt hij uit. 'Er is een concept dat iedereen alles weet over de spelcode, dus de levelartiest zou moeten helpen met de oplossing voor de levelarchitectuur. Weet je, communitymanagers lossen geen bugs op.'

Ik hoorde hetzelfde van Fredrik Brönjemark, directeur van live services bij Massive Entertainment, de studio achter The Division. 'Grote online games zijn extreem complexe stukjes software, die afhankelijk zijn van een enorme online serverinfrastructuur om dit te ondersteunen', legt Brönjemark uit. 'Bovendien heb je nog de extra laag first party services, dus er zijn veel verschillende manieren waarop het mis kan gaan! Voor ons op The Division waren de belangrijkste soorten incidenten die downtime of verbindingsproblemen konden veroorzaken instabiliteit in de spelsoftware die op de servers draaide, of problemen met de hostingprovider. Een tekort aan servercapaciteit is zelden het probleem. Op The Division 2 schalen onze servers automatisch, afhankelijk van het aantal spelers dat de game wil spelen.'

Er kan van alles misgaan op de lanceringsdag, en vaker wel dan niet, staat het pure aantal spelers relatief laag op de wachtlijst. Er kan een geheugenlek zijn, een enkele maar catastrofale regel onjuiste code of een lag ergens begraven in de enorme serverpijplijn. Een game kan een probleem hebben met een bepaalde ISP, of, zoals Brönjemark al zei, de first-party services waarop een game vertrouwt, kunnen uitvallen. Het probleem kan overal zijn, maar waar het ook is, het is het probleem van iedereen. Niemand is een eiland als het gaat om online games, en dat kan het reageren op problemen ongelooflijk moeilijk en tijdrovend maken.

'Elke lancering is anders'

Alle ontwikkelaars die ik sprak, beschreven een soortgelijk triageproces voor het oplossen van problemen. Mann bood een overzicht van hoe een oplossing er van begin tot eind uit zou kunnen zien. Eerst moet een ontwikkelaar de symptomen van het probleem doorzoeken om de werkelijke oorzaak te achterhalen. Vervolgens halen ze de mensen binnen die verantwoordelijk zijn voor dat deel van het spel om een ​​oplossing uit te werken. Is het iets dat ze aan hun kant kunnen updaten, of moeten ze een patch uitgeven? Zodra ze een oplossing hebben gevonden, moeten ze deze testen om er zeker van te zijn dat er niets anders kapot gaat, vooral als het een patch is.

'Er is een controle voordat er iets live gaat', zegt Mann. 'Er is veel heen en weer met platformhouders [zoals Sony en Microsoft] om ervoor te zorgen dat we samen naar succes werken; we moeten de QA-stappen doorlopen. En terwijl we door die patch gaan, als we met een ruk reageren en dit nu repareren, maar dan een half uur later een tweede patch op dezelfde dag moeten doen, wordt het een puinhoop. Dus we moeten zeggen: 'We doen deze patch; welke andere kritieke problemen kunnen we als onderdeel hiervan oplossen? Wat is er nog meer aan de hand?' Een patch maak je niet zomaar in een half uur. Je moet ervoor zorgen dat je slim bent met hoe je die inhoud patcht.'

Als dat allemaal is gebeurd, kunnen de ontwikkelaars, als het universum het toelaat, de patch doordrukken en beginnen met het monitoren en communiceren van de effecten ervan via hun sociale kanalen. Maar 'er is geen half uur omdraaien', zegt Mann, eraan toevoegend, 'er zijn misschien honderden mensen die dat zullen aanraken voordat het uitgaat.'

Frank Sanchez, een voormalig vertegenwoordiger van de BioWare en Gazillion Entertainment-gemeenschap met technische ervaring, kent dit paradigma goed. Als iemand die veel tijd heeft besteed aan het verzamelen van reacties en het opstellen van patch-notities, heeft hij beide kanten van het updateproces gezien, van feedback van spelers tot het indienen van patches. Hij weet ook als geen ander hoe ingewikkeld reparaties kunnen worden en hoe frustrerend de opstartproblemen kunnen zijn voor zowel spelers als ontwikkelaars.

'Wij zijn de laatste mensen die een server omhoog willen zien gaan en twee uur later zo erg achterblijven dat mensen niet kunnen inloggen', legt Sanchez uit. 'Ik garandeer je dat als [de ontwikkelaars] een server aanbieden voor een bèta en het niet goed werkt, dat waarschijnlijk aan het einde is van iemand die meer tijd heeft gestoken dan wat ze al aan het kraken waren om het in een staat te krijgen waarin het kon lanceren. Dus als iemand online zegt: 'Nou, ze zijn gewoon lui', dan is dat volledig en flagrant onjuist. Het werk is erin gestoken, de uitdaging is hoe te reageren op problemen en te communiceren met spelers wanneer ze zich voordoen. Het is een onvolmaakte wetenschap … elke lancering is anders. Zelfs als twee games zijn ontwikkeld op Unity of wat dan ook, zelfs als het genre hetzelfde is, is het proces anders. Je kunt niet zeggen 'Dit spel was prima, wat is het probleem met dit spel', want elke game heeft veel eigenheid.'

Je kunt niet zeggen 'Dit spel was prima, wat is het probleem met dit spel', want elke game heeft veel eigenheid.

Frank Sanchez

De opmerkingen van Sanchez raken aan een andere veelvoorkomende vraag die rond de lanceringstijd opduikt: waarom had je dit niet voorzien? Misschien kwam game X een paar maanden geleden in de problemen. De ontwikkelaars van game Y zouden dat toch kunnen zien en maatregelen nemen om diezelfde problemen te voorkomen, toch?

Afgezien van de verschillen in afzonderlijke games, zei iedereen die ik sprak dat sommige problemen niet kunnen worden voorzien. Interne tests kunnen alleen zoveel doen, en het kan nooit echt worden vergeleken met het daadwerkelijk lanceren van een game.

'Er is gewoon geen simulatie voor live'

'Je kunt niet plannen voor live [gelijktijdige spelers]', vervolgt Sanchez. 'Het is gewoon onmogelijk. Er is geen vervanger. Ik heb elke methode gezien om iets intern te stresstesten voordat je het naar buiten bracht, en er is gewoon geen simulatie voor live.'

Dit is waar pre-launch stresstests en bètaperiodes in het spel komen. Ze zijn niet perfect, maar ze zijn de beste manier om te meten hoe de lancering van een game eruit zal zien en wat er moet worden opgelost voor prime time. 'Bèta's zijn enorm nuttig', zegt Mann. 'De grootte en schaal die je met een bètatest intern krijgt, krijg je niet. Je kunt gewoon niet zoveel mensen inhuren om je servers te bezoeken. De beste manier om live te testen is door live te zijn. Als je naar veel alfa's en bèta's kijkt, is er het concept dat er niet genoeg servers zijn, dat er bugs en andere problemen zijn, maar binnen een week hebben ze een triage uitgevoerd en de nieuwste of definitieve release heeft die problemen niet . Dat is alleen maar omdat het tijdens die bèta's [live] is ervaren en onderzocht.'

'Onlangs draaide een studio een bètaversie voor zijn spel en een stel van mijn vrienden sprongen enthousiast in om te spelen, en ze raakten een bug waar ze vast kwamen te zitten in de tutorial omdat een belangrijk item niet op de server is voortgekomen, vertelt Mann. Ik merkte op hoe lastig het kan zijn om te anticiperen op fouten bij het lanceren van een online game. 'Ik garandeer je dat bij alle QA-tests van die game dat item er altijd was. De enige manier om dat te vinden is door deze stroom op grote schaal te testen. Ik vermoed dat die jongens daar nu heel goed van op de hoogte zijn en dat hele probleem om het voor lancering te laten repareren, allemaal vanwege dat bètawerk.'

Je kunt niet alles oplossen

Als bèta's zo geweldig zijn, waarom hebben ontwikkelaars er dan niet meer van, en waarom houden ze ze niet maanden voor de lancering vast? Zoals vaak het geval is in games, laten technologie en tijd ontwikkelaars niet altijd precies doen wat ze willen doen. Vanwege de manier waarop de meeste games zijn gemaakt, komen ze pas aan het einde samen, wat over het algemeen de reden is waarom bèta's zo dicht bij de lancering verschijnen. En ongeacht wat ontwikkelaars leren van een bèta, ongeacht welke problemen het kan onthullen, ze kunnen hun spel niet realistisch vertragen als reactie daarop. Een webserviceprovider wil niet dat een team de startdatum van de server mist, net zo min als een uitgever hun lanceringsdatum wil missen. Dit is de reden waarom, net zoals sommige problemen niet kunnen worden voorzien, sommige bugs niet op tijd voor de lancering kunnen worden verholpen.

The Division 2 bèta's

De Divisie 2 bèta schema was redelijk uitgebreid, met privé- en open bèta's en een meer gerichte stresstest. Niet alle games kunnen dat evenaren, maar degenen die dat wel doen, hebben enorm veel baat bij wat Brönjemark de 'laatste repetitie' noemt. De eerste open bèta is gepland van 1 tot 4 maart, twee weken na de lancering.

'Ik zou graag zonder bugs verzenden', zegt Sanchez, een opmerking die je zult horen van elke ontwikkelaar die door een hel en terug is gegaan om een ​​product daadwerkelijk te verzenden. 'Maar elk team zal je vertellen dat dat heel moeilijk is. Dat is gewoon de realiteit ervan. De lijst met dingen die gerepareerd moeten worden, verandert voortdurend. Je moet begrijpen dat als het om bugs gaat, er bugs zijn die mogelijk worden verzonden en dat er bugs worden ontdekt na de lancering. Dat alles moet worden geprioriteerd en gepland en besproken. Het is triage. De gelukkigere lanceringen zijn degenen die bugs hebben, maar geen verlammende bugs.'

Bovendien kan het maken van een bètaversie een langdurige en arbeidsintensieve taak op zich zijn. Ontwikkelaars kunnen niet zomaar een stukje van hun game hacken en uploaden naar Xbox Live of PlayStation Network. Bèta's worden vaak los van (maar in combinatie met) een game ontwikkeld, wat meer tijd en geld kost. Dit is de reden waarom problemen die al lang zijn opgelost in de hoofdversie van een game, nog steeds aanwezig kunnen zijn in de bètaversie. We zagen dit bijvoorbeeld in de demo's van Anthem en in de nieuwste bèta voor The Division 2.

'Heel vaak hoor ik mensen zeggen dat ze denken dat bètatests alleen maar marketingcampagnes zijn, en dat de ontwikkelaars er toch niets van kunnen leren omdat het spel dan al af is', vertelt Brönjemark. 'Ik wil die mythe graag ontkrachten. Zelfs als de game al op schijf is afgedrukt en de patch voor de eerste dag al klaar is, zijn er nog steeds enorm veel dingen die we aan de serverzijde kunnen aanpakken, zowel qua technologie als qua gameplay en balancering .'

Aan de andere kant, zegt Sanchez, 'zijn publicatieschema's en tijdlijnen voor game-ontwikkeling erg agressief, soms te agressief. Wanneer wordt iets geleverd, hoeveel geld heb je nog over, hoe lang ben je al in ontwikkeling. Soms hangt het succes van de lancering echt af van hoe vaak je je mijlpalen hebt moeten terugdringen, hoe vaak je je lancering hebt uitgesteld omdat je iets moest oppoetsen. Sommige spellen kunnen alleen worden verzonden met een bepaalde hoeveelheid glans. Je kunt niet zeggen dat het helemaal goed is als het eenmaal goud wordt. Er zijn gevallen waarin een game wordt verzonden in een staat die klaar is voor lancering, maar er kan een beetje gepolijst worden.'

Een lancering is meer dan dag één

Ontwikkelaars en spelers willen allebei dat hun games perfect werken de eerste keer dat ze ze opstarten, maar de realiteit van game-ontwikkeling is dat er zoveel bewegende delen en zoveel onwrikbare beperkingen zijn dat sommige problemen onvermijdelijk door de kieren glippen, en de de kans daarop neemt alleen maar toe naarmate games groter en groter worden. Sanchez denkt dat dit de reden is waarom we dergelijke lanceringen holistisch moeten bekijken. De prestaties van een game op de lanceringsdag zijn belangrijk, maar niet alles.

'Het zijn niet de problemen, die zullen altijd gebeuren', zegt Sanchez. 'Zo pak je die problemen aan. Als je traag bent of ze niet goed aanspreekt, of als je vijandig staat tegenover je spelers, zal het bij hen blijven. Als er één ding is waarvan ik zou willen dat spelers het zouden begrijpen, dan is het dat problemen zich voordoen, ongeacht hoe goed je voor hen plant. Je moet ontwikkelaars verantwoordelijk houden voor hoe ze worden beantwoord. Als je een week na je lancering een probleem hebt, zet dan hun voeten in het vuur en zeg: 'Hé, ik heb geen goede ervaring, daarom ben ik bang dat deze problemen niet zijn opgelost.' Dat zijn de dingen waar we over willen horen.'

Problemen gebeuren, ongeacht hoe goed je ze plant.

Frank Sanchez

Geen enkele game start perfect. Het gebeurt gewoon niet. Zoals Sanchez het stelt: 'alles wat je als een soepele lancering zou beschouwen, is gewoon iets dat nooit het niveau bereikte waarop een speler merkte dat er iets mis was.' Achter de schermen wordt er altijd gerommeld. Mann beschreef het als een stel ontwikkelaars die ineengedoken in een 'oorlogskamer' naar een muur van monitoren keken voor feedback en mogelijke problemen. Soms vangen ze die problemen vroeg op, soms komen ze een paar uur niet opdagen en soms kunnen ze nog een paar uur of zelfs een paar dagen niet worden opgelost.

Het punt is dat enorme online games bij de lancering altijd technische problemen zullen hebben. Verdorie, alle moderne games hebben een aantal problemen bij de lancering. Dat is nu eenmaal de aard van de technologie van vandaag en de industrie van vandaag. Dat betekent niet dat spelers blindelings moeten toegeven aan games die met catastrofale ontwerpen of andere problemen naar buiten worden geduwd, maar het plaatst de gemiddelde lancering wel in perspectief. Een game kan kleine problemen hebben die we niet eens opmerken, of er kunnen duidelijke spelbrekers zijn. In ieder geval kan iedereen alleen maar hopen op het beste, zich voorbereiden op het ergste en problemen uitspreken als ze onvermijdelijk aan de oppervlakte komen.