Rieccoci con una nuova edizione di "Tra le Corsie", una rubrica del blog in cui i membri del nostro team di sviluppo raccontano nel dettaglio alcune delle sfide, dei bug da risolvere e delle fortunate coincidenze in cui ci imbattiamo mentre lavoriamo a un gioco unico come Dota.

L'evento di Crownfall è stato così imponente che abbiamo avuto l'opportunità di fare un sacco di esperimenti: mappe della regione, trame ramificate, gettoni a tema Eroi, minigiochi, fumetti, pixel art e altre idee che non vedevamo l'ora di esplorare da anni.

Ciò che ci ha dato la fiducia necessaria per correre questi rischi (ed è un vantaggio di cui godiamo sempre in Valve) è stata la libertà di iterare: raccogliere dati reali sui giocatori, lasciare che mettessero in discussione le nostre ipotesi e persino farci cambiare idea. Diciamo sempre che non comprendiamo appieno ciò che stiamo costruendo finché non vediamo i giocatori interagire con esso. Quindi cerchiamo di arrivare a quella fase il più rapidamente possibile.

Questa mentalità influenza anche il processo decisionale, spesso il più tardi possibile nella fase di sviluppo, quando abbiamo i dati migliori (e a volte gli unici). In ogni fase, attingiamo alle esperienze reali dei giocatori per concentrarci su ciò che funziona ed evitare il resto.

In questa edizione di Tra le Corsie, daremo un'occhiata al processo di sviluppo di un minigioco che è stato pubblicato online piuttosto tardi in Crownfall: la battaglia dell'Atto IV tra i nostri Eroi e la Regina Imperia nel suo Nido di Spine. Lo useremo anche come caso di studio per mostrare come i test di gioco e i dati che generano influenzino il nostro processo decisionale.


Il primo (e unico) minigioco dell'Atto I era una modesta battuta di pesca in cui Tidehunter metteva alla prova le tue abilità nella speranza di accaparrarsi la colazione. In effetti, è così che abbiamo affrontato l'Atto I: tante piccole idee sparse per la mappa per valutare la reazione dei giocatori. I dati incoraggianti dei giocatori dell'Atto I ci hanno dato la fiducia necessaria per passare all'Atto II, e nell'Atto III abbiamo lanciato Sleet Fighter, un minigioco nella taverna preferita di Tusk; Scacchi del drago, una battaglia a tre contro Winter Wyvern; e Tana di Zaug, uno sparatutto che mette un drago malvagio contro Vengeful Spirit attraverso i tortuosi tunnel sotterranei del Deserto di Ghiaccio.

Quando abbiamo raggiunto l'Atto IV, avevamo un'idea ben precisa di cosa avrebbe funzionato e cosa no. Sulla base di quali dati? Da dettagli concreti (quanti giocatori hanno riavviato i minigiochi e con quale frequenza) a dati più soggettivi, come i feedback inviati dalla Comunità e le discussioni online. Questa chiarezza ci ha dato la sicurezza necessaria per lanciarci in un finale mozzafiato: un'epica battaglia contro la malvagia Regina Imperia.

Naturalmente, decidere che tipo di meccaniche di gioco adottare per una battaglia di questo tipo non è stata una passeggiata. Sapevamo che le aspettative erano alte e che dovevamo mettere in scena uno spettacolo degno di questo nome. Allo stesso tempo doveva offrire abbastanza varietà e rigiocabilità da rimanere divertente anche dopo diverse sessioni. Trattandosi di un minigioco progettato per essere giocato in attesa di una partita, doveva essere intenso ma breve. Per intenderci, come una merenda veloce e non un pranzo luculliano.

Per trovare il giusto equilibrio, avevamo bisogno di un genere che combinasse l'alta qualità di produzione di Sleet Fighter con la rigiocabilità di Scacchi del drago. Dopo tutto, si trattava di uno scontro epico tra Vengeful Spirit, Skywrath Mage, il nuovo arrivato Kez ("i magnifici tre" dei quattro atti di Crownfall) e la Regina Imperia, nel cuore stesso del suo castello. Volevamo che il giocatore sentisse di dover affrontare ostacoli impossibili nel tentativo di raggiungere la regina.


L'idea di una battaglia a turni in stile GDR giapponese ci era passata per la testa, ma non ci abbiamo messo molto a capire che non era la soluzione migliore. Avevamo bisogno di qualcosa che catapultasse rapidamente i giocatori nel vivo dell'azione, che fosse breve, intenso e abbastanza divertente da intrattenerli tra una partita di Dota e l'altra.

È qui che entra in gioco il genere dei "sopravvissuti". L'idea di un "inferno di proiettili inverso" con ondate infinite di nemici era il genere ideale per una battaglia epica ad alto rischio. Il giocatore avrebbe dovuto farsi strada tra le orde agguerrite, usando un po' di strategia per migliorare le sue abilità e prepararsi allo scontro finale con Imperia. Tutto quello che dovevamo fare era ispirarci agli oggetti e alle abilità già presenti in Dota e far sapere ai giocatori cosa aspettarsi.

Poiché volevamo che l'esperienza fosse relativamente breve, un altro pezzo importante del puzzle era la rigiocabilità. Grazie alla sua intrinseca variabilità, un gioco di sopravvivenza promette di essere sempre diverso. I giocatori non possono mai sapere quando o in quale ordine un oggetto sarà disponibile o quando si attiverà un evento. La variabilità incoraggia a continuare a provare, partendo da zero in un modo da sembrare impegnativo ma senza risultare insormontabile o frustrante. L'obiettivo non era quello di avere successo al primo tentativo, ma non doveva nemmeno essere fonte di scoraggiamento.


I primi prototipi del Nido di Spine presentavano già gli stessi elementi di base della versione finale. Un giocatore sceglieva uno dei tre Eroi, combatteva ondate di nemici e alla fine raggiungeva la Regina Imperia. Il problema era che questi primi tentativi non erano neanche lontanamente divertenti. A volte, un Eroe vagava in una mappa quasi vuota prima di imbattersi in un povero scheletro. Altre volte, le ondate di nemici erano così schiaccianti che era impossibile vincere (o almeno così pensavamo, ma ne parleremo più avanti). Eravamo comunque certi che, da qualche parte, il gioco avesse anche del potenziale. Abbiamo dovuto continuare a torturare i giocatori che stavano testando build fallimentari finché non abbiamo trovato quella ideale.

I dipendenti di Valve sono tutti cavie e fare provare loro una build è il modo in cui capiamo se qualcosa funziona (o, altrettanto spesso, non funziona). Possiamo fare riunioni infinite, ma a meno che qualcuno non si sieda e giochi, non abbiamo modo di sapere se le scelte che abbiamo fatto siano quelle giuste.

Nelle prime versioni, sopravvivere ai primi 3-6 minuti non era un'impresa da poco. In generale, questo è un indicatore che il gioco è sbilanciato o che non spiega correttamente le sue regole. Abbiamo poi chiesto di descriverci la loro esperienza: c'erano momenti in cui non sapevano come muoversi, o c'erano così tanti nemici che la sfida sembrava impossibile, oppure il gioco diventava semplicemente noioso. Siamo poi tornati alle nostre scrivanie per apportare alcune modifiche prima di far testare la build a nuovi giocatori. A poco a poco, abbiamo cominciato a vedere dei progressi.

E poi, qualcosa di inaspettato è accaduto.

Dopo averci descritto la sua prima partita, un playtester che aveva appena perso ci ha domandato: "Posso riprovare?".

Non era mai successo prima ed è stato incoraggiante. Il Nido di Spine era ancora lontano anni luce dall'essere un buon minigioco. Di solito ci volevano almeno tre tentativi prima che qualcuno capisse come vincere. Ma almeno non dovevamo più costringere i nostri colleghi a giocare al nostro prototipo del cavolo. Questa volta, le cavie stesse si sono offerte di provare il prototipo del cavolo! Abbiamo percepito un piccolo barlume di interesse che si è tradotto in: "Ho visto di peggio". Abbiamo apprezzato il commento.

Ma non era ancora il momento di gridare: "eureka"!


Uno degli aspetti caratteristici del genere "sopravvissuti" che mancava nelle nostre prime versioni era la pressione costante. All'inizio, evocavamo un'ondata di centinaia di scheletri nel livello e lasciavamo l'Eroe a ripulire il tutto. Una volta eliminati gli scheletri, una nuova ondata di cattivi più potenti prendeva il loro posto. I giocatori si annoiavano in fretta. Quando ci si rende conto che l'unico obiettivo è uccidere i cattivi, il gioco diventa rapidamente una noia mortale. L'unica ricompensa per aver eliminato un'ondata di nemici era la promessa di un'altra ondata più agguerrita. (Evviva?)

