L’analisi del software è divisa in tante nicchie operative, ognuna con le sue peculiarità, per i giochi per esempio il primo documento necessario è il GDD.
Vediamo come è composto e cosa si propone, ricordando sempre che è noioso e “nessuno legge i GDD”.
Cos’è un GDD?
Un GDD è un documento preliminare, che serve da progetto per un gioco. Aiuta a definire scopi e meccaniche di gioco, vision e direzione del progetto, informando tutto il team di quella che dovrà essere la volontà comune.
Un GDD include (almeno) queste parti:
- Sommario (game concept, genere, target, ambito di applicazione)
- Gameplay (obbiettivi, livelli, GUI, etc.)
- Meccaniche di gioco (regole, sistema di combattimento, fisica, etc.)
- Elementi di gioco (scene, storie, personaggi, ambientazione e luoghi, level design, etc.)
- Assets (musica, suoni, modelli 3D e 2D, etc.)
Anche i GDD sono diventati Agile con il tempo, quindi non create un documento di 100 pagine con tutto lo scibile umano sul gioco in esso contenuto, lavorate col team e fate progredire il GDD e l’idea del gioco con lo sviluppo dello stesso.
Come scrivere un GDD
- Riassumi qualsiasi cosa: il documento deve risultare leggibile in massimo 15 minuti.
- Scrivi il GDD insieme a tutto il team, salteranno fuori idee nuove e i problemi saranno eviscerati prima di cominciare lo sviluppo.
- Come in tutte le cose Agile, è un documento in evoluzione: non è una bibbia per cui litigare.
- Arricchisci il documento con grafici, concept, flow-chart e qualsiasi cosa renda il documento comprensibile ad un bambino.
Vuoi un esempio? Ne troverai migliaia in rete, mi sento di consigliartene uno iconico:
