Game design document
Un game design document (documento di progettazione giochi), spesso abbreviato con l'acronimo GDD, è un documento di software design in continuo aggiornamento e estremamente descrittivo usato nella progettazione e nel design di videogiochi. Un GDD viene creato e modificato dal team di sviluppo e viene utilizzato principalmente nel settore dei videogiochi per organizzare il lavoro del un team di sviluppo. Il documento viene creato dal team di sviluppo come risultato della collaborazione tra designer, artisti e programmatori come guida attraverso il processo di sviluppo del gioco. Quando un gioco viene commissionato da un editore (publisher), il documento deve essere creato dal team di sviluppo e viene spesso allegato all'accordo tra editore e sviluppatore; lo sviluppatore deve aderire al GDD durante il processo di sviluppo del gioco.
Un game design document (documento di progettazione giochi), spesso abbreviato con l'acronimo GDD, è un documento di software design in continuo aggiornamento e estremamente descrittivo usato nella progettazione e nel design di videogiochi.[1][2][3][4] Un GDD viene creato e modificato dal team di sviluppo e viene utilizzato principalmente nel settore dei videogiochi per organizzare il lavoro del un team di sviluppo. Il documento viene creato dal team di sviluppo come risultato della collaborazione tra designer, artisti e programmatori come guida attraverso il processo di sviluppo del gioco. Quando un gioco viene commissionato da un editore (publisher), il documento deve essere creato dal team di sviluppo e viene spesso allegato all'accordo tra editore e sviluppatore; lo sviluppatore deve aderire al GDD durante il processo di sviluppo del gioco.
Vita di un GDD
[modifica | modifica wikitesto]Gli sviluppatori di videogiochi possono creare il GDD nella fase di pre-produzione del gioco, prima o dopo la presentazione.[5] Prima di una presentazione (pitch), il documento può essere concettuale e incompleto. Una volta approvato il progetto, il documento viene espanso dallo sviluppatore di modo che possa guidare il team nello sviluppo.[1][6] A causa dell'ambiente dinamico dello sviluppo di giochi, il documento viene spesso modificato, rivisto e ampliato man mano che lo sviluppo avanza e vengono esplorati i cambiamenti nella portata e nella direzione. In quanto tale, un GDD viene spesso definito come un "vivo", ovvero un testo che viene continuamente migliorato durante l'implementazione del progetto, a volte persino con frequenza giornaliera.[2][7][8][9] Un documento può iniziare con un'idea del concetto di base e diventare un elenco completo e dettagliato di ogni aspetto del gioco entro la fine del progetto.
Contenuto
[modifica | modifica wikitesto]Un GDD può essere fatto di testo, immagini, diagrammi, concept art o qualsiasi altro supporto applicabile e media per illustrare meglio le decisioni di progettazione. Alcuni documenti possono includere prototipi funzionanti o il motore di gioco (engine) scelto per alcune sezioni del gioco.
Sebbene considerato un requisito da molte aziende, un GDD non ha un formato standard. Ad esempio, gli sviluppatori possono scegliere di mantenere il documento come semplice formato word offline o come strumento di collaborazione online.
Struttura
[modifica | modifica wikitesto]Lo scopo di un documento di progettazione del gioco è di descrivere in modo inequivocabile gli argomenti di vendita (selling points) del gioco, il pubblico di riferimento, il gameplay, l'arte, il level design, la storia, i personaggi, l'interfaccia utente, le risorse (assets), ecc.[10][11] In breve, ogni parte del gioco soggetta a sviluppo deve essere inclusa dallo sviluppatore in modo sufficientemente dettagliato da consentire agli addetti di implementare tali componenti.[12] Il documento è appositamente diviso in sezioni di modo che gli sviluppatori possano fare riferimento e aggiornare le parti pertinenti.
La maggior parte dei documenti include o una variazione delle seguenti sezioni:[13][14]
- Storia
- Personaggi
- Level design / ambientazione
- Gameplay (meccaniche e giocabilitá)
- Arte
- Suono e musica
- Interfaccia utente, controlli di gioco
- Accessibilità
- Monetizzazione
Questo elenco non è esaustivo né applicabile a tutti i giochi. Alcune di queste sezioni potrebbero non apparire nel GDD stesso, ma verrebbero incluse in documenti supplementari.
Note
[modifica | modifica wikitesto]- ^ a b Oxland 2004, p. 240.
- ^ a b Brathwaite, Schreiber 2009, p. 14.
- ^ Bates 2004, p. 276.
- ^ Bethke 2003, pp. 101-102.
- ^ Moore, Novak 2010, p. 70.
- ^ Bethke 2003, p. 103.
- ^ Oxland 2004, pp. 241-242, 185.
- ^ Moore, Novak 2010, p. 73.
- ^ Bethke 2003, p. 104.
- ^ Bates 2004, pp. 276-291.
- ^ Bethke 2003, p. 102.
- ^ Bethke 2003, p. 105.
- ^ Oxland 2004, pp. 274-186.
- ^ Adams, Rollings 2003, pp. 569-570, 574-576.
Bibliografia
[modifica | modifica wikitesto]- Ernest Adams e Andrew Rollings, Andrew Rollings and Ernest Adams on game design, New Riders Publishing, 2003, ISBN 1-59273-001-9.
- Bob Bates, Game Design, 2ndª ed., Thomson Course Technology, 2004, ISBN 1-59200-493-8.
- Erik Bethke, Game development and production, Texas, Wordware Publishing, Inc., 2003, ISBN 1-55622-951-8.
- Brenda Brathwaite e Ian Schreiber, Challenges for Game Designers, Charles River Media, 2009, ISBN 1-58450-580-X.
- Michael E. Moore e Jeannie Novak, Game Industry Career Guide, Delmar, Cengage Learning, 2010, ISBN 978-1-4283-7647-2.
- Kevin Oxland, Gameplay and design, Addison Wesley, 2004, ISBN 0-321-20467-0.
Collegamenti esterni
[modifica | modifica wikitesto]- Anatomia di un GDD di Tim Ryan su Gamasutra
- Specifiche di gioco di Tom Sloper su Sloperama
