In questa lezione parliamo ancora di bilanciamento. Ora che abbiamo definito le meccaniche del gioco e come queste interagiscono fra loro, non rimane che bilanciarle numericamente. Vedremo quindi alcune tecniche utili per rendere il gioco interessante, e far sì che lo rimanga a lungo nel tempo.
Complessità e bilanciamento di sistemi
Nelle prime fasi di sviluppo di un gioco ci si troverà spesso a cercare di bilanciare il sistema che definisce tutto il gameplay. Quando parliamo di sistema, parliamo delle relazioni fra le meccaniche:
- i controlli;
- come l'avatar del giocatore risponde ai comandi;
- come il mondo di gioco risponde alle azioni del giocatore.
La complessità di questi sistemi varia molto, si va dal semplice click per compiere un'azione (come nei giochi di carte), a giochi complessi dove anche un singolo movimento del giocatore è governato da 3-4 parametri. Di solito se mettete le mani nella programmazione, sarà necessario assegnare dei valori alle variabili che gestiscono le meccaniche.
Facciamo un rapido esempio di complessità in un gioco relativamente semplice: si pensi ad esempio ad un salto in un gioco d'azione. La quantità del salto è determinata da una spinta, identificata con una variabile. Tuttavia a questa si potrebbe aggiungere il peso del personaggio (non sempre, solo se il sistema di fisica lo supporta).
Ancora, durante il salto potrebbe entrare in gioco l'attrito con l'aria (spesso chiamato drag nei physics engine, che modifica non solo l'altezza ma anche la lunghezza del salto) ed ovviamente la gravità, che influenza quanto rapidamente il corpo viene richiamato al suolo. Tutti questi fattori interagiscono fra loro, rendendo difficile il bilanciamento.
Metodi pratici per il bilanciamento dei numeri
Per aiutarci nel bilanciamento dei numeri che sono dietro le meccaniche, possiamo attingere da una serie di metodi pratici:
Definire bene il problema
Un problema di bilanciamento può dipendere da diversi fattori, ed è facile saltare subito a conclusioni modificando uno di essi senza aver analizzato dove è più giusto andare ad agire.
Proseguendo nell'esempio di prima, modificare il drag influenza l'attrito non solo in aria, ma anche in fase di movimento a terra. Ma attenzione: siamo sicuri che il problema sia il salto, e non gli ostacoli/fossi che sono troppo grandi...?
Cercate di guardare il problema da tutti i punti di vista prima di fare modifiche ad un sistema complesso, e di indovinare che effetti possano avere eventuali cambi.
Duplicare e dimezzare i valori
Quando si lavora con variabili dai valori numerici, effettuare cambi minimi è spesso inutile. Invece, raddoppiare o dimezzare il valore durante i test, permette di arrivare prima alla soluzione.
Ad esempio, se la spinta di un salto è impostata su 100 e vi sembra troppo forte, invece di abbassare il valore a 90-95, provate direttamente 50. Sarà sicuramente troppo poco, ma vi darà un'idea più chiara del valore da usare nel prossimo test. Quando effettuare un test richiede molto tempo (per problemi di compilazione, o perché bisogna provare il gioco su un device), è fondamentale ottimizzare ed arrivare al risultato perfetto nel minor numero di tentativi.
In quest'ottica, succede spesso di fare modifiche minuscole a numeri di sistemi complessi (nell'esempio di prima, supponiamo di andare da 100 a 98, poi 96, poi 90…) e pensare che il cambio sia stato troppo minimo. Solo dopo diversi tentativi arriveremo a cambiare il numero di molto (70, 60), rendendoci conto che cambiare quella variabile… non ha effetto! Caso tipico: il valore del salto sembra troppo basso ed il personaggio non si stacca da terra, ma in realtà il pulsante del salto non è stato collegato all'azione!
Modificando di incrementi grandi, l'errore sarebbe saltato subito all'occhio: se non avviene nessun cambiamento, vuol dire che c'è qualcosa che non va alla base.
Documentare tutto
è buona pratica annotare come le diverse variabili interagiscono fra loro. Questo aiuta a fare chiarezza nei vostri pensieri, e ad affinare il funzionamento del vostro sistema di gioco.
Fare aggiustamenti al modello, non solo al bilanciamento!
Mentre cercate di bilanciare le meccaniche che sostengono il vostro modello di gioco, non fatevi domande solo sul ‘quanto', ma continuate a mettere in dubbio anche il ‘come'. Le regole che avete stabilito all'inizio non sono dei dogmi, se cambiandole migliora tutto il gioco, non fatevi problemi.
Prepararsi dall'inizio a fare del bilanciamento
Nessun gioco nasce perfetto, sapete già che prima o poi dovrete dare una ripassata ai controlli o al sistema di gioco e bilanciare tutte le variabili. Per questo motivo, fate in modo che il gioco sia facilmente aggiustabile. Esempio stupido: in un gioco di corse, aggiungere un tasto che rimetta l'auto in posizione al centro della pista, con velocità a zero, danni a zero, ecc., pronta per un nuovo giro. Vi sorprenderà scoprire quante volte vengono sviluppati giochi in cui lo sviluppatore deve fermare il gioco e rilanciarlo (e magari "buildare" di nuovo) per fare un altro test che duri 10 secondi.
Non usare i giocatori
Non pensiate che i giocatori possano aiutarvi nel bilanciamento del sistema di gioco. I giocatori vogliono un gioco che li sfidi, ma al tempo stesso vogliono vincere. è probabile che se lasciate che i giocatori decidano il bilanciamento del gioco, tenderanno a produrre un sistema in cui loro (ovvero i loro avatar) sono favoriti rispetto all'ambiente (nemici, trappole, etc.).
I giocatori potranno tornare utili durante la fase di playtesting (ne parleremo più avanti), ma per ora il compito di bilanciare il gioco - almeno inizialmente - spetta al designer.
Livello di sfida: la teoria del Flow
Una volta passato lo step della progettazione del sistema, vediamo come rendere interessanti le sfide che abbiamo ideato. Quando spendiamo tempo nel regolare la difficoltà di un gioco e delle sue sfide, lo facciamo con un unico scopo: fornire al giocatore una sfida che possa essere superata, ma non con facilità.
Affinché un giocatore si presti a giocare a lungo, dobbiamo cercare di catturare la sua attenzione, e mantenerla viva. Per fare ciò dobbiamo fornire un quantitativo di sfide la cui difficoltà è bilanciata con il suo livello di bravura, al fine di tenere il giocatore in uno stato di concentrazione/interesse.
Questo stato di concentrazione viene in generale chiamato 'Flow', ed è un concetto conosciuto e non esclusivo del mondo dei videogiochi. Vediamo uno schema:
Se poniamo il livello di difficoltà delle sfide durante un gioco sull'asse verticale Y, e il tempo di gioco (e quindi l'aumentare delle skill del giocatore) sull'asse orizzontale, al centro possiamo definire un canale ideale per cui se riusciamo a tenere il giocatore al suo interno, questi sarà nel giusto stato d'animo e continuerà a giocare con piacere.
Se alziamo troppo (o troppo presto) il livello di sfida, il giocatore andrà nella posizione A3, ovvero inizierà a sentire una sensazione di ansia dovuta al livello di difficoltà troppo alto per le sue skill. Se, al contrario, le sfide sono troppo facili, il giocatore finirà nella posizione A2, ovvero si annoierà.
Idealmente, dovremmo fornire sfide proporzionate al livello di bravura del giocatore, per fare in modo che la sua posizione in quel grafico passi direttamente da A1 ad A4.
Le posizioni del giocatore nel canale del Flow dovranno seguire una progressione del genere:
Tuttavia, pur facendo così, il giocatore potrebbe leggere una progressione fissa nel modo in cui la difficoltà cresce in relazione alla sua bravura, ed annoiarsi. Per evitare ciò, si può cercare di variare la sfida e le ricompense per creare un grafico leggermente diverso, dove la progressione non è lineare ma segue dei cicli (di sfida, e di relax, di sfida e di relax, …), più o meno lunghi. Ad esempio:
In questo grafico, le parti più piatte (ovvero i momenti in cui il giocatore aumenta le proprie skill senza che la sfida cresca) sono le più noiose (tipico scenario: i tutorial). Man mano che il giocatore migliora, la sfida cresce. C'è un momento in cui la sfida cresce fino diventare quasi insormontabile (come nel caso di un boss), ed a seguire viene fornito al giocatore una grossa ricompensa.
Esempio pratico
In un gioco d'azione, il giocatore è chiamato a superare il tutorial come prima sfida. In questo momento non sa niente del gioco: anche imparare i controlli è una sfida in sé per sé, quindi gli vengono presentati dei bersagli che non possono ferirlo. In questo momento il livello di sfida tende ad essere più basso del livello di bravura (pur questo essendo prossimo allo zero), proprio per introdurre il giocatore.
A seguito del completamento del tutorial, il giocatore viene immesso nel livello 1, poi il 2, ecc. mentre le sue skill crescono di conseguenza (ovvero acquisisce manualità con i controlli). Arrivato al livello 5, affronta un boss molto forte, per cui il livello di sfida supera il suo livello di bravura. Dovrà probabilmente provare a sconfiggere il boss più di una volta, prima che il suo livello di skill superi di nuovo quello della difficoltà. Quando ci riesce, viene ricompensato con un'arma nuova, che rende i livelli 6, 7, 8 molto semplici, dandogli il tempo di rilassarsi e 'giocare' con la sua ricompensa, finché il rapporto difficoltà/bravura non tende di nuovo ad impennarsi nei livelli 9 e 10, dove affronterà un nuovo boss che lo porterà sull'orlo dello stress.
Bilanciamento dinamico della difficoltà
Ora che sappiamo a che livello vogliamo impostare la difficoltà delle sfide in ogni dato momento del gioco, come facciamo a portarla effettivamente al livello giusto? Alcuni designer, nel tempo, hanno cercato di aggirare questo problema implementando un sistema dinamico di bilanciamento della difficoltà.
Piuttosto che fare playtesting di tutte le sfide nel gioco con giocatori di diverso livello di bravura, gli sviluppatori implementano delle sfide che non hanno un livello di difficoltà intrinseco ma si aggiustano dinamicamente al livello di bravura del giocatore. In poche parole, più il giocatore è bravo, più il gioco diventa difficile; mentre al contrario più perde, più diventa facile.
Per quanto sembri la soluzione ideale a tutti i problemi, questo approccio presenta alcune problematiche inattese:
- Rovina il realismo del mondo di gioco. I giocatori vogliono credere che il mondo di gioco - per quanto fantastico - sia qualcosa di 'reale', di cui loro sono parte. Un mondo di gioco la cui difficoltà si adatta al giocatore è un mondo giocatore-centrico, poco credibile. I giocatori vogliono sentire che esistono delle sfide, e che se le superano è solo perché sono diventati bravi, non perché il mondo di gioco si è piegato al loro livello.
- È facile imbrogliare. Quando un giocatore si accorge di come funziona il sistema, può facilmente sovvertire le regole e giocare volontariamente male per ottenere un'esperienza di gioco facilitata, annullando quindi lo scopo del sistema automatico stesso.
- I giocatori migliorano con la pratica. Un sistema del genere assume che il giocatore non migliori mai, e quindi si piega al suo livello. In realtà, parte del gioco è fallire le sfide un certo numero di volte, per migliorare e finalmente superarle. Questo genere di sistema auto-bilanciante elimina involontariamente questa parte fondamentale del processo di gioco.
Finora, un sistema fatto ad hoc (quindi con sfide a difficoltà fissa), per quanto non accontenti tutti i giocatori, si è rivelato essere quello che comunque dà più soddisfazioni alla maggioranza degli utenti. Detto questo, i sistemi di difficoltà dinamica non sono da scartare a priori, ma bisogna fare attenzione a non cadere nelle trappole di cui sopra.
