Modello di game design document

File Modello di game design document/Game design document.md

Game design document

Come usare questo modello: le righe in corsivo sono indicazioni. Sostituiscile con parole tue, poi cancellale. I valori tra parentesi quadre sono da compilare. Tieni questa pagina più o meno entro una schermata: è quella che tutti leggono per prima, e ogni altra parte del design è a un link di distanza.

In sintesi

Pitch

Due o tre frasi: chi è il giocatore, cosa fa e cosa rende il gioco diverso. Scrivilo in modo che funzioni anche su una pagina dello store.

Esempio (Saltmarrow, un gioco dimostrativo): Rastrella il sale, immergiti in cerca di ricordi, torna a casa prima della marea. Un gioco cooperativo di esplorazione e crafting fino a quattro giocatori, ambientato in saline di marea dove una città archivio sommersa riemerge due volte al giorno.

[Il tuo pitch]

Pilastri di design

Da tre a cinque regole che ogni funzionalità deve servire. Un pilastro che potrebbe descrivere qualsiasi gioco, come «combattimenti divertenti», non è un pilastro. Una funzionalità che non serve nessun pilastro si taglia; una che ne rompe uno si riprogetta.

1. [Primo pilastro]: [cosa significa, in una frase]
2. [Secondo pilastro]: [cosa significa, in una frase]
3. [Terzo pilastro]: [cosa significa, in una frase]

Esempio (Saltmarrow, un gioco dimostrativo): La marea è l’orologio. Il tempo è l’unica risorsa che non cresce mai: ogni sistema legge la marea, e niente la mette in pausa.

Pubblico

Per chi è il gioco, a cosa giocano oggi queste persone e quando smettono di giocare. Cita giochi veri e abitudini vere, non solo una fascia d’età.

• Giocatori principali: [chi sono e come giocano]
• A cosa giocano oggi: [tre o quattro giochi]
• Smettono di giocare quando: [...]
• Giocatori secondari: [...]

Giochi di riferimento

Tre o quattro giochi che il tuo team e i tuoi giocatori conoscono già. Di’ cosa prendi da ciascuno e, altrettanto utile, cosa lasci.

Perimetro

Cosa contiene la prima versione e cosa, esplicitamente, non contiene. È la seconda lista a impedire che il perimetro cresca in silenzio.

• Nella prima versione: [...]
• Non nella prima versione: [...]
• Da decidere più avanti: [...]

Il resto del design

Ogni parte è un documento a sé. Rimanda a quella invece di copiarne il contenuto, così ogni fatto vive in un solo posto e cambia in un solo posto.

• Gameplay: il ciclo di gioco, le meccaniche, i controlli e la progressione
• Sistemi ed economia: ogni sistema, le sue regole e i suoi numeri
• Mondo, storia e personaggi: l’ambientazione, la storia e chi la abita
• Livelli e contenuti: ogni luogo, la prima ora e il budget dei contenuti
• Direzione artistica e audio: come appare e come suona il gioco
• Interfaccia e accessibilità: schermate, HUD, comandi e accessibilità
• Design tecnico: motore, obiettivi di prestazioni, architettura e pipeline
• Piano di produzione: milestone, team, rischi e registro delle decisioni

Questo modello è libero: usalo, modificalo e condividilo. Viene da Nodary, dove questi file si importano come una mappa di documenti collegati.

File Modello di game design document/Game design document/01 Gameplay.md

Gameplay

Responsabile: [nome] · Stato: bozza · Ultima revisione: [data]

Cosa fa il giocatore da un minuto all’altro, e perché continua a farlo. Parti dal ciclo: tutto il resto di questo documento dipende da lì.

Ciclo di gioco

Il ciclo che il giocatore ripete più spesso, in una sequenza da quattro a sei verbi. Se il team non riesce a disegnarlo, non è ancora definito.

