Come devo strutturare un documento di progettazione? [chiuso]


30

Il documento di progettazione dovrebbe essere una linea continua di testo, con frasi reali, più simile a una descrizione dell'intero gioco, o dovrei strutturarlo in punti semplici? Quali sono i vantaggi e ci sono altri modi per strutturarlo?


5
Non che non sia affatto d'accordo con la risposta di Josh, ma 35 minuti dopo con 1 sola risposta è un po 'presto per segnare una domanda come risposta, sicuramente?
Kylotan,

4
Sì sono d'accordo. È possibile sempre cambiare in un secondo momento, ma che è sempre molto deludente per la persona la cui risposta si stanno cambiando lontano da. E più precisamente, a volte la selezione di una risposta scoraggia gli altri dal rispondere da soli, e ciò potrebbe farti perdere una risposta molto migliore della mia.
Josh

OK, welp, deselezionata la risposta. Ma probabilmente lo segnerò di nuovo domani, l'ho trovato davvero utile! A meno che, ovviamente, qualcuno non mi dia qualcosa di ancora più utile;). Grazie per questo suggerimento, non ci ho pensato!
jcora,

Puoi anche consultare questo articolo per ulteriori informazioni sulla struttura del tuo GDD. È davvero un'ottima fonte: active.tutsplus.com/articles/game-design/…
Daniel Sidhion

@Josh il tuo punteggio è l'intimidazione - chi proverà a batterti in una risposta;)
Tim Holt

Risposte:


30

Non ci sono regole o standard di settore; strutturare il documento nel modo che sarà più utile per le persone che lo consumeranno , tenendo presente lo scopo del documento.

Personalmente mi aspetterei che ci siano parti del documento che meglio si adattano all'uso di "frasi reali" per trasmettere la tua idea, così come parti che sono più adatte per essere scritte come un elenco puntato di funzionalità.

Chi è il tuo pubblico? Se sei solo tu, se questo dovrebbe solo aiutarti a focalizzare i tuoi pensieri, fai qualunque cosa funzioni per te. Se lavori con altri, chiedi loro come preferirebbero vedere il documento scomposto e come si aspetterebbero di usarlo.

Mi aspetterei di vedere una descrizione in prosa dei punti salienti del gioco: concetto, stile e sensazione principali. Mi aspetterei quindi di vedere una sezione per ciascuna delle principali funzionalità del gioco.

Non esagerare con dettagli e statistiche, ricorda che un documento di progettazione è in genere qualcosa che si evolverà nel corso della vita del gioco durante la creazione e l'iterazione. Non è pratico pensare che lo scriverai una volta, in anticipo, e sarà perfetto, quindi concentrati su ciò di cui hai bisogno per trasmettere il documento ora e su come puoi trasmetterlo al meglio ai consumatori specifici di quel documento.

Non importa cosa fanno gli altri, vuoi fare ciò che funziona meglio per il tuo team.


un documento di progettazione è al centro di una struttura del gioco. nello stesso modo in cui scrivi uno schema per un libro, l'unica cosa che conta davvero è ciò di cui "hai bisogno" per capire la tua idea e realizzarla. anche se vorrei rafforzare il punto del pubblico previsto e che anche ogni sottosezione potrebbe avere un pubblico diverso, un piano di progetto è per il team / manager, i casi d'uso / ERD sono per i programmatori e le descrizioni delle entità sono per gli artisti. è una delle poche volte in cui puoi scrivere qualcosa che non sembra adattarsi insieme oltre a essere sullo stesso argomento generale.
gardian06,

24

Oltre a ciò che Josh ha detto nella sua risposta, diverse persone hanno condiviso la loro idea di cosa dovrebbe andare in un documento di progettazione del gioco, che può aiutarti a decidere quali aspetti saranno utili nei tuoi documenti. Ricorda che si tratta di designer professionisti e ciò che ha funzionato per loro nel contesto dell'industria dei giochi tradizionali non è necessariamente giusto per te, quindi è utile provare a capire perché usano determinati approcci e scegliere quelli che ti aiuteranno di più .


