Template game design document: una pagina che resta viva

Ti serve un template game design document che stia su una pagina, e che cresca solo quando il gioco se lo guadagna. Parti da sette blocchi: pitch, core loop, verbi del giocatore, mondo, sistemi, scope e domande aperte. Riempili in una serata. Taglia tutto ciò che non puoi testare in un prototipo questo mese. Il resto di questo articolo è il template vero e proprio, con le parti che la maggior parte delle guide salta.

Perché la maggior parte dei game design document muore alla seconda settimana

Immagina il GDD da 40 pagine. Copertina bellissima, indice, un capitolo di lore che nessuno ha chiesto. Alla seconda settimana il prototipo si è spostato e il documento è diventato un fossile.

Il problema vero non sono le sezioni mancanti. È un file che smette di essere vero. Un GDD è uno strumento di lavoro, più vicino a un changelog che a una bibbia. Se documento e build non coincidono, vince la build, e le persone smettono di aprire il documento.

Quindi la domanda non è «cosa dovrebbe contenere un game design document?». La domanda è «qual è il documento più piccolo che riuscirò davvero a tenere onesto?»

Il template del game design document su una pagina

Copia questo schema. Ogni blocco merita due o cinque righe, e non di più al primo giro.

1. Pitch. Una frase che uno sconosciuto potrebbe ripetere. «Un villaggio portuale cooperativo dove la marea riscrive la mappa ogni notte.»

2. Core loop. Quello che il giocatore fa, ancora e ancora, in meno di un minuto. Disegnalo come un cerchio di verbi.

3. Verbi del giocatore. Da cinque a otto azioni. Non funzionalità, verbi: scalare, scambiare, nascondersi, fare un fork, riparare.

4. Mondo. Luogo, atmosfera, tre regole sempre vere. Anche il meteo conta come regola.

5. Sistemi. I due o tre meccanismi che rendono interessanti i verbi. Economia, furtività, crafting, qualunque cosa porti avanti il loop.

6. Scope. Cosa esce, cosa viene tagliato, cosa è un obiettivo ambizioso. Accanto a ogni voce, una data.

7. Domande aperte. La lista onesta di ciò che ancora non sai. Questo blocco è il più prezioso della pagina.

Nota cosa manca: monetizzazione, piano marketing, un capitolo con il backstory del personaggio. Quelle cose vanno in file separati, scritti quando il prototipo dimostra che il loop funziona. La maggior parte dei template pubblicati comincia proprio da lì, ed è esattamente il motivo per cui quei documenti non vengono mai finiti.

Se ti serve una struttura più lunga per un team che deve dare il via libera, la guida GitBook su come scrivere un game design document descrive la classica lista di capitoli. Il suo consiglio di partire da una versione di una pagina e aggiungere dettagli man mano che i prototipi lo giustificano è l'istinto giusto.

Cosa dovrebbe dire davvero la sezione sul core loop

Togli gli aggettivi. Scrivi il loop come una frase con un timer.

Raccogli per 40 secondi -> porta il recupero al molo -> scambia per un upgrade -> la marea cambia, la mappa cambia -> ripeti

Ora leggilo ad alta voce. Se un passaggio ti sembra morto, hai trovato il tuo primo compito di prototipo. Se ogni passaggio suona bene ma non riesci a dire perché il giocatore torna, al loop manca una ragione. Mettila tra le domande aperte invece di seppellirla in un paragrafo.

Un test che mi piace: la frase del loop deve stare su una sola riga di testo. Se ne serve un paragrafo, sono due loop, e stai progettando due giochi.

Quali sezioni puoi tagliare senza rimpianti?

Sii spietato. Un progetto da solo, o in due, di solito può eliminare subito queste voci:

• Biografie complete dei personaggi. Tieni un nome, un desiderio, un difetto. Scrivi di più quando il personaggio compare in una build.

• Descrizioni dettagliate dei livelli. Descrivi le regole del livello, non le singole stanze.

• Capitoli su piattaforme e monetizzazione. Mettili da parte finché il loop non funziona.

• Art bible. Tre immagini di riferimento e una palette. Basta questo.

Fa eccezione chi sta costruendo un gioco per una game jam di 72 ore: pitch, loop e verbi sono tutto il documento. Vale la pena tenere la lista completa se hai un editore, un percorso di certificazione per console o collaboratori che non possono farti domande a mezzanotte.

Il PDF del template di game design document di Unity è un buon riferimento su come si scrivono meccaniche e comportamento degli oggetti quando c'è un team. Leggilo come un catalogo, non come una checklist.

Dove conservare il documento?

Dove lo modificherai ogni giorno. Sembra ovvio, finché non vedi quanti GDD vivono in un PDF che nessuno riesce a confrontare con la versione precedente.

Scegli uno strumento che ti dia titoli, un database per i task e una cronologia delle versioni. Un'app di note basata su database funziona bene, perché le domande aperte e la lista dello scope possono diventare elementi tracciati invece di punti elenco che marciscono.