flowchart LR
  n0["Pianificare"]
  n1["Esplorare"]
  n2["Raccogliere"]
  n3["Creare"]
  n4["Potenziare"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
  n4 --> n0

Esempio (Saltmarrow, un gioco dimostrativo): Raccogliere o immergersi, da 8 a 14 minuti: rastrellare sale sicuro o immergersi in cerca di cristalli che potrebbero valere di più? Ogni fase dovrebbe porre una domanda al giocatore. Una fase senza domanda è una corvée.

Meccaniche

Una riga per meccanica. La colonna del pilastro tiene in riga ogni meccanica: quella che non serve nessun pilastro finisce nella lista dei tagli.

Controlli

I verbi del giocatore e la sensazione che ognuno deve dare. La mappatura dei tasti per ogni dispositivo sta in Interfaccia e accessibilità.

• [Verbo]: [come si esegue e che sensazione deve dare]
• [Verbo]: [...]

Progressione

Cosa cresce durante una sessione e nell’arco dell’intero gioco, e come il giocatore lo vede crescere. Indica l’obiettivo a lungo termine.

• Durante una sessione: [...]
• Tra una sessione e l’altra: [...]
• Obiettivo a lungo termine: [...]

Sfida e fallimento

Come sale la difficoltà, quanto costa fallire e come il giocatore rientra in gioco. Un fallimento che costa solo tempo insegna meno di uno che costa una scelta.

• La difficoltà sale con: [...]
• Fallire costa: [...]
• Per rientrare in gioco: [...]

Esempio (Saltmarrow, un gioco dimostrativo): Un sommozzatore ancora nell’archivio quando suona il corno perde i cristalli che ha nella sacca e riemerge alla torre più vicina, ma tiene il suo sale.

Domande aperte

• [Domanda], [chi risponde], [entro quando]

Vedi anche: Game design document · Sistemi ed economia · Livelli e contenuti

File Modello di game design document/Game design document/02 Sistemi ed economia.md

Sistemi ed economia

Responsabile: [nome] · Stato: bozza · Ultima revisione: [data]

Ogni sistema del gioco, le regole che segue e i numeri che ci sono dietro. I numeri cambiano ogni settimana: tienili in tabelle o fogli di calcolo, e il ragionamento qui.

Sistemi

Una riga per sistema. Un sistema che non alimenta nulla è decorazione. Un sistema in cui confluisce tutto è la spina dorsale del tuo gioco, e merita un documento a sé.

Esempio (Saltmarrow, un gioco dimostrativo): Ogni sistema legge la marea: le rese del raccolto, il rischio di tempesta, i prezzi al villaggio, perfino quanto a lungo un personaggio è disposto a parlare.

Risorse e valute

Per ogni risorsa, da dove arriva (fonti) e dove finisce (pozzi). Un’economia con più fonti che pozzi va in inflazione: compila entrambe le colonne prima di bilanciare qualsiasi cosa.

Ricompense e drop rate

Tabelle del bottino, probabilità di ricompensa ed eventuali regole di pity. Di’ cosa deve aspettarsi un giocatore: quanti tentativi servono perché metà dei giocatori ottenga un oggetto, e perché lo ottengano nove su dieci. Il calcolatore di drop rate gratuito lo calcola a partire da una tabella di pesi.

Leve di bilanciamento

I pochi valori che un designer cambia per rendere il gioco più facile, più veloce o più generoso, con il valore attuale e l’intervallo già testato. Quando ne cambia uno, annota il perché nel registro delle decisioni del piano di produzione.

Domande aperte

• [Domanda], [chi risponde], [entro quando]

Vedi anche: Gameplay · Livelli e contenuti · Piano di produzione

File Modello di game design document/Game design document/03 Mondo, storia e personaggi.md

Mondo, storia e personaggi

Responsabile: [nome] · Stato: bozza · Ultima revisione: [data]

Le regole del mondo, la storia che il giocatore vive e chi la abita. La lore che non arriva mai al giocatore va in documenti a parte, collegati da qui.

Ambientazione

Dove e quando, in tre frasi, e la regola di questo mondo che il giocatore sente mentre gioca.

Esempio (Saltmarrow, un gioco dimostrativo): Una città biblioteca che cercò di sopravvivere al mare coltivando il sale. Funzionò: il sale conservò i libri e annegò i lettori. Due volte al giorno, la marea la scopre.

[La tua ambientazione]

Tono

Tre parole, ciascuna con un gioco, un film o un libro che fissa l’asticella. Poi cosa il tono non è: chiude più discussioni di cosa è.

• Tono: [...]
• Riferimenti: [...]
• Mai: [...]

Traccia della storia

La storia come la vive il giocatore, momento per momento, non l’antefatto. Annota come ogni momento arriva al giocatore: una cutscene, una battuta di dialogo, un oggetto trovato, il livello stesso.

Personaggi

Quando un personaggio ha più di qualche battuta, dagli un documento a sé (un profilo, riferimenti, dialoghi d’esempio) e collegalo da questa tabella.

Regole di scrittura

Le convenzioni che ogni autore segue: nomi e grafie, parole che questo mondo non usa mai, la battuta più lunga che sta sullo schermo. Scritte presto, fanno risparmiare settimane al team di localizzazione.

• [Regola]
• [Regola]

Domande aperte

• [Domanda], [chi risponde], [entro quando]

Vedi anche: Game design document · Livelli e contenuti · Direzione artistica e audio

File Modello di game design document/Game design document/04 Livelli e contenuti.md

Livelli e contenuti

Responsabile: [nome] · Stato: bozza · Ultima revisione: [data]

Ogni luogo in cui va il giocatore e ogni contenuto di cui il gioco ha bisogno, con le quantità di ciascuno. Questa lista diventa il backlog di produzione, quindi tieni i numeri onesti.

Luoghi e livelli

Regole di level design

Regole valide in ogni livello: come si guida il giocatore, quanto distano i checkpoint, come si segnalano i segreti. Scrivile una volta qui invece che in ogni livello.

• [Regola]
• [Regola]

La prima ora

La prima ora del giocatore, passo dopo passo: cosa fa, cosa impara e il primo momento che racconterebbe a un amico. La maggior parte di chi abbandona, abbandona qui.

Budget dei contenuti

Quanti contenuti di ogni tipo servono per la prima versione, e chi li realizza. Confrontalo con il piano di produzione prima che qualcuno inizi a sviluppare.

Domande aperte

• [Domanda], [chi risponde], [entro quando]

Vedi anche: Gameplay · Mondo, storia e personaggi · Piano di produzione

File Modello di game design document/Game design document/05 Direzione artistica e audio.md

Direzione artistica e audio

Responsabile: [nome] · Stato: bozza · Ultima revisione: [data]

Come appare e come suona il gioco, descritto con una precisione tale che due artisti che lavorano separati producano lavori che stanno bene insieme.

Regole visive

Da tre a cinque regole su forme, colori, luce e dettaglio. «Stilizzato» non è una regola; «ogni silhouette si legge a trenta metri» lo è.

• [Regola]
• [Regola]
• [Regola]

Riferimenti

Aggiungi immagini di riferimento sotto ogni regola e di’ cosa prendere da ciascuna: la palette, la luce, le forme. Mai «tutto».

Palette

Famiglie di asset

Cosa hanno in comune gli asset di ogni famiglia, il loro budget (poligoni, dimensione delle texture, frame) e chi li approva.

Audio

Il mood della musica, gli effetti sonori e le voci, e le informazioni di gioco che il suono trasmette: avvisi, ricompense, il passare del tempo.

• Musica: [...]
• Effetti sonori: [...]
• Voci: [lingue e numero di battute, oppure nessuna]
• Informazioni trasmesse dal suono: [...]

Esempio (Saltmarrow, un gioco dimostrativo): Due minuti prima che la marea cambi, un corno risuona sulle saline. La marea si vede sullo schermo, si sente nel mix e si percepisce nel controller.

Revisioni

Chi approva arte e audio, e quando. Lascia i feedback sull’immagine stessa, fissati nel punto a cui si riferiscono: risparmia un giro di «quale, quella a sinistra?»

• L’arte è approvata da: [...]
• L’audio è approvato da: [...]

Domande aperte

• [Domanda], [chi risponde], [entro quando]

Vedi anche: Mondo, storia e personaggi · Interfaccia e accessibilità

File Modello di game design document/Game design document/06 Interfaccia e accessibilità.md

Interfaccia e accessibilità

Responsabile: [nome] · Stato: bozza · Ultima revisione: [data]

Tutto ciò che il giocatore legge, preme e attraversa, e come il gioco si adatta a chi vede, sente o si muove in modo diverso.

Schermate e flusso

Ogni schermata, e come il giocatore passa dall’una all’altra dall’avvio all’uscita. Un diagramma trova i vicoli ciechi prima che vengano costruiti.

flowchart LR
  n0["Schermata iniziale"]
  n1["Menu principale"]
  n2["Gioca"]
  n3["Impostazioni"]
  n4["Pausa"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n2 --> n4
  n4 --> n2
  n4 --> n1

HUD

Cosa resta sullo schermo durante il gioco, e perché ogni elemento si merita il suo posto. Tutto ciò che il giocatore controlla meno di una volta al minuto può stare in un menu.

Comandi

Accessibilità

Spunta ogni voce, o scrivi perché non si applica. Decise presto, la maggior parte costa poco; aggiunte tardi, costano molto.

• Ogni comando può essere rimappato
• Le azioni da tenere premute possono passare alla modalità attiva/disattiva
• I sottotitoli indicano chi sta parlando e la loro dimensione si può modificare
• I suoni importanti hanno anche un segnale visivo
• Nessuna informazione è affidata al solo colore
• Il testo può essere ingrandito
• I timer possono essere rallentati o disattivati
• Lo scuotimento della telecamera e i flash possono essere ridotti

Testi e lingue

Le lingue al lancio, e le regole che rendono possibile la traduzione: nessun testo incorporato nelle immagini, spazio per testi fino a un terzo più lunghi dell’inglese, font che coprano ogni alfabeto in cui esce il gioco.

• Lingue al lancio: [...]
• Lingue successive: [...]
• Font: [...]

Domande aperte

• [Domanda], [chi risponde], [entro quando]

Vedi anche: Gameplay · Direzione artistica e audio · Design tecnico

File Modello di game design document/Game design document/07 Design tecnico.md

Design tecnico

Responsabile: [nome] · Stato: bozza · Ultima revisione: [data]

Le scelte tecniche che danno forma al design, e i limiti che il design deve rispettare. L’architettura dettagliata può stare in documenti di ingegneria collegati da qui.

Motore e strumenti

Obiettivi e budget

I numeri su cui lavora ogni reparto. Senza di essi, i problemi di prestazioni si scoprono alla fine.

Architettura

Le parti principali del codice del gioco e come comunicano tra loro. Un diagramma di cinque riquadri vale più di cinque pagine di testo.

flowchart TD
  n0["Input"]
  n1["Stato di gioco"]
  n2["Rendering"]
  n3["Audio"]
  n4["Salvataggi"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n1 --> n4

Salvataggi e online

• Salvataggi: [cosa si salva, quando e dove]
• Online: [nessuno, peer to peer, server dedicati]
• Dati dei giocatori: [cosa si raccoglie e dove viene conservato]

Pipeline

Come un asset o una riga di testo passa dal suo autore a una build giocabile, e quanto tempo ci vuole. Una pipeline lenta riduce in silenzio il numero di iterazioni di un team.

[La tua pipeline]

Rischi tecnici

Domande aperte

• [Domanda], [chi risponde], [entro quando]

Vedi anche: Interfaccia e accessibilità · Piano di produzione

File Modello di game design document/Game design document/08 Piano di produzione.md

Piano di produzione

Responsabile: [nome] · Stato: bozza · Ultima revisione: [data]

Quando esce il gioco, chi lo realizza, cosa potrebbe fermarlo, e ogni decisione presa lungo la strada.

Milestone

«Raggiunta quando» è la colonna che si salta sempre. Senza, una milestone è solo una data.

Team

Rischi

Registro delle decisioni

Ogni decisione che cambia il design: cosa si è deciso, chi l’ha deciso, perché e quale documento è cambiato. Sei mesi dopo, quando qualcuno chiede perché funziona così, questa tabella risponde.

Esempio (Saltmarrow, un gioco dimostrativo): 12 settembre: niente combattimento, la minaccia arriva solo dalla marea e dalle tempeste. Decisa dal direttore creativo e dal system designer, per mantenere il gioco calmo e il suo conto alla rovescia serrato. Documento modificato: i pilastri di design.

Domande aperte

• [Domanda], [chi risponde], [entro quando]

Vedi anche: Game design document · Livelli e contenuti · Design tecnico