Alla fine abbiamo capito che quando generavamo cento scheletri e l'Eroe iniziava a colpirli, dovevamo impostare un timer per quell'ondata e continuare ad aumentarne il numero, indipendentemente da quanti ne avesse uccisi l'Eroe. Quando il timer raggiungeva lo zero, aggiungevamo una nuova ondata di nemici ancora più forti e un nuovo timer. Così facendo, la pressione non si è mai allentata e i giocatori restavano coinvolti.

Soprattutto era cambiato l'obiettivo del gioco. Quando i nostri Eroi erano impegnati a massacrare un numero sempre più esiguo di scheletri, l'obiettivo era quello di “far arrivare il numero di scheletri a zero”. Ma se il numero di scheletri non diminuisce mai, indipendentemente dal numero di vittime, non passerà molto tempo prima che i giocatori si rendano conto che ucciderli non è davvero l'obiettivo.

Invece, è quello che si ottiene uccidendo tutti quegli scheletri che conta; in altre parole, abilità e miglioramenti. Improvvisamente, l'obiettivo non era più "Uccidere tutti gli scheletri", ma "Quanti ne posso uccidere il più velocemente possibile per diventare più potente possibile?". Invece di essere un compito noioso, decimare ondate di nemici iniziava a sembrare una gara per raggiungere il montepremi, in cui ogni nemico ucciso era un altro passo verso il raggiungimento della build perfetta.

Poiché il passaggio all'ondata successiva non era più legato all'eliminazione dell'ondata precedente, abbiamo aggiunto un nuovo elemento: un orologio condiviso. Di conseguenza, tutti condividevano lo stesso ritmo e sapevano esattamente quando le cose si sarebbero fatte difficili. Quindi quando un giocatore esclamava: "Non sopporto quell'ondata di ragni al quarto minuto", tutti sapevano esattamente a cosa si riferisse (quei ragni sono terribili).

Finalmente avevamo capito come fare divertire i giocatori. Questo piccolo cambiamento del punto di vista ci ha permesso di capire cosa piacesse alle persone e perché, e ha portato a una cascata di nuove idee: miglioramenti più potenti, abilità sempre più devastanti e possibilità di build che non avevamo nemmeno considerato. I playtester potevano sperimentare la creazione di build di Eroi uniche, anche all'interno della stessa partita. Di conseguenza, i test di gioco sono diventati più efficienti e abbiamo ricevuto feedback e suggerimenti migliori da applicare alla prossima build.

Anche se abbiamo dovuto insistere un po'. Dopo un test di gioco, a volte i nostri colleghi non volevano più parlare dei punti da migliorare, ma cercavano di convincersi a vicenda che la loro build fosse la migliore.

Anche se la varietà delle build continuava a crescere, abbiamo iniziato a domandarci se avessimo trascurato un pezzo importante del puzzle: e se gli stessi Eroi fossero diventati unici come le loro abilità? Nei primi prototipi, a parte l'abilità di partenza, l'esperienza di gioco era relativamente simile, indipendentemente dall'Eroe scelto. Abbiamo quindi deciso di modificarli per rendere la scelta del personaggio più decisiva: uno sarebbe stato più forte, l'altro più veloce e l'altro ancora avrebbe inflitto più danni magici, aumentando ulteriormente la variabilità delle build. La scelta di un Eroe rispetto ad un altro ha poi aperto rami specifici di abilità che altrimenti non avrebbero potuto essere sviluppati, e poiché c'era sempre un pizzico di fortuna nel decidere quali potenziamenti fossero disponibili per il giocatore, ogni scelta sembrava una scommessa ad alto rischio.



Mentre i giocatori si distraggono pensando a quali potenziamenti potrebbero portarli a Imperia, noi lentamente aumentiamo la difficoltà. A un certo punto, senza preavviso, le ondate di nemici diventano mortali e il ritmo è così frenetico che è un'impresa mantenere la testa fuori dall'acqua.

