Quello che state per leggere fa parte di una serie di articoli estratti dal mio lavoro “Progettare giochi da tavolo”. Si tratta di un progetto di cui ho parlato in questo post sul forum della Tana dei Goblin.
L’idea è quella di estrarre dai libri alcuni paragrafi che trattano argomenti ritenuti da me di particolare interesse e di presentarli sottoforma di articoli. Se avete già letto i libri non troverete nulla di nuovo, ma se non li aveste ancora letti potreste trovare qualche spunto interessante.
Di seguito gli articoli facenti parte di questa serie:
1 - Gli archi di gioco
2 - Progressione del gioco e dei giocatori
3 - Gestione dei pareggi
4 - La casualità come fonte di incertezza
5 - La tensione e la pressione
6 - Modellare la curva di apprendimento
7 - Bilanciare un gioco con il metodo dell’ancoraggio
8 - La granularità nel bilanciamento di un gioco
9 - Il design document
La progettazione di un gioco da tavolo è un’attività articolata e complessa, nella quale possono essere coinvolte diverse persone. Si tratta di un lavoro lungo, che può durare diversi mesi se non addirittura anni, nel corso dei quali il gioco può anche essere messo in pausa in attesa di ispirazione o per dedicarsi a qualcosa di più urgente. Non è raro, inoltre, che un designer sia impegnato nel progettare più di un gioco allo stesso tempo.
Proprio per questo è buona norma seguire un metodo di lavoro che permetta di tenere traccia in modo strutturato e ordinato delle informazioni utili all’avanzamento del progetto. Se ci si affida solamente alla memoria, infatti, si corre il rischio che certe idee o certi dettagli vengano dimenticati col passare del tempo o a seguito di una pausa.
La prima regola che è bene seguire, quindi, è quella di annotarsi tutte le informazioni che risultano significative dal punto di vista del progetto. Queste annotazioni, poi, vanno organizzate in qualcosa di strutturato che sia facilmente fruibile.
C’è da dire che al momento non esiste ancora una formalizzazione precisa su come strutturare queste informazioni. La progettazione dei giochi da tavolo, infatti, ha iniziato a essere considerata un processo formale di design da troppo poco tempo per poter avere già dei metodi di lavoro formali. Nonostante questo, però, esistono alcuni documenti il cui utilizzo è largamente condiviso e tra tutti, uno dei più importanti è sicuramente il design document.
Il design document è un documento che aiuta il designer a tradurre le idee, i pensieri e le ispirazioni in informazioni strutturate, utili alla progettazione del gioco. Per il designer e per tutti gli eventuali collaboratori rappresenta il punto di riferimento del lavoro di progettazione.
Si tratta di un documento di tipo descrittivo dove vengono annotati i principi, gli obiettivi, le caratteristiche del gioco e tutte le informazioni che servono a dare la direzione alle scelte di progettazione. Man mano che il gioco evolve, il design document si aggiorna andando a registrate tutte le nuove decisioni che vengono prese. Esso rappresenta, così, una panoramica sempre aggiornata sullo stato di progettazione del gioco.
Sebbene il designer potrebbe decidere di procedere nella realizzazione del suo gioco senza il supporto del design document, il suo utilizzo è caldamente consigliato per diversi motivi.
In primo luogo, c’è il fatto che per compilarlo si devono avere le idee molto chiare sull’aspetto del gioco di cui si vuole scrivere. Questo costringe a dover ragionare, prima o dopo, su tutti gli aspetti importanti del progetto andandoli a definire nel dettaglio. Quando non si è costretti a scrivere, invece, può esserci il rischio, anche involontario, di lasciare sul vago alcuni aspetti. Inoltre, una volta che i pensieri sono stati messi per iscritto sul design document, è facile far emergere incompatibilità o conflitti. A questo punto, infatti, eventuali elementi in contrasto diventano molto più evidenti rispetto a quando il gioco era solamente nella mente del designer.
Secondariamente, il design document permette di mantenere chiari nel tempo sia gli obiettivi del progetto sia le scelte progettuali che sono state fatte. Come già detto, la lavorazione di un gioco da tavolo è un’attività lunga. Risulta, quindi, abbastanza normale che, per scongiurare il rischio di dimenticanze, il designer decida di non affidarsi solamente alla sua memoria. Inoltre, a volte può anche capitare di dover rielaborare un gioco anni dopo la sua conclusione (ad esempio per fare una seconda edizione). In casi di questo tipo, il design document funge da memoria storica e permette di riprendere velocemente in mano il gioco.
Infine, il suo utilizzo facilita le comunicazioni con altre persone che devono lavorare sul gioco, siano essi coautori, editori o collaboratori di altro genere. Per una persona che dovesse iniziare una collaborazione con il designer, infatti, sarà sufficiente leggere il design document e il regolamento per farsi un’idea abbastanza precisa sul gioco. Inoltre, durante tutto il corso della collaborazione, il design document avrà lo scopo di essere il luogo dove raccogliere tutte le informazioni di progetto in modo da renderle sempre disponibili a tutti gli interessati.
Il design document è un documento vivo, che cambia e si evolve con l’avanzare del processo iterativo di design. La prima compilazione avviene con le informazioni emerse durante la fase di definizione iniziale del gioco. Nella prima stesura, quindi, le informazioni non saranno complete e in molti casi fungeranno come una sorta di dichiarazione d’intenti. Se, per esempio, in questa fase il designer scrive che il gioco dura 30 minuti, significa che questo è il suo proposito. Non avendolo ancora potuto provare (probabilmente in questo stadio di sviluppo non esiste nemmeno un prototipo) non può essere certo che sia veramente così. Il significato di scrivere questa informazione così presto è quello di voler fissare qual è la durata ottimale per il tipo di gioco. Chiaramente, non è obbligatorio inserire già da subito questo tipo di informazioni: se non è ancora stata fatta una valutazione è possibile rimandare la compilazione di alcuni dati a un momento successivo.
Alla fine di ogni ciclo del processo iterativo di design, poi, è importante tornare sul documento per accertarsi che le informazioni presenti siano sempre aggiornate. Man mano che il gioco evolve e vengono prese nuove decisioni, infatti, sempre più aspetti diventeranno chiari. Il design document, quindi, va rivisto e modificato. A seconda di com’è andato il ciclo di iterazione, ci si troverà a dover apportare revisioni più o meno profonde. Ci saranno dei momenti in cui verranno modificate o aggiunte intere sezioni, mentre altri in cui ci saranno da apportare solo minime correzioni. Sebbene possa sembrare un processo dispendioso in termini di tempo, mantenere il design document aggiornato è una cosa molto importante da fare, soprattutto per i giochi complessi o dove sono coinvolte più persone.
Da un punto di vista pratico, non esiste un modello standard e formalizzato da usare, ma ognuno può strutturare il design document come meglio crede. In genere può prendere una forma diversa sia a seconda delle preferenze del designer, sia a seconda del gioco che si intende progettare. Ad esempio, per dei giochi semplici basterà un design document snello, mentre per dei giochi più complessi sarà necessario usare un design document più articolato. Allo stesso modo non è possibile dire a priori quanto si dovrà scendere nel dettaglio sui vari temi presenti all’interno del documento. Anche questo aspetto dipenderà molto dal tipo gioco. In alcuni casi si sentirà la necessità di andare in profondità nella descrizione di certi aspetti e restare più ad alto livello su altri. In altri casi, magari, sarà il contrario.
Di seguito viene proposta una possibile strutturazione del design document. Il documento viene diviso in quattro sezioni, ognuna delle quali contiene una serie di temi da sviluppare. Non deve spaventare la mole di dati richiesti. Come già detto in precedenza, infatti, le varie informazioni vanno inserite man mano che si rendono disponibili. A seconda del gioco, poi, si può decidere di scendere più o meno in profondità e in alcuni casi, certi temi possono essere tralasciati. Il consiglio, però, è quello di scrivere qualcosa per ogni aspetto. Se si ritiene che non ci sia niente di rilevante su un certo tema, infatti, è comunque bene scriverlo. Questo farà capire a chi leggerà il documento che quell’aspetto è stato preso in considerazione, ma che non è stato sviluppato in quanto non lo si è ritenuto necessario.
Il designer può usare il modello presentato di seguito così com’è oppure può usarlo come base per creare una struttura che si adatti meglio al suo stile di progettazione.
Sezione 1: Dati di sintesi
- Titolo di lavoro;
- Autori;
- Numero di giocatori supportati;
- Età consigliata;
- Durata attesa;
- Genere del gioco;
- Data di ultima modifica del documento;
- Eventuali scadenze per la progettazione.
Sezione 2: informazioni generali sul gioco
- Breve descrizione del gioco;
- Elemento centrale e distintivo;
- Target;
- Esperienza desiderata (estetiche);
- Dinamiche previste ed emergenti;
- Meccaniche principali;
- Meccaniche secondarie;
- Ambientazione, Tema, LORE e arco narrativo del gioco.
Sezione 3: informazioni sulla struttura del gioco
- Modalità di gioco;
- Struttura del tempo di gioco;
- Azioni;
- Automatismi;
- Risorse;
- Obiettivi in gioco;
- Condizione di fine partita;
- Obiettivo per la vittoria;
- Sistemi di punteggio.
Sezione 4: informazioni sulle dimensioni del gioco
- Interazione;
- Fonti di incertezza;
- Controllo;
- Varietà;
- Valutazioni sulla durata e sul valore del tempo di gioco;
- Scalabilità e ridimensionamento del gioco;
- Spazio di gioco;
- Soddisfazione;
- Stabilità;
- Sistemi di progressione.
A questo link è presente il file contenente il modello completo di tutti i dettagli. Si tratta di un modello che ho realizzato nel corso del tempo e che ho iniziato ad usare abitualmente nei miei progetti.