Quanto sono dettagliati e / o completi i documenti di progettazione del tuo gioco prima di iniziare un progetto?

Quello che mi chiedo è quanto siano generalmente completi i tuoi documenti di progettazione prima di iniziare l'implementazione di un progetto? Sto parlando di progetti medio-piccoli con un team molto piccolo qui in cui persino l'intero documento potrebbe essere composto da poche decine di pagine.

Inizi con un framework approssimativo e inizi a definire i dettagli mentre inizia l'implementazione?

Completi completamente ogni sezione prima ancora che venga avviata qualsiasi implementazione? In tal caso, quale variazione percentuale hai visto dopo l'avvio dell'implementazione?

Se hai esperienza con uno dei due scenari che ho delineato, mi piacerebbe sentire la tua opinione su quali problemi ha causato quel particolare percorso e quali ostacoli ritieni ti abbiano aiutato a evitare.

Se l'idea di gioco è fortemente basato su qualche concetto di gameplay insolito , ho prototipo che subito da zero, con un progetto precedente come modello. Il 95% delle volte questo porta a rendersi conto che non è divertente come immaginavo, e renderlo divertente richiederebbe più risorse di quante ne valga la pena.

Se nel frattempo sto lavorando a un altro progetto, mi prendo il mio tempo, faccio uno scarabocchio per avere un'idea di come dovrebbe essere il prototipo (cerca di non distrarti dall'arte dello schizzo). Poi lo condivido con gli amici, in parte per vedere se hanno qualche input, ma soprattutto per farmi pensare a cose che non sono ovvie subito (ci sono sempre tonnellate di cose, anche per le persone più intelligenti che pensano alle idee più semplici). Dopo un paio d'ore come questo, scriverò alcuni concetti chiave che devono essere nell'architettura, letteralmente ~ 20 parole. Quindi posso costruire un prototipo quando ho tempo.

Attualmente i miei progetti di gioco sono stati adeguatamente dettagliati prima di iniziare.

Potrò perfezionare la maggior parte delle classi importanti, disegnare alcuni modelli (i disegni sono di solito orribili), fare una descrizione del gioco.

Anche se questo è principalmente dovuto al fatto di avere un lungo tragitto da lavoro, e nient'altro da fare. Preferirei dedicare meno tempo a fare questo, e più tempo alla programmazione, dal momento che la realizzazione di classi che probabilmente cambieranno sembra eccessiva.

Lavorando su piccoli team in piccoli giochi (squadre individuali su piccoli giochi casuali), sono passato dal "design pesante" al "design rapido". Trovo che lo sviluppo iterativo (due settimane focalizzate su un singolo obiettivo, ad esempio il gameplay di base) aiuta a dare forma al design e ti dà qualcosa da giocare, il che significa che non cambi idea e invalidi il 90% di ciò che hai progettato che sembrava buono "sulla carta" ma non in-game.

Detto questo, dedico la maggior parte del mio tempo di progettazione al gameplay e alla meccanica di base (come funzionerà il gioco principale), e ciò cambia raramente molto - diventa ritocchi e a volte raccolgo nuove idee o rilasso vecchie idee; ma nulla può andare senza un prototipo funzionante.

Dal punto di vista tecnico, qualsiasi cosa dovrebbe prendere almeno qualche minuto di riflessione prima di rendere reale il codice. Ma puoi sempre refactoring più tardi.

La documentazione di progettazione ha un costo di mantenimento; quando le cose cambiano devi tornare indietro, rileggere e aggiornare tutti i documenti esistenti. In quanto tale, dovrebbe essere un obiettivo di produzione ridurre al minimo la quantità di documentazione gestibile perché ciò massimizzerà il tempo impiegato a costruire il gioco.

Da lì, ne consegue che non vuoi progettare tutto nei minimi dettagli in anticipo, perché sai bene che metà di esso cambierà, e quindi dovrai affrontare un sacco di tempo perso. Esegui il design minimo necessario per iniziare a creare il gioco principale. Al termine, iterare secondo necessità, quindi ripetere il processo per ogni nuova funzionalità.