Avendo appena superato il lancio di Dragonflight, volevamo prenderci un momento per discutere degli avvenimenti di questi giorni dal punto di vista della progettazione. Speriamo, così facendo, di fornire qualche informazione in più riguardo ai dietro le quinte di un simile lancio su scala globale, cosa può non andare secondo i piani, quali inconvenienti possono esserci e come li gestiamo.
Internamente, definiamo gli avvenimenti come quello di lunedì scorso “lancio dei contenuti”, perché la pubblicazione di un’espansione è un processo graduale, non immediato. World of Warcraft è ben lontano dall’essere il gioco statico di diciotto anni fa o persino di due anni fa; è un gioco in costante crescita e soggetto a cambiamenti così come i nostri processi di pubblicazione.
Le espansioni ora sono composte da diverse pubblicazioni minori: prima viene pubblicato il codice applicandolo ai contenuti esistenti, poi gli eventi pre-lancio e i nuovi sistemi, e finalmente il lancio dei contenuti, nuove aree, missioni e spedizioni. Ciascuna fase cambia parti diverse, così da permetterci di individuare e risolvere i problemi. Ma in ogni sistema ampio e complesso possono verificarsi situazioni inaspettate.
Un cambiamento, con questa espansione, è stato il lancio dei contenuti avviato tramite un evento a tempo. Varie modifiche al gioco possono essere attivate per accadere contemporaneamente in un momento specifico. Introdurre manualmente questi cambiamenti permetterebbe il rischio di un errore umano, o di un problema tecnico interno o esterno. L’evento a tempo aiuta a mitigare questi rischi.
Un altro cambiamento di Dragonflight è il supporto migliorato per criptare i registri dati di gioco. I registri criptati ci permettono di rendere disponibile il nostro client con i dati di cui il gioco necessita per mostrare filmati, ascoltare dialoghi o sbloccare missioni, proteggendoli al contempo dall’essere estratti prima che i giocatori possano vederli in gioco. Sappiamo che la community ama WoW e che quando si vuole ardentemente qualcosa di nuovo è difficile resistere alla tentazione e non rovinarsi la sorpresa. I registri criptati ci permettono di prendere parti fondamentali della storia e nasconderle dai giocatori fino al momento giusto.
Abbiamo ora scoperto che la lag e l’instabilità viste nella scorsa settimana erano causate dal modo in cui i due sistemi interagiscono. Come risultato, forzavano il server della simulazione (che muove i personaggi nel mondo esplorabile e permette di usare incantesimi o abilità) a ricalcolare quali registri andassero nascosti più di cento volte al secondo per ciascuna simulazione. Dato che una grossa porzione della CPU veniva usata per questi calcoli, le simulazioni diventavano lente e le richieste dagli altri servizi verso i server delle simulazioni si accumulavano. I giocatori e le giocatrici vedevano questi come lag o errori tipo “Server del mondo di gioco non disponibile”.
Come abbiamo scoperto, i registri criptati, sino all’introduzione dello sblocco tramite evento a tempo, lasciavano uno spiraglio per un errore logico nel codice: una linea di codice nel posto sbagliato segnalava al server che era necessario ricalcolare quali registri nascondere, anche se nulla era cambiato.
Ecco alcuni dettagli sul processo di identificazione dell’errore. Primo, l’orologio batte le 15:00 PST. Sappiamo dai test che arriva prima lo zeppelin dell’Orda e poi la nave dell’Alleanza. Molti di noi, connessi in gioco sui nostri personaggi, sono seduti ad aspettare in entrambi i porti su una finestra del computer, mentre osservano grafici e registri o pannelli di controllo su altre finestre. Siamo anche in una chiamata di gruppo con i membri dei team di supporto di tutta Blizzard.
Prima del lancio, abbiamo creato piani di emergenza per le situazioni che più preoccupanti rilevate in seguito ai test. Per esempio, i nostri progettisti e le nostre progettiste avevano creato dei portali che i giocatori e le giocatrici avrebbero potuto usare per raggiungere le Isole dei Draghi in caso il trasporto non funzionasse.
Alle 15:02 arriva puntuale lo zeppelin dell’Orda. Urrà! I giocatori e le giocatrici salgono a bordo, tra cui alcuni impiegati e alcune impiegate Blizzard. Altri impiegati e altre impiegate aspettano (vogliono essere coloro che testeranno i portali in caso siano necessari). I giocatori e le giocatrici sullo zeppelin partono e, anche se alcuni e alcune arrivano alle Isole dei Draghi, molte persone vengono disconnesse o finiscono bloccate.
Immediatamente esaminiamo i registri e i pannelli di controllo. Ci sono alcuni giocatori e giocatrici sulla mappa delle Isole dei Draghi, ma non molti. I membri che hanno avuto problemi ci comunicano i nomi e reami dei loro personaggi da usare come esempi specifici. Altri iniziano a riportare picchi nel carico della CPU e nel NFS (file system di rete) usato dai nostri server. Altre persone ancora stanno osservando e riferendo cosa succede in gioco.
Ora che abbiamo visto gli zeppelin dell’Orda, aspettiamo l’arrivo della nave dell’Alleanza. La maggior parte non arriva, e la maggior parte degli zeppelin dell’Orda non ritorna.
Emerge un fatto: gli zeppelin sono incastrati e i server delle Isole dei Draghi stanno impiegando molto più tempo del previsto a funzionare. Qui abbiamo iniziato a scavare più a fondo per iniziare a risolvere i problemi.[Text Wrapping Break][Text Wrapping Break]Gli zeppelin hanno dato problemi in passato, quindi abilitiamo i portali mentre cerchiamo una soluzione. Il nostro NFS è chiaramente sovraccarico. C’è una lunga coda di rete sul servizio responsabile per la coordinazione dei server della simulazione, facendogli credere che le simulazioni non siano state avviate, causando quindi ulteriori avvii e sovraccaricando il nostro hardware. Presto scopriamo che aggiungere i portali ha peggiorato il sovraccarico, poiché i giocatori e le giocatrici possono cliccare ripetutamente sui portali, quindi li disattiviamo.
Col persistere dei problemi, lavoriamo sul ridurre il sovraccarico per permettere al maggior numero di giocatori e giocatrici possibile di giocare, ma il servizio non si sta comportando come nei test pre-lancio. Continuiamo a cercare una soluzione al problema per escludere ciò che non ne è la causa in base ai nostri test.
Nonostante fosse tardo pomeriggio, molte persone continuano a lavorare mentre altre vanno a casa per poter tornare la mattina presto il giorno dopo e ricominciare a mente fresca, lasciando riposare chi è rimasto.
Entro martedì mattina, abbiamo compreso meglio la situazione. Sappiamo che stiamo inviando più messaggi del solito ai client riguardo alle missioni, anche se abbiamo scoperto dopo che non era questo a causare problemi. Un nuovo file di archiviazione API che stiamo usando sta impattando l’archiviazione dei file più del solito. Alcune nuove linee di codice aggiunte perché i committenti attirino i giocatori sembrano più lente del necessario. Il servizio sta richiedendo un tempo molto lungo per inviare ai client tutti i cambiamenti di dati fatti negli hotfix. Stiamo ricevendo rapporti di giocatori e giocatrici che hanno raggiunto le Isole dei Draghi e stanno riscontrando estrema lag.
A metà mattina di martedì, per coincidenza, scavando a fondo nel nuovo codice scritto per i committenti, troviamo gli agganci al nuovo sistema di criptazione. Iniziamo ad analizzare la questione dal lato opposto: possibile che il sistema di criptazione rallentato spieghi questi e gli altri problemi che stiamo riscontrando? Risposta: sì. La lentezza del sistema di criptazione spiega il problema degli hotfix, il problema dell’archiviazione dei file e la lag in gioco. Una volta identificata la fonte, chi ha creato la parte di sistema rilevante ha potuto identificare l’errore e applicare la dovuta correzione.
Rilasciare una soluzione per una parte di codice usata in così tanti servizi non è una cosa immediata, e il nuovo codice va rilasciato e attivato. Dobbiamo spostare lentamente i giocatori e le giocatrici dalle vecchie simulazioni a quelle nuove perché la correzione funzioni. Anzi, a un certo punto abbiamo tentato di spostare i giocatori e le giocatrici troppo velocemente, causando problemi a un’altra parte del servizio. Alcuni dei codici affetti non potevano essere corretti senza un riavvio del servizio, che abbiamo posticipato fino a quando c’erano solo poche persone connesse, per non disturbare chi era in gioco. Entro mercoledì, la soluzione era completamente integrata e la stabilità dei servizi era migliorata esponenzialmente.
Anche se ci è voluto molto impegno per identificare e risolvere il problema, il nostro team è stato incredibilmente attento nell’investigare, risolvendolo il più rapidamente possibile. Progettare bene i software non significa non fare mai errori, ma minimizzare le possibilità di farne, identificarli rapidamente quando si verificano e avere le capacità di trovare una soluzione velocemente…
…e avere un team incredibile con cui collaborare perché fili tutto liscio.[Text Wrapping Break]
-Team di progettazione di World of Warcraft