Template game design document: il modello da una pagina

Un template game design document utile deve stare prima su una pagina sola e crescere solo quando il gioco se lo guadagna. Parti da cinque blocchi: pitch, pilastri di design, core loop, elenco dei sistemi e domande aperte. Tutto il resto, dal lore alle note di livello, entra quando una sessione di prova dimostra che la meccanica funziona davvero. Qui sotto trovi il modello che usiamo per i progetti indie e da tavolo, insieme a dove ogni sezione tende a marcire.

Perché la maggior parte dei game design document muore entro la terza settimana?

Il fallimento tipico è l'ambizione. Qualcuno apre un file vuoto, incolla una scaletta di venti sezioni trovata in un forum e passa un weekend a riempire caselle per meccaniche che nessuno ha mai testato. Alla terza settimana il gioco si è spostato e il documento no. Nessuno lo apre più, e nessuno lo ammette.

La guida di Game Dev Beginner sui GDD dice il problema senza giri di parole: i documenti grandi e troppo dettagliati richiedono un lavoro enorme all'inizio, sono quasi sempre superati e diventano una gabbia proprio mentre il design sta ancora cambiando. La soluzione proposta è procedere a stadi. Prima una pagina, poi una decina quando il gioco prende forma, e la versione completa solo quando si inizia a produrre contenuti.

Questo vale ancora di più per chi progetta giochi di ruolo da tavolo, rispetto a un team di videogiochi. Un designer TTRPG è spesso insieme autore, responsabile dei sistemi e tester. Nessun ingegnere aspetta una specifica. Il documento ha un solo compito: impedirti di contraddirti tra la sessione quattro e la sessione quaranta.

Lascia perdere il template da 40 pagine se lavori da solo. Non riuscirai a mantenerlo. Anche la definizione standard parla di documento vivo, cioè qualcosa che nessuno si aspetta sia finito il primo giorno.

Cosa deve contenere un template game design document che la gente apre davvero?

Cinque blocchi coprono il primo mese di quasi ogni progetto. Tieni ciascuno abbastanza corto da poter leggere tutta la pagina in due minuti.

1. Pitch. Due frasi. Chi gioca, cosa fa e cosa lo distingue dal gioco più vicino che possiede già.

2. Pilastri di design. Tre o quattro affermazioni con cui testare ogni decisione successiva. "Ogni combattimento costa qualcosa in modo permanente" è un pilastro. "Divertente e coinvolgente" no.

3. Core loop. Ciò che il giocatore ripete. In un dungeon crawl può essere esplorare, scegliere, rischiare, spendere. In una campagna politica può essere intrigo, leva, conseguenza, ricaduta.

4. Elenco dei sistemi. Solo nomi, con una riga ciascuno. Niente numeri per ora.

5. Domande aperte. La sezione più utile della pagina, quella che i template di solito dimenticano. Scrivi ciò che non sai, e datalo.

In fondo aggiungi un registro delle modifiche, anche solo una riga a settimana. Quando una sessione di prova uccide un'idea, annota la morte e il motivo. Altrimenti tra sei mesi proverai di nuovo la stessa idea senza ricordarlo.

Come scrivere i pilastri di design in modo che possano perdere una discussione?

Un pilastro si guadagna il posto perché può bocciare qualcosa. Se non riesci a indicare una funzione che il pilastro rifiuterebbe, è solo decorazione.

Mettili alla prova con una lista di tagli. Prendi le tre funzioni a cui sei più affezionato e chiedi a quale pilastro serve ciascuna. Una funzione che non serve nessuno finisce nello scaffale del "forse più avanti", e quello scaffale può restare lungo. È l'ora più dura dell'intero processo, e vale più di qualunque sezione di template.

Un esempio concreto da un'ambientazione di campagna con una peste al centro. Primo pilastro: la scarsità è visibile, quindi ogni risorsa curativa viene tracciata sul tavolo. Secondo pilastro: le fazioni vogliono cure diverse, quindi nessun trattamento risolve tutto. Terzo pilastro: la mappa si restringe, quindi viaggiare costa sempre di più man mano che la storia avanza. Ora arriva la proposta di un incantesimo di resurrezione. Il primo pilastro la respinge. La decisione prende dieci secondi invece di una discussione di quaranta minuti.

Da tenere presente: i pilastri non sono uno slogan di marketing. Sono interni, diretti, e possono suonare un po' poco lusinghieri. Va bene così.

Dove va il lore in un GDD e dove invece intralcia?

Il lore è la sezione che cresce più in fretta e viene letta di meno. Di solito finisce sepolto in fondo sotto un titolo "Storia", oppure occupa tutto il file. Nessuna delle due soluzioni funziona.

Separa il materiale in base a ciò che fa. Il lore che cambia il gioco, come il rancore di una fazione che sblocca una missione o una maledizione che plasma una classe, vive dentro i sistemi che tocca. Il lore che serve solo a creare atmosfera vive in una pagina separata del Codex, che nessuno deve aprire per prendere una decisione di design. Il test è semplice: se cancellare il paragrafo non cambia una meccanica, un tiro o una scelta del giocatore, appartiene al Codex.

Questa divisione protegge anche il canone. Quando un fatto vive in due posti, i due si allontanano. Scegli una sola casa per ogni fatto e collegala da tutti gli altri punti. Il canone è una promessa, e ogni incoerenza la rompe.