Anche un Markdown semplice nel repository è una risposta valida. Vive accanto al codice, si confronta bene con i diff, e nessuno dimentica di aggiornarlo durante una pull request. Il costo è che i colleghi non tecnici non lo toccheranno.

Qualunque strada tu scelga, metti la pagina di sintesi in cima e collega i file più approfonditi. La pagina è la mappa. I file sono il territorio.

Cambia qualcosa nel documento a seconda del motore?

Un po', sì. Il motore decide quali verbi costano poco e quali costano molto, quindi le sezioni su sistemi e scope devono dirlo chiaramente.

Se lavori in 3D con una pipeline di asset grande, lo scope deve avere una riga per ogni categoria di asset, perché è sui contenuti che i calendari vanno a morire.

Se preferisci un motore open source senza calcoli sulle royalty da tenere sotto controllo, la sezione dello scope diventa più semplice: niente riga sulle licenze, ma una nota seria su quali funzioni costruirai da solo.

Se il gioco è in 2D con meccaniche strette, la sezione del loop porta quasi tutto il peso. Documenti piccoli e leggibili si adattano a giochi piccoli e leggibili.

Il punto non è scegliere un vincitore. Il punto è che «Motore e strumenti» non è una riga da buttare lì. Dovrebbe elencare cosa il motore rende facile, cosa rende doloroso e cosa ti rifiuti di costruire.

Come scrivi un GDD per un mondo che si genera da solo?

È il vuoto che quasi tutti i template lasciano. Presumono che tu piazzi ogni albero a mano.

Quando un mondo viene generato da un prompt, il documento cambia forma. Non specifichi più le stanze. Specifichi i vincoli: cosa deve essere vero in ogni mondo che il motore può produrre, e cosa è lecito che vari.

Aggiungi due blocchi alla pagina di sintesi:

• Vincoli del mondo. Le regole che non si possono rompere. «Ogni insediamento ha acqua a non più di due minuti a piedi.» «Nessuna missione in luoghi senza uscita.»

• Seed di prompt. I prompt esatti che hai usato, salvati come parte del documento.

Ecco come appare un seed nella pratica:

a foggy harbor town at low tide, one lighthouse, narrow stairs, rope bridges between rooftops, nobody in sight yet

Salva il prompt, salva ciò che è tornato indietro, e annota cosa faresti come fork. Il prompt è insieme la specifica e il changelog. Fai un fork, cambia una cosa, guarda cosa succede, poi scrivi il delta nel documento. Questa abitudine trasforma un mondo generato in qualcosa su cui puoi ragionare, e dà ai colleghi qualcosa di concreto da criticare invece di un'impressione vaga.

Un avvertimento: la qualità della generazione cambia molto da uno strumento all'altro, e alcune funzioni sono ancora in beta in tutto il settore. Scrivi versione e data accanto a ogni seed, così sai se un risultato è ripetibile o solo un tiro fortunato.

Un modo veloce per testare il loop prima di scrivere altro

Questo è il flusso serale che seguirei su un'idea nuova.

1. Scrivi la pagina di sintesi in 30 minuti. Non modificarla.

2. Trasforma il pitch e le tre regole del mondo in un prompt, e genera una prima versione dello spazio.

3. Percorri il core loop in quello spazio, a mano o in un prototipo grezzo.

4. Segna ogni passaggio che ti è sembrato morto. Quelli vanno tra le domande aperte.

5. Taglia un verbo. Taglia sempre un verbo.

Il taglio è la parte che la gente salta. Un documento di design che cresce solo è una lista dei desideri. Togliere un verbo costringe quelli rimasti a portare più peso, e di solito rivela quale sistema stava facendo davvero il lavoro.

Come tieni vivo il documento dopo la seconda settimana?

Tre abitudini, nessuna eroica.

Data ogni domanda aperta. Se una domanda ha più di tre settimane e resta aperta, rispondile o ammetti che la stai evitando.

Aggiorna il documento nella stessa sessione della build. Non dopo. Il dopo è il momento in cui si forma il fossile. Una modifica di due righe alla fine di una sessione costa un minuto.

Tieni in fondo una lista delle idee uccise. Ti evita di ridiscutere ogni mese la stessa meccanica, e fa un certo effetto vedere quanto hai portato a termine dicendo di no.

Quando qualcuno di nuovo entra nel progetto, dagli prima la versione su una pagina e osserva dove si confonde. Ogni domanda di chi si confonde è una riga mancante nel documento.

Cosa useremmo davvero?

Se lavori da solo o in due, la pagina di sette blocchi più una lista di seed di prompt basta per il primo mese. Se hai un team, tieni la pagina di sintesi come porta d'ingresso e aggiungi file separati per sistemi e contenuti man mano che il prototipo li giustifica. Se hai un editore, dagli la versione lunga, ma tieni la tua pagina di sintesi come la versione di cui ti fidi.

Apri una pagina bianca stasera e scrivi il pitch. Una frase. Poi il loop, con un timer sopra. Se non riesci a finire in mezz'ora, l'idea è ancora un sogno, e vale la pena saperlo prima di passarci un mese.