Almeno, questo era l'obiettivo. Con i miglioramenti apportati, il ritmo del gioco ha continuato ad accelerare. Volevamo che l'esperienza fosse intensa, senza diventare impossibile. (Sapevamo che il minigioco avrebbe fornito intrattenimento durante l'attesa di una partita). D'altra parte, volevamo che ci fosse abbastanza spazio di manovra per permettere ai giocatori di godersi i miglioramenti man mano che si accumulavano.

Facendo due calcoli, il minigioco dovrebbe richiedere circa dodici minuti per essere completato, senza contare i tre minuti finali di combattimento contro Imperia. Abbiamo poi stabilito il ritmo da adottare per i primi sei minuti. Con quale frequenza proporre un nuovo miglioramento? A che punto si può iniziare ad accumulare abilità? Quanto danno dovrebbe fare ogni abilità in modo da risultare soddisfacente ma non eccessivamente potente?

Affinando il gameplay sezione per sezione, concentrandosi sui primi sei minuti, gli ultimi sei minuti erano diventati praticamente ingiocabili. Lasciavamo che i playtester giocassero per i primi sei minuti e poi li fermavamo. Tecnicamente avrebbero potuto continuare a giocare, ma dal sesto minuto in poi era ancora tutto in divenire. Non si poteva giocare oltre quel punto. (In realtà abbiamo implorato i nostri colleghi di non farlo).

Uno degli effetti collaterali più spassosi del rendere le abilità e i miglioramenti così divertenti è stato che spesso ai playtester non importava che metà del gioco fosse ancora ingiocabile. Ci sedevamo alla scrivania di un collega e lo guardavamo giocare fino a metà, poi, al sesto minuto, gli dicevamo:

"Fantastico, grazie!". "Puoi ricominciare da capo?"

Una pausa.

"Aspetta un attimo, credo di poter vincere".

Abbiamo poi ricordato loro che gli ultimi sei minuti erano un pasticcio pieno di nemici copia-incolla impossibili da sconfiggere. Dicevano di aver capito. Abbiamo poi domandato cosa ne pensassero e abbiamo ricevuto una serie di commenti interessanti sulla loro esperienza di gioco nei primi sei minuti. Così tornavamo alle nostre scrivanie, loro aspettavano che ci allontanassimo e poi riprendevano il gioco per cercare di vincere comunque.

Alcuni dei nostri colleghi hanno preso come un affronto personale il fatto di non essere riusciti a superare gli ultimi sei minuti, ferocemente ingiusti e letteralmente impossibili da vincere. Quindi, mentre noi progettavamo la prima metà del gioco, loro univano le loro risorse per affrontare a testa alta l'imbattibile seconda metà.

E neanche a dirlo: ce l'hanno fatta.

Hanno finito per trovare combinazioni precise di abilità con superpoteri che non avevamo ancora perfezionato e hanno completato la parte del gioco che pensavamo fosse impossibile. (Il che la dice lunga sulla progettazione dei videogiochi, ma forse ancora di più sul tipo di persone che vi si dedicano).


Alla fine dello sviluppo, il nucleo del gioco era pronto. Le abilità, le battaglie con i miniboss e lo scontro finale contro la Regina Imperia... tutto questo era perfetto. A questo punto, non eravamo più alla ricerca di bug che potessero compromettere il gioco, ma di modi per regolare, bilanciare e perfezionare ciò che già funzionava. I test di gioco sono continuati, ma abbiamo interrotto le interviste approfondite post-mortem e abbiamo lasciato che le persone giocassero solo per divertimento (e, naturalmente, per generare più dati).

Se i dati quantitativi di ogni tentativo erano importanti, lo erano anche i dati qualitativi dei test di gioco. In un esempio memorabile, un test di gioco si è concluso in modo epico quando La Massa del Pianto (che internamente chiamavamo "Polpetta") ha occupato più della metà dello schermo prima di divorare il giocatore, cosa che ha suscitato grande ilarità tra i colleghi che si erano fermati a guardarlo. Ovviamente, il playtester ha subito premuto il pulsante "Gioca ancora".

Finalmente avevamo un prodotto che valeva la pena pubblicare. Dopo essere stati disponibili solo per le persone che si erano offerte volontarie, i test di gioco erano ora aperti a chiunque nei nostri uffici fosse disposto a farsi convincere a provarli. Durante lo sviluppo dei primi prototipi non era raro ricevere un messaggio su Slack alle 23:00 che diceva: "Il gioco è troppo difficile".
In questa fase, continuavamo a ricevere questo tipo di messaggi alle 23:00, ma con un messaggio successivo alle 03:00 del mattino che diceva: "Come non detto, sono arrivato alla fine".

Anche se il minigioco era quasi finito, abbiamo continuato a lavorare al Nido di Spine fino all'uscita dell'Atto IV di Crownfall. All'inizio di questo post, abbiamo ricordato l'importanza di raccogliere dati affidabili, essenziali per prendere le decisioni giuste. Bene, ora ne avevamo alcuni: con il team interno che effettuava i test così entusiasta di giocare (e rigiocare) al minigioco, avevamo un sacco di dati per sapere quali parti di ciò che avevamo creato avessero successo. E non c'è niente di più emozionante per uno sviluppatore di videogiochi del momento in cui un gioco inizia a essere divertente. Volevamo investire ancora di più in questi aspetti, che finalmente si erano dimostrati validi, e includere il maggior numero possibile di elementi. Nuovi oggetti, nuove abilità, nuovi dialoghi e persino nuove ondate: ogni volta che pensavamo di aver finito il gioco, qualcuno inevitabilmente se ne usciva con un'altra ideuzza. E poiché in generale si trattava di una buona idea, non potevamo non approvarla.

Le idee non solo continuavano ad arrivare, ma miglioravano sempre di più man mano che ci si avvicinava al rilascio. All'inizio del progetto, quando era tutto poco definito, era difficile distinguere tra una funzionalità con un grande potenziale e una meno interessante. A una settimana dal rilascio, era chiaro su quali aspetti del gioco investire risorse e tempo per migliorarlo.


Mentre stavamo apportando gli ultimi ritocchi al Nido di Spine, abbiamo potuto fare un passo indietro e guardarlo con occhi nuovi. La posta in gioco era alta in quanto dovevamo applicare le lezioni apprese dagli atti precedenti per creare una battaglia che fosse abbastanza epica da concludere un evento su larga scala. Il risultato dei nostri sforzi è stato più che soddisfacente, dati i tempi ristretti. Il gioco era divertente.

Ma purtroppo la Comunità non lo sapeva ancora. Quello a cui non avevamo pensato era che, essendo il Nido di Spine una battaglia con una regina, avrebbe dovuto logicamente svolgersi nella sala del trono, proprio alla fine dell'ultimo atto. Ciò significava almeno un giorno o due di silenziosa tortura, mentre aspettavamo che i professionisti di Dota arrivassero alla fine dell'Atto IV alla velocità della luce, in attesa di vedere quando i giocatori avrebbero finalmente avuto la possibilità di giocarci.

Per fortuna non abbiamo dovuto aspettare così tanto. Pensavamo di avere almeno un giorno o due prima che qualcuno raggiungesse la sala del trono della Regina Imperia. Non avevamo considerato la velocità vertiginosa con cui i giocatori di Dota possono divorare i contenuti. Appena sedici ore dopo il lancio, sì, 16 ore, alcuni giocatori avevano combattuto per superare l'atto finale e stavano tentando di conquistare il Nido di Spine per la prima volta.

E alla fine, tutti sono riusciti a scontrarsi con Imperia. Al momento della stesura di questo post, il Nido di Spine è stato giocato quasi cento milioni di volte. Se non hai ancora tentato la fortuna, o se vuoi semplicemente fare un altro tentativo, il minigioco è ancora disponibile negli archivi di Crownfall, dal client di gioco.


Speriamo che questo sguardo dietro le quinte su come il team di Dota crea un minigioco ti abbia dato un'idea più precisa di come lavoriamo, e che non ti abbiamo spaventato rivelandoti che improvvisiamo sempre. Questo dimostra che la progettazione di videogiochi non è un'arte mistica impiegata da geni creativi che si incontrano in stanze buie, ma un processo iterativo di prove ed errori guidato da dati, ansia, test di gioco, fallimenti, altri test di gioco, altri fallimenti e così via.

Lo sviluppo di un gioco si basa sull'iterazione: tutto inizia "senza un'idea", che lentamente si trasforma in "un'idea vaga", motivata da idee passate che avevano funzionato. Poi si trasforma in un prototipo scadente, quello con cui nessuno vuole giocare ma che noi realizziamo comunque. Osserviamo i playtester mentre non si divertono a giocare e andiamo a sistemare tutte le parti noiose, finché alla fine capiamo che la gente si sta divertendo davvero. Poi arriva il momento di mettere a punto i minimi dettagli, con gli occhi puntati sulla fatidica data di uscita, che si avvicina senza pietà. La filosofia di Valve è sempre stata quella di accettare l'incertezza e lasciare che siano i dati a guidare lo sviluppo. Forse non riusciamo sempre a consegnare i nostri prodotti in tempo, ma siamo convinti che ti piaceranno quando saranno pronti.