Ho cercato la documentazione di progettazione del gioco e come farlo. Il tuo primo link è stato fantastico. Funziona davvero bene con 'scoping'. Impostare l'ambito di base del progetto e, con parole grossolane, spiegare ciò che è dentro e fuori l'ambito del gioco.
Wertilq,

5

Ci sono alcune informazioni che vorrei aggiungere: durante la documentazione del progetto reale del gioco (ad esempio: le regole), fornire spiegazioni chiare sul perché stai facendo una particolare scelta di progettazione delle regole.

Una delle cose che è più probabile che dimentichi durante l'implementazione di qualcosa è il motivo esatto per cui hai aggiunto una determinata regola. Inoltre, una delle cose che molto probabilmente farai è aggiungere regole ed elementi di gioco solo perché altri giochi li hanno, non perché il tuo gioco ne ha bisogno .

Aggiungendo una sezione sul motivo esatto per cui esiste un elemento di gioco, ti costringe a giustificare l'uso di tale elemento in termini di progettazione generale del gioco. E in seguito, ti consente di valutare in modo efficace se un determinato elemento sta effettivamente soddisfacendo le esigenze a cui lo desideri. In caso contrario, è possibile rimuoverlo e sostituirlo con qualcos'altro che soddisfa tali esigenze.

Ancora meglio, se scopri che il gioco non funziona e vuoi sostituire più elementi per rendere il gioco più divertente, puoi guardare indietro al tuo documento di progettazione e capire perché scegli quegli elementi e quali nuovi elementi devono realizzare . Se le esigenze del design del tuo gioco cambiano, puoi aggiornare la tua lista di cosa dovrebbero fare gli elementi del gioco.


1

Mi piace il modo in cui l'autore di Level Up usa per scrivere i suoi documenti di design del gioco disegnando molte forme, personaggi ecc.

Consiglio vivamente di dare un'occhiata a questo libro Level Up !: The Guide to Great Video Game Design

Con l'aggiunta di piccoli disegni ai tuoi documenti, gli altri ti presteranno maggiore attenzione e sarai sicuro che leggeranno i tuoi documenti di progettazione


0

La struttura del documento di progettazione del gioco dipende completamente da te, ma quella che creo tende a includere (nota che funziona meglio per i giochi di ruolo o altri giochi basati sulla trama):

Sommario - Molto importante, poiché una volta che hai giochi più complessi dovrai includere un metodo di organizzazione

Descrizione del gioco - Una breve descrizione del gioco, che fornisce alcune descrizioni del gioco, insieme alla piattaforma e altri dettagli importanti

Panoramica della storia : dai una panoramica della trama

Controlli : elenca i controlli che utilizzerai nel gioco

Requisiti tecnici : puoi approfondire la piattaforma qui

Diagramma di flusso del gioco : mostra come si collegano le schermate del gioco

Presentazione : fornisce dettagli sul tipo di telecamera, HUD e altre informazioni che il lettore vedrà

Personaggio giocatore - Fornisci informazioni sul tuo giocatore, come l'aspetto, il retroscena e gli strumenti / armi che può usare

Combattimento - Descrivi come funziona il combattimento (se applicabile)

Livelli di gioco - Fornisci alcuni esempi di livelli

Nemici : dai dettagli sui tuoi nemici (attacchi, sguardi)

Boss - Informazioni su boss specifici

NPC : descrivi gli IA che non attaccano il tuo personaggio

Musica / SFX - Cosa musica e SFX devono essere prodotti

Appendici : inserisci qui lunghi elenchi insieme a script e qualsiasi altra informazione

Puoi anche creare una versione più concisa del documento di progettazione del gioco che si trova su una pagina, contenente le seguenti cose:

Panoramica del titolo e del concetto - Fornisci una breve panoramica di come è il gioco e di cosa faranno i giocatori

Piattaforma : elenca la piattaforma su cui verrà pubblicato il gioco

Punti principali : fornisci le informazioni di base sul tuo gioco, come un FPS, un MMO e una modalità per giocatore singolo

Riepilogo : riepiloga l'eventuale trama

Personaggi : fornisci alcune informazioni sui tuoi personaggi

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.