Chi lavora su giochi molto narrativi aggiunge spesso una pagina di cronologia e una tabella di "chi sa cosa". Entrambe costano poco e fanno risparmiare intere sessioni di rielaborazione quando una rivelazione tardiva deve funzionare nel modo giusto.

Quale strumento deve ospitare il tuo template: Notion, Obsidian o un documento semplice?

Lo strumento conta meno di un'altra cosa: il documento deve restare nel posto in cui già lavori. Un documento che vive in una scheda che non apri mai è un documento morto.

Notion è la scelta predefinita per i piccoli team, perché le pagine si collegano tra loro, i database contengono oggetti e fazioni, e i collaboratori non devono configurare nulla. Esistono anche modelli pronti, incluso un modello Notion per GDD con sezioni dedicate a controlli, game loop, progettazione dei livelli e regole. Il rischio è il vincolo allo strumento e la tentazione di costruire database per cose che non ne hanno bisogno.

Obsidian va bene per il designer solitario che vuole file Markdown semplici sul disco. I backlink qui fanno un lavoro vero: collega una fazione a ogni scena in cui compare e ottieni gratis un controllo di coerenza. Sopravvive anche se il fornitore scompare, cosa che conta se il progetto dura anni.

GitBook funziona quando il documento deve essere pubblico o semipubblico, per un gruppo di playtest o la pagina dei sostenitori di un crowdfunding. Un normale Google Doc va bene per una game jam. Evita strumenti con un modello di permessi complicato, a meno che non sia un editore a chiederlo.

Qualunque strada scegli, fissa una regola: il documento si aggiorna alla fine di ogni playtest, prima che qualcuno se ne vada a casa. Dieci minuti, senza eccezioni.

Cosa aggiungere quando il prototipo regge alle prove di gioco?

Dopo tre o quattro sessioni con giocatori veri, la pagina singola si guadagna il livello successivo. Aggiungi le sezioni in quest'ordine, e solo quando emerge il bisogno.

Dettaglio dei sistemi. Numeri, tabelle, casi limite. Scrivili nel momento in cui blocchi un sistema, non prima. Per un gioco di ruolo qui vanno l'economia delle azioni, gli intervalli di danno e i costi delle risorse, insieme al testo delle regole così com'è scritto. Per un videogioco, aggiungi le tabelle dati che leggeranno gli ingegneri.

Liste dei contenuti. Oggetti, nemici, fazioni, luoghi. Usa una tabella con una riga per voce e una colonna per il pilastro che ciascuna serve. Le righe che non servono nessuno sono candidate al taglio.

Interfaccia e flusso. Layout della scheda del personaggio per il tavolo, flusso di schermate per il digitale. Schizzalo a mano prima di descriverlo a parole.

Note di produzione. Traguardi, ambito, rischi, cosa c'è nella prima versione e cosa no. Se pensi di vendere il risultato su DriveThruRPG o Itch.io, qui iniziano anche il testo della pagina e le ipotesi di prezzo.

Una sezione di pitch o di marketing è un documento a parte, per un lettore diverso. Editori e sostenitori cercano contesto di mercato e punti di forza unici. I tuoi playtester cercano regole. Mescolarli produce un file che non serve nessuno dei due.

Può l'IA aiutarti a scrivere un game design document, e dove non basta?

Aiuta con le bozze delle parti noiose e fallisce proprio dove conta. Chiedi a un modello di espandere un elenco di sistemi in una tabella di casi limite e in un minuto avrai una prima stesura decente. Chiedigli di scegliere i tuoi pilastri e otterrai pilastri che suonano come quelli di qualunque altro gioco. Genera in fretta, ma le decisioni richiedono ancora una revisione umana.

L'uso più pratico è il controllo di coerenza. Dagli in pasto il Codex e l'elenco dei sistemi, poi chiedi dove due pagine si contraddicono. Strumenti costruiti attorno a una bibbia narrativa lunga, come Novelcrafter, sono pensati proprio per questo tipo di verifica incrociata. Tratta il risultato come una lista di sospetti, non come un verdetto, e controlla ogni segnalazione sulle tue pagine.

Una regola ferma: il modello non scrive mai la sezione delle domande aperte. Quella pagina è il tuo elenco onesto di ciò che non sai, e affidarla a qualcun altro ne vanifica lo scopo.

Cosa saltare e cosa tenere?

Salta il template completo finché una meccanica non è sopravvissuta ad almeno tre sessioni reali. Salta il saggio sul "pubblico di riferimento" se non riesci a nominare cinque persone reali che giocherebbero. Salta le sezioni dettagliate sulla monetizzazione per un gioco che non ha ancora trovato il suo loop. Salta qualunque sezione che non riusciresti a immaginare letta ad alta voce a un collaboratore.

Tieni i pilastri, le domande aperte e il registro delle modifiche. Sono questi tre a fare quasi tutto il lavoro. Un documento fatto solo di questi, aggiornato ogni settimana, batte un file lucido da trenta pagine che nessuno apre da marzo.

Il template è una promessa a te stesso futuro su ciò che hai deciso e sul perché. Tienilo abbastanza corto da poterla mantenere.