Ok: abbiamo un gioco. Abbiamo definito tutte le sue parti più importanti: abbiamo stabilito chi sono i giocatori, perché giocano e se e come vincono, abbiamo deciso cosa possono fare, come interagiscono fra loro e col gioco, abbiamo descritto com’è strutturato il mondo di gioco e come in esso scorre il tempo, abbiamo stabilito quali sono le fonti d’incertezza. Adesso siamo al momento del primo test, la prima volta in cui il nostro gioco uscirà, seppur per breve tempo, dalla fase “design”, passando in quella del “play”, del giocare. Venendo giocato la prima volta, sarà la prima volta che trasmetterà un’esperienza a qualcuno. Siete un po’ emozionati al pensiero? Io sì, ogni volta. Ma sto correndo troppo: per far fare i primi crash test, alla macchina non bastano motore e ingranaggi, serve anche un minimo di carrozzeria.

Nell’esempio concreto fatto su Vudù ho parlato spesso di “prime versioni” del gioco. Com’è che siamo arrivati, partendo dall’idea iniziale, al prodotto finale? Grazie alla fase di sviluppo. In questa fase, che inizia ufficialmente dopo la prima fase di progettazione vera e propria (quella in cui si definiscono tutte le cose menzionate poc’anzi), costruiremo un prototipo del nostro gioco, lo faremo passare per le forche caudine dei playtest, che ci permetteranno di vedere come il gioco si comporta una volta “messo in moto” e che esperienza fa vivere ai giocatori, e lo modificheremo tramite il bilanciamento per ottenere, alla fine, il risultato che riteniamo ottimale.

Il prototipo

Solitamente faccio una secca distinzione fra due diversi tipi di prototipo: il prototipo di sviluppo e il prototipo da presentazione. Il prototipo di sviluppo potete immaginarlo come quello “da battaglia”, è quello su cui lavorerete la maggior parte del tempo, soprattutto nelle fasi iniziali, mentre quello da presentazione è una specie di ufficiale in alta uniforme: indipendentemente da quali siano i suoi meriti sul campo, anche la forma avrà la sua importanza. Probabilmente passare dall’uno all’altro lo faremo naturalmente, mano a mano che consolideremo le nostre certezze sul corretto funzionamento del nostro gioco.

La prima, importantissima caratteristica che dovrà avere ogni nostro prototipo è la funzionalità. Le informazioni devono essere leggibili, le icone chiare e comprensibili, il flusso di gioco ben organizzato sul tavolo. Questo vale per qualsiasi prototipo, di qualsiasi tipo.

Il prototipo di sviluppo deve essere facilmente modificabile. Potrebbe succederci di metterci le mani più e più volte, per cui è necessario che le modifiche possano essere fatte agevolmente. A meno che non abbiamo i soldi che ci escono dalle orecchie, il che è difficile visto che siamo game designer, sarebbe anche utile che fosse economico, perché ogni volta che cambiamo qualcosa potrebbe essere necessario stampare o realizzare nuovamente parte dei componenti. È difficile, se non impossibile, fornire una “ricetta unica” per i prototipi, perché ogni gioco è diverso e spesso basta un singolo componente “non standard” per costringerci a cercare soluzioni creative per la realizzazione della prima copia giocabile, ma in generale negli anni ho notato che c’è una regola che si adatta particolarmente bene al prototipo di sviluppo: keep it simple.

In generale, per fare delle carte basterà usare delle bustine protettive in cui infileremo una carta qualsiasi a fare da spessore e le nostre carte (fronte e\o retro) stampate su banali fogli A4 e ritagliate. Va benissimo la carta da stampa comune (la famosa “usomano”), quella da 80\90 grammi. Per tessere e altri elementi che idealmente dovrebbero essere fustellati, finché non c’è bisogno di assemblare oggetti complessi o 3D va benissimo usare del cartoncino (150-250 grammi) su cui attaccheremo e nostre stampe usando fogli adesivi o della comodissima colla spray. Sono tutte cose reperibili nelle catene che vendono oggetti per ufficio e cancelleria. Per quanto riguarda i materiali in plastica o legno, come meeple, cubetti o stand up, possiamo “prendere in prestito” pezzi da altri giochi o acquistarli da qualche sito che ne vende, ormai si trovano agevolmente. In generale la regola è: cerchiamo di usare il materiale col miglior rapporto qualità-prezzo, magari riutilizzabile. Questo prototipo verrà visto solo da noi e dai nostri collaboratori più stretti, quindi non preoccupiamoci troppo della sua bellezza estetica; ricordandoci però che la grafica è parte dell’esperienza, la cosa più “agevole” che possiamo fare è cercare qualche immagine per dare un minimo di identità tematica agli elementi del gioco. Va da sé che se invece la parte visiva e grafica sono una parte fondamentale del gameplay, non abbiamo altra scelta che curare questo aspetto fin da subito, pena la perdita di funzionalità del prototipo, che come abbiamo visto è l’ultima cosa che vogliamo.

Il prototipo di presentazione è quello che useremo sia per fare playtest al di fuori della nostra cerchia di collaboratori che per presentarlo agli editori. Questo prototipo ha il compito fondamentale di far capire nel minor tempo possibile a chi abbiamo davanti quella che è la nostra esperienza desiderata, quindi armiamoci di pazienza e cerchiamo di renderlo funzionale in tal senso. C’è stato un periodo in cui ogni autore diceva ai neofiti che un prototipo “non importa che sia bello, importa che funzioni”, che è una frase verissima, solo che dato che lo scopo di questo prototipo è sia trasmettere efficacemente la nostra idea di gioco e l’esperienza che abbiamo in mente, sia venderla a un editore, è superfluo notare come l’essere visivamente accattivante e capace di comunicare la nostra visione diventi istantaneamente una caratteristica fondamentale proprio a livello di funzionalità. Perché, visti gli scopi, se fa schifo al cazzo e non trasmette quel che volevamo, non funziona.

Imparare a usare qualche semplice programma di grafica non è difficile, inoltre internet pullula di risorse di ogni tipo (immagini, sfondi, mappe, applicazioni, tutorial), per cui se potete vi consiglio di spendere qualche ora per la vostra formazione in questo senso, il resto verrà con la pratica: fare dei prototipi gradevoli può essere faticoso, soprattutto all’inizio, ma vi assicuro che si rivelerà estremamente utile. Soprattutto, checché ne dicano alcuni, presentare un prototipo realizzato in modo dozzinale, con le scritte a mano su fogli di carta igenica, non è più considerato lo standard da anni. Se lo facciamo, bene che vada ci prenderanno per degli eccentrici svitati, male che vada ci vedranno come disadattati.

Occorre ricordarsi che il prototipo da presentazione non è necessariamente l’ultimo che fate: potrebbero emergere nuove modifiche da fare e, soprattutto, difficilmente un editore non metterà le mani sul gioco, ma a quel punto probabilmente concorderemo con lui le modalità di realizzazione delle successive versioni del prototipo. Questa precisazione è necessaria a causa di un fenomeno normalissimo con cui potremmo trovarci ad avere a che fare, ossia la tentazione di non fare modifiche necessarie per non dover modificare parte del prototipo, magari mettendo le mani altrove cercando di “martellare” il sistema per farlo funzionare. Spero non ci sia bisogno di dire che in quel caso staremmo facendo, senza tanti giri di parole, una discreta cazzata. È controproducente “affezionarsi” ai prototipi, le modifiche strutturali necessarie vengono sempre prima rispetto a tutto il resto.

I playtest

Per parlare di playtest è necessario introdurre un concetto fondamentale per il game design, quello di design iterativo. Per design iterativo s’intende un procedimento ciclico che prevede una serie di fasi (che vedono alternarsi modifiche, test e analisi) che ha lo scopo migliorare qualità e funzionalità di un prodotto o di un processo. Un’immagine vale più di mille parole, quindi vediamo insieme come funziona.

Applicando il design iterativo al nostro processo di sviluppo, possiamo vedere una prima fase di ideazione, in cui abbiamo avuto l’idea di gioco e abbiamo deciso più o meno il target e il focus dell’esperienza di gioco. Questa fase, secondo il nostro metodo, sfocia naturalmente nella prima fase di progettazione, in cui, seguendo le 5W che abbiamo visto, progettiamo la prima versione del gioco e ne scriviamo il regolamento. Non è importante che il primo regolamento che scriviamo sia “bello da leggere”, serve più che altro a noi per avere chiaro il flusso di gioco, cosa possono o non possono fare i giocatori e che norme seguono i vari elementi del gioco. A questo punto arriviamo al punto in cui ci eravamo fermati, ossia l’implementazione, in cui creiamo il nostro prototipo, il che vuol dire realizzare eventuali file con i materiali da stampare, reperire altri tipi di materiali come pedine, monete o bustine, e assemblare il tutto. A questo punto partiremo coi primi playtest, che sono l’unico modo che abbiamo per vedere se il nostro gioco fa quello che volevamo o per qualche motivo genera dinamiche (ed esperienze) inaspettate.

I primissimi playtest, se il gioco lo permette, sarebbe bene farli da soli. Se il sistema “di base” funziona o meno, infatti, è una cosa che possiamo valutare tramite semplici test in cui giochiamo al gioco “interpretando” in prima persona un numero variabile di giocatori al tavolo. Una volta che siamo ragionevolmente sicuri che il gioco non esploda al primo utilizzo, che non ci siano bug di dimensioni colossali e che il sistema di gioco non sia di una noia mortale, possiamo passare ai playtest veri e propri, da farsi preferibilmente con un gruppo fidato e formato di playtester. Non sto dicendo, ovviamente, che dobbiamo tenere dei “corsi di playtest”, ma semplicemente di identificare uno o più gruppi di persone – solitamente amici – in linea col target del gioco, a cui avremo avuto premura di spiegare che si tratta di un gioco ancora in sviluppo e che quello che ci interessa maggiormente è ricevere una serie di feedback sull’esperienza di gioco. Che decidiamo o meno di prendere parte ai test (soprattutto inizialmente potrebbe essere un’ottima idea), sarà dunque nostra cura non solo cercare di capire se l’esperienza dei giocatori è simile a quella che avevamo ipotizzato, ma dovremmo stare molto attenti a capire se i giocatori sono interessati, divertiti, annoiati o addirittura frustrati. Ovviamente cercheremo di scegliere come tester persone che reputiamo all’altezza del compito, o particolarmente affini al target, e diremo loro di essere sinceri e diretti nell’esprimere le proprie valutazioni, ma anche saper leggere il linguaggio del corpo dei giocatori, le loro espressioni e le loro emozioni è fondamentale: sia che siamo molto bravi a farlo, sia e a maggior ragione se siamo empatici come un condor che non mangia da due giorni, è importante non aver paura di fare domande e di chiedere riscontri rispetto all’esperienza in corso o appena conclusa.

Ovviamente se qualche playtester sente il bisogno di darci suggerimenti saremo aperti, collaborativi e cercheremo di metterci nei panni della persona. Anche se sono cose che avevate già pensato o provato, anche se vi sembrano senza senso, sono feedback e in qualche modo potranno comunque tornare utili: non è questo il momento di essere “protettivi” nei confronti del nostro gioco. Non è facile trovare il giusto mezzo fra fiducia in sé stessi e nelle proprie idee e fiducia negli altri e nella fondatezza delle critiche e dei suggerimenti, ma per fortuna è una capacità che si acquisisce anche e soprattutto con la pratica e interagendo costantemente coi giocatori.

Dopo aver raccolto le impressioni sulla partita (o sulle partite) è giunto il momento di operare una valutazione delle stesse. In questa fase andremo ad analizzare cosa è andato bene, cosa è andato male e cosa è andato così così. Se c’è qualcosa da cambiare, come spesso succede, si torna alla fase di progettazione e si fanno le opportune modifiche al gioco, per poi ripartire con un altro ciclo di implementazione-playtest-valutazione. Prima di vedere in concreto qualche consiglio pratico su come operare in questa fase, però, giova ricordare che questo processo non è in realtà lineare come sembra e, in mezzo, potrebbe infilarsi la presenza di un editore (anzi, diciamo che è il caso ideale).

A un certo punto, la cui “posizione” nel processo di sviluppo può variare a seconda della nostra esperienza, di quanto l’idea sia stata valida fin da subito, o grazie a intuizioni che risolvono eventuali problemi di rilievo, il gioco sarà ancora in lavorazione ma avrà un gameplay ormai definito, e staremo lavorando sui dettagli. Questo, secondo me, è un buon momento per creare il prototipo da presentazione, che ci servirà per far provare il gioco a persone meno conosciute e a eventuali editori. Non è che abbiamo finito, ma siamo in quella fase che molti chiamano late developement o fine tuning, in cui è auspicabile non dover rimettere le mani sulla meccanica principale, lavorando solo sulle secondarie, sui sistemi di progressione e su tutti i piccoli dettagli che arricchiscono l’esperienza di gioco. Come potete immaginare ci sono mille casi possibili che dipendono dalle prassi dei singoli autori ed editori, da come vi trovate meglio a lavorare, da eventuali richieste di un committente: essere razionali, ragionevoli e mentalmente aperti è l’unico “trucco” possibile, perché non è possibile prevedere prima ogni possibile scenario.

Il bilanciamento

Anche in questo caso è difficile stabilire norme generali e universali per tutti i giochi, perché “bilanciare” un gioco dev’essere sempre visto in relazione al target e all’esperienza che vogliamo far vivere a uno o più “tipi” di giocatori. Una regola d’oro però c’è, ed è questa: modificare un solo elemento per volta. Se qualcosa nel gioco non funziona come dovrebbe, il primo tentativo da fare è modificare un singolo elemento (per esempio il costo di un edificio, o l’effetto di un tipo di carte) o un gruppo armonico di elementi (per esempio il sistema di combattimento, o il sistema con cui si piazzano delle tessere), resistendo alla tentazione di cambiare molte cose diverse che regolano parti diverse del gameplay. Questo, ovviamente, perché cambiare “troppo” in aree diverse del progetto potrebbe portarci a risolvere un problema creandone contemporaneamente un altro, e se il gioco non è estremamente lineare si rischia di perdere un sacco di tempo a capire da cosa dipenda la nuova situazione non prevista.

In generale, inoltre, cercate di rimanere sempre focalizzati sull’esperienza desiderata e se modificate qualcosa cercate di farlo nella maniera più coerente possibile con lo scopo ultimo del vostro gioco. Se per esempio un’asta risolverebbe un problema di bilanciamento delle azioni, ma non c’entra davvero nulla con la nostra idea di gioco, forse è meglio pensare a altre soluzioni o spendere più tempo nel bilanciare quelle azioni una per una che inserire una nuova meccanica secondaria che non c’entra nulla col nostro gioco.

È sicuramente utile tenere aggiornato il documento di design e utilizzare eventuali file (siano essi di testo, grafica o fogli di calcolo) per raccogliere informazioni utili che non volete inserire nel regolamento: a seconda del gioco, può essere utile avere una lista di keyword coi relativi effetti, lo schema di tutte le carte\tessere con costi e valori, il set di icone presenti nel gioco etc.

Fatte queste dovute premesse, ci sono comunque una serie di linee guida che possiamo seguire, che coprono diversi tipi di “bilanciamento”.

1. Ogni gioco deve avere un livello di complessità e/o sfida commisurato al target. Che sia un collaborativo o un competitivo, le abilità e le competenze richieste ai giocatori devono essere in linea con il target del gioco: uno dei compiti del bilanciamento è far sì che l’audience del gioco trovi la difficoltà (di impararlo, di giocarci, di padroneggiare tattiche e strategie) adeguato.
2. Ogni gioco deve fornire a tutti i giocatori le stesse probabilità di vittoria o dire in modo chiaro che non è così, ove necessario. Non devono quindi esserci strategie dominanti o elementi che permettano a un giocatore di vincere più facilmente degli altri. Questo vale sia per giochi simmetrici che asimmetrici [1].

Se per il primo punto è sufficiente far giocare il gioco al target di riferimento alzando o abbassando la complessità a seconda dei feedback, dando ovviamente per scontato che si siano già risolti o si stiano risolvendo tutti i problemi relativi a regole farraginose, ridondanti o di difficile assimilazione, nel secondo caso le cose potrebbero farsi un po’ più complesse. Di modi per bilanciare un gioco ce ne sono tantissimi e dipendono molto dal tipo di gioco; conoscere giochi esistenti aiuta, ma anche in questo caso probabilmente la pratica sarà la nostra migliore alleate. In generale, il modo per bilanciare diversi elementi di gioco può essere diviso in tre macro-categorie: bilanciamento matematico interno, bilanciamento matematico esterno e bilanciamento non matematico [2]. In realtà la lista non vuol essere esaustiva, ogni gioco può aver bisogno di una procedura tutta sua per essere bilanciato a dovere, anzi, di solito si usano tutti e tre i sistemi contemporaneamente ma in modi diversi. in questa sede mi limiterò a descrivere le situazioni più comuni, ricordando che per quanto riguarda il bilanciamento matematico del gioco è davvero utile dare un “valore” anche a effetti e abilità che non sono espressi numericamente, tenendo un foglio di calcolo con tutti i valori, in modo da capire al volo cosa succede cambiando un elemento (e sapere subito quanti e quali elementi dovete correggere).

Bilanciamento matematico interno: è il classico metodo di bilanciamento per cui a un elemento di gioco si assegnano almeno due valori (per esempio la “potenza” e il “costo” o “il punteggio” e “il numero di copie presenti nel mazzo”). Riducendo o aumentando l’uno, l’altro o entrambi si possono bilanciare gli elementi stessi. Che lo applichiamo a un singolo oggetto di gioco a un micro-sistema (es. “le armi”, o “gli edifici”), consiste nel modificare costi, vantaggi e svantaggi dei singoli elementi senza tenere in considerazione le interazioni con il resto del gioco in senso stretto. L’esempio più calzante con un gioco famoso è il rapporto fra costi e rendite dei terreni del Monopoly.

Bilanciamento matematico esterno: definito egregiamente dalla morra cinese, è il metodo di bilanciamento relativo a interazioni e relazioni fra elementi, e si basa sul potenziare o depotenziare qualcosa sulla base non di sé stesso, ma di qualcos’altro. Per esempio, un oggetto molto forte potrebbe avere un bonus che si applica solo in alcune stanze o solo contro alcuni mostri, un edificio potrebbe dare pochi punti, ma avere dei bonus per ogni edificio di un tipo specifico costruito, delle risorse potrebbero avere sempre lo stesso costo, ma effetti diversi a seconda del personaggio che le usa. L’esempio della morra cinese, nella sua semplcità, spiega bene il principio: forbici, carta e sasso sono strutturalmente identici, il loro valore cambia solo ed esclusivamente in relazione a uno degli altri elementi del gioco.

Bilanciamento non matematico: è il sistema che si usa quando si decide di dare a diversi elementi effetti e funzioni così diverse fra loro da rendere impossibile una comparazione matematica efficiente, come può succedere per esempio per effetti “fisici”, per giochi estremamente asimmetrici o basati su creatività, forti interazioni sociali o altri elementi non riducibili a valori numerici. L’unico modo per usarlo efficacemente è tramite una mole estremamente consistente di playtest, preferibilmente con gruppi diversi per coprire il massimo numero possibile di comportamenti.

Come dicevo, spesso ci troveremo a usare tutti e tre gli approcci contemporaneamente, non sono assolutamente “mutualmente esclusivi”, anzi, i risultati migliori bilanciando un gioco si ottengono sempre avendo molto chiara la rete di relazioni fra i vari elementi che lo compongono a tutti i livelli. Quindi è sempre opportuno avere (in testa o nel design document) uno schema che riassuma le relazioni fra le varie regole, le risorse e in generale tutti gli elementi, fisici e non, che compongono il nostro gioco.

Infine, giova ricordare che esistono alcuni escamotage che possono aiutare in fase di design e sviluppo, soprattutto se siete alle prese con progetti complessi. Il primo è usare meccaniche auto-bilancianti. Le aste, soprattutto al rilancio, l’uso di sistemi di draft o di mercati dinamici (“se vendi, il prezzo scende, se compri il prezzo sale”) tendono a far sì che gli oggetti vengano “pagati”, “trovati” o “usati” il giusto, che sarà stabilito dagli stessi giocatori a livello dinamico. Si può anche optare per l’utilizzo di limiti (limitando il numero o il tipo di carte in mano, mettendo un valore massimo al valore complessivo delle carte nella propria area di gioco, stabilendo un costo totale delle truppe di un’armata), si possono usare le informazioni come se fossero una risorsa e, soprattutto, si possono inserire sistemi di compensazione che facciano sì che uno o più giocatori, in una qualsiasi condizione di vantaggio o svantaggio, ricevano bonus e malus specifici a seconda della propria situazione. Come potete vedere le situazioni sono tantissime e le soluzioni possono essere molte di più, per cui non ci resta che armarci di calma e sangue freddo e lavorare sodo per far sì che i nostri giocatori ottengano dal nostro gioco un’esperienza significativa, magari non la più appagante della loro vita ludica, ma almeno una di quelle che vale la pena ricordare.

—

[1] Questa cosa della simmetria spesso è un po’ confusa. In generale, tranne rarissimi casi, tutti i giochi sono asimmetrici per qualche motivo, perché l’unico gioco realmente simmetrico è un gioco in cui tutte le informazioni sono a disposizione di tutti, le dotazioni iniziali sono identiche per ogni giocatore, e si gioca in contemporanea. Altrimenti – si pensi agli scacchi o al go – basta il fatto che un giocatore giochi per primo rispetto agli altri per innescare dinamiche tali da rendere comunque la partita non simmetrica. In questa enorme scala di colori che va da Ricochet Robots a Magic the Gathering, si tende a considerare “asimmetrico” un gioco che implichi un forte ed evidente squilibrio iniziale: devono essere presenti differenti fazioni\personaggi\poteri per ogni giocatore, differenti condizioni di vittoria o sconfitta, o comunque una serie di elementi che facciano sì che l’esperienza di gioco e il gameplay risultino immediatamente e effettivamente differenti a seconda del “ruolo” con cui si sceglie di giocare.

[2] Ian Schreiber li chiama “transitivo”, “intransitivo” e “tuttifrutti”, ma la sostanza è la stessa.