Share
Ogni sviluppatore o team indipendente si è chiesto come meglio gestire il processo di sviluppo. È obbligatorio utilizzare la documentazione dettagliata, come il leggendario documento di progettazione del gioco (GDD)? Quali sono gli errori più comuni e come possono essere evitati?
Per coloro che hanno cercato risposte a queste domande, voglio condividere l'esperienza del nostro team nel creare il nostro GDD.
Molti game designer si astengono dal coltivare documenti di design e idee organizzative. Non riesco a immaginare come questi sviluppatori riescano a superare quei momenti in cui sono ostacolati da codice malfunzionante, arte di segnaposto e meccaniche che si scontrano, il tutto cercando di ricordare perché è stato il primo a sottoporsi a fare un gioco in primo luogo.
Avere un ben progettato documento di progettazione del gioco può fungere da stampella in questi tempi. Ti permetterà di vedere le fantastiche idee e concetti che ti hanno tenuto sveglio tutta la notte quando hai iniziato il gioco e, forse ancora più importante, quali devono essere tagliati dal gioco per rendere la tua vita più facile, o rielaborati per renderti i tuoi sforzi ne valgono la pena.
Un documento di progettazione del gioco funge da nesso e hub per collegare ed elencare ogni aspetto di un gioco. Consiste in descrizioni scritte, immagini, grafici, grafici e elenchi di informazioni pertinenti a ciascun segmento di sviluppo, ed è spesso organizzato in base a quali caratteristiche saranno presenti nel gioco, e illustra chiaramente come si integreranno tutte insieme.
La creazione di un GDD aiuterà il designer del tuo team a capire qual è l'essenza del gioco e lo scopo pianificato del suo mondo e gameplay. Inoltre, avere tutti gli elementi del gioco in un documento ben organizzato aiuterà il progettista a trasmettere facilmente la propria visione al resto della squadra, contribuendo anche a individuare punti deboli o componenti mancanti che il gioco potrebbe richiedere.
Il GDD dovrebbe fungere da elenco di controllo principale. Sarà il documento che salterai in aria per festeggiare completando tutte le sue sezioni e finendo il tuo gioco.
Dal momento che un GDD è pieno di descrizioni, è una risorsa ideale per tutti i PR e i fronti di marketing, con concetti che trasmettono l'estetica e l'appeal del gioco già scritti e pronti per copiare e incollare.
Le capacità dei potenziali dipendenti possono essere rapidamente valutate come qualificate o meno guardando le loro credenziali accanto alle corrispondenti sezioni delle loro posizioni nel documento.
Se la raccolta di fondi è nelle carte per la tua squadra, sarà cruciale avere un GDD ben congegnato per consentire agli investitori di esaminare e determinare i rischi del tuo sviluppo, così come la tua capacità di mantenere le tue promesse.
Creare e aderire a un documento di progettazione del gioco è come piantare un seme e guardarlo crescere in un albero nel corso dello sviluppo. Avete la vostra preparazione iniziale, la coltivazione e, in definitiva, la fatica macabra e massacrante della mietitura.
Un errore comune non è quello di consegnare a tutti i membri del tuo team gli strumenti di giardinaggio appropriati per rendere il tuo gioco realtà. Il GDD contribuirà a far sì che tutti lavorino insieme, in modo da non trovare il programmatore e l'artista che tagliano il ramo su cui si trovano.
Cercando di descrivere tutto in una volta
Non è necessario elencare dettagliatamente tutte le funzionalità e il meccanismo nella prima bozza. Questo è impossibile quando si lavora su un gioco complesso con una piccola squadra. Delineare i nodi principali del gameplay e degli elementi centrali ti aiuterà a darti una prospettiva su ciò che deve essere fatto, ma dovresti aspettarti di riempirli uno per uno, nel tempo.
Definire obiettivi di gioco con scadenze può sembrare scoraggiante per alcuni sviluppatori. Le scadenze fanno parte del noioso stile di vita 9 a 5, quindi molte persone hanno una naturale avversione per loro.
Tuttavia, l'impostazione delle scadenze è il modo in cui ti assicuri che il tuo gioco venga realizzato e non resti per sempre incompiuto in una cartella sul desktop. Questi tipi di obiettivi sono pietre miliari sulla strada del progresso e passarli uno per uno è una chiara indicazione che stai facendo qualcosa di giusto. Ognuno è motivo di festa.
Le scadenze sono una componente fondamentale della programmazione che ti aiuta a monitorare le prestazioni della tua squadra e te stesso. Aiuta a prendere decisioni che sono radicate nella realtà, e alla fine crea uno slancio e un'etica che è salutare per la squadra nel suo complesso e gli individui al suo interno.
C'è spazio nella GDD per le descrizioni di base che riguardano il gameplay, le trame e le principali attività di codifica. Mentre lo sviluppo avanza, aggiungi ulteriori dettagli a queste sezioni. Durante la creazione e il test del gioco, è necessario aggiungere o aggiornare dettagli tecnici specifici ogni volta che una funzionalità viene implementata o modificata. In questo modo, non avrai mai una build con elementi che non puoi risalire al GDD, creando collegamenti mancanti di idee, codice o arte. Può anche essere utile aggiungere informazioni sulla difficoltà di implementare determinati compiti e se sono stati completamente integrati nel gioco o potrebbero richiedere ulteriori revisioni.
Durante tutto questo processo, i tuoi concetti iniziali dovrebbero gocciolare in descrizioni sempre più dettagliate di ogni sfaccettatura contenuta nelle tue funzioni. Questo aiuta a fare traguardi concreti facili da navigare e tornare indietro per vedere dove sono originati e dove devono andare.
Dato che il GDD continua a crescere e diventare più finalizzato, è comunque importante tenerlo aggiornato. Ciò elimina le situazioni in cui i membri del team fanno qualcosa senza essere in grado di giustificare il motivo per cui hanno trascorso del tempo a eseguirli, il che è cruciale nel momento cruciale.
Personalmente, ho una paura inspiegabile di annegare in un mucchio di documentazione stampata. Questo diventerebbe un vero incubo se dovessi mantenere tutte le vecchie versioni del nostro GDD per ogni membro del team.
Perché dovremmo torturarci in questo modo nell'era della tecnologia digitale? Ci sono molti servizi online gratuiti come Google Docs o Trello che ti permettono di salvare tutte le modifiche e vedere tutti i commenti della tua squadra in tempo reale.
Quando si avvia il GDD, è normale essere avvolti nei concetti. Gli sfondi, le introduzioni e le descrizioni chiave aiutano a dare forma al gioco e a dargli forma. Quando inizi a testare e implementare le funzionalità, questi concetti dovrebbero diventare più raffinati, specificati e dettagliati. Mantenere una corretta organizzazione diventerà sempre più importante man mano che il tuo GDD guadagna peso e densità.
Inizia nella fase concettuale, in cui fai un brainstorm delle tue idee e le butti giù sulla carta. Questo dovrebbe essere eccitante! Servirà anche come una tabella di marcia in modo da non perdere traccia dei tuoi obiettivi e visione lungo la strada. Quando il fascino di alcuni elementi del gioco perde la sua lucentezza o ti porta in un fosso, potrebbe essere il momento di rielaborare il tuo concetto iniziale per assicurarti di raggiungere un traguardo soddisfacente.
Verso la metà dello sviluppo, una volta che avrai a bordo un team di gung-ho, le discussioni e le build del gioco aiuteranno a scolpire e organizzare il documento in una guida facile da usare e pesante per tutti. C'è ancora spazio per sperimentare nuovi concetti e idee a questo punto, ma dovrebbero essere tenuti sotto controllo con parte della documentazione iniziale.
La fase iniziale dello sviluppo è dove il tuo documento di progettazione del gioco ti farà risparmiare ore di frustrazione e angoscia. Mentre ti avvicini, rilascia il tuo GDD dovrebbe lentamente iniziare a trasformarsi in un tablet di pietra, con funzionalità e meccaniche impostate in build di gioco più permanenti, tutte tenute insieme da un'arte che è stata sicuramente realizzata su più iterazioni per adattarsi alle specifiche del documento. Il documento dovrebbe aiutare a mantenere tutte le ruote del team sul terreno, con una buona visuale sulle aspettative realistiche nel consegnare il gioco.
Non è necessario avere un GDD assolutamente completo prima di iniziare lo sviluppo. Ma il GDD dovere essere completato per i prossimi 10 giorni o due settimane oltre il lavoro corrente della tua squadra e le parti pertinenti del documento devono essere il più dettagliate possibile.
Parti del GDD dovranno essere cambiate e modificate durante l'intero processo di sviluppo, a volte anche negli ultimi giorni prima del rilascio. Può iniziare ad assomigliare ad una zona disastrata se il contenuto non viene ritagliato correttamente. Se hai paura di eliminare il testo che è obsoleto, taglia e incolla il file in un addendum o documento separato. Questo lascerà il corpo principale del GDD rilevante per lo stato attuale di sviluppo, senza tutte le distrazioni delle precedenti iterazioni.
Non interrompere mai i membri del team che inviano nuove idee. La creazione di idee è una delle parti più gratificanti dello sviluppo e dovrebbe essere incoraggiata in ogni momento. I membri del tuo team dovrebbero dirigersi verso lo sviluppo sapendo che molti di questi concetti verranno tagliati e non potranno mai entrare nel gioco, ma questo non dovrebbe impedir loro di sognare! Nessuno sa quali idee produrranno i migliori risultati in un primo momento, quindi generare idee nuove e innovative dovrebbe essere un punto fermo delle discussioni e celebrato di conseguenza.
La supervisione del GDD deve essere eseguita solo da un membro del team. Identificheranno le idee chiave su cui concentrarsi e taglieranno le idee meno importanti.
Incoraggiare un feedback attivo è importante, quindi, perché gli altri membri del team non hanno la possibilità di aggiungere direttamente le loro idee al documento.
La maggior parte dei problemi di sviluppo sono costituiti da un involucro esterno difficile di comunicazione e da un interno morbido che non sa come compensarli e correggerli. Queste barriere possono essere eliminate con un vigile mantenimento del GDD e una documentazione chiara e concisa, e ciò può essere realizzato al meglio se una persona assume tale responsabilità.
Essere coerenti con gli stili dei caratteri e utilizzare intestazioni uniformi e indentazioni, punteggiatura e formattazione. Creare una legenda o una chiave per spiegare quali specifici evidenziatori colorati significano andare molto lontano nel ridurre la confusione e ridurre il tempo necessario per trasmettere le fasi dell'implementazione di diverse caratteristiche.
Più è semplice e chiara la lingua nella GDD, migliore sarà la tua squadra a comprenderla.
È importante mantenere la scrittura chiara e concisa e il tuo team dovrebbe darti un feedback attivo sulla presentazione e la chiarezza del GDD. Una dinamica avanti e indietro si tradurrà in un'esperienza di sviluppo più coesa, con benefici generali tra cui uno stile artistico definito, meno errori di comunicazione e meno stressante documentazione e lavoro d'ufficio.
Ma soprattutto, il GDD dovrebbe essere un riflesso della cultura della tua squadra, creato in qualsiasi formato trovi che funzioni meglio e sia più attraente per te e per coloro con cui lavori.
Nessuno dovrebbe mai essere in grado di dire di non aver capito qualcosa, o di aver fatto qualcosa correttamente, a causa della mancanza di materiale di riferimento nel GDD.
I materiali visivi e i riferimenti svolgono un ruolo chiave nel processo di trasmissione delle idee. Alcuni concetti difficili possono essere spiegati in meno tempo con aiuti visivi come grafici e concept art. Ciò contribuirà a garantire che ogni membro del team comprenda le informazioni che vengono loro trasmesse, il che in cambio li aiuterà a completare le attività di sviluppo più rapidamente.
Non dovresti limitarti ad asciugare il testo. (Se lo fai, starai aspettando molto tempo prima che tutti si impegnino e capiscano le idee principali!) Prova a descrivere le emozioni dei giocatori e le esperienze che il gioco potrebbe coltivare.
Mantenere un GDD può sembrare tecnico, ma non dovresti aver paura di strapparti il cuore e gettarlo sul documento. Lascia che le tue emozioni e le tue passioni si fondano in esso. Immagina come vuoi far sentire il giocatore, e scrivi quelle aspirazioni insieme alle descrizioni delle tue caratteristiche. Questo aiuta a coltivare una coscienza collettiva nella tua squadra su ciò che il tuo gioco sta cercando di trasmettere al giocatore - e, ammettiamolo, i sentimenti dovrebbero avere entusiasmo dietro di loro se vuoi che siano compresi da chiunque altro.
Definisci le priorità di attività e caratteristiche, documenta le loro scadenze e controlla la loro esecuzione. Non puoi sviluppare assolutamente tutte le idee che la tua squadra e la tua mente propongono, quindi (dopo averne tagliato alcune), devi stabilire le loro priorità e almeno approssimare un programma per la loro implementazione.
Un GDD ben curato costituisce un eccellente elenco di attività prioritarie che devono essere completate dal team. Non tutte le funzionalità di un GDD lo faranno nel gioco finale. Con questo in mente, è necessario decidere quali caratteristiche hanno la precedenza su altre e dovresti programmarle per l'implementazione e il test prima di quelle degli altri.
Pensa bene a ciò che è fondamentale per il tuo gioco, e cosa è possibile dato il livello di abilità della tua squadra, e usa quelle informazioni per guidare la tua produzione.
Un solido GDD può anche aiutare a facilitare il coinvolgimento di nuovi membri del team nel progetto e farli eccitare quanto te.
Dal momento che un GDD completamente delineato può risultare in quello che sembra un gioco eccessivamente scoraggiante da fare, è bene ricordare che più di una persona sarà arricchita con le sue specifiche. Assegnare le attività dei membri del team nel GDD lo aiuterà a diventare più solido mantenendo tutti sulla stessa pagina. Chiunque può accedere al documento e vedere cosa è stato completato, quali attività si trovano davanti a loro e al resto del team e perché stanno lavorando al loro compito corrente.
Scrivere qualcosa in un GDD condiviso non dovrebbe minimizzare o eliminare la discussione con il team, dovrebbe servire ad aumentare la discussione di gruppo e migliorare le tue dinamiche comunicative. È importante che tutti comprendano chiaramente come tu (e gli altri membri del team) immagini ogni caratteristica del gioco.
Tagliare le idee può essere difficile e snervante, ma è un processo innato alla creazione di giochi. Fare in modo che una discussione aperta e libera sia parte dello sviluppo contribuirà ad alleviare le tensioni inerenti qui, senza dissuadere i membri dall'essere creativi.
Ho trovato molte buone idee praticamente a giocare nella mia mente, sia prima che durante la creazione del gioco. Naturalmente, questo non garantisce che quelle idee si radicheranno nel gioco durante lo sviluppo e il testing ma, soprattutto nelle fasi iniziali, è un buon metodo di brainstorming.
Mentre è buono promuovere l'aria di eccitazione all'interno di una squadra, è altrettanto importante mantenere i tuoi obiettivi di gioco incorporati nella realtà. La meccanica e i complessi comportamenti nemici e di livello sono sempre fantastici su carta, ma la realtà ha un modo di corrodere la grandezza di certi elementi di gioco, e questo dovrebbe essere previsto.
Conseguenze di aggiornamenti e modifiche sono quasi impossibili da prevedere in anticipo in alcune situazioni, quindi ricorda che è il tuo lavoro cercare di limitare la quantità di rimodellamento che deve essere fatta quando si verificano cambiamenti. Se fai pratica comune per giocare nuove idee nella tua mente prima di metterle sulla carta, hai una maggiore possibilità di mantenere gli obiettivi di sviluppo radicati in aspettative realistiche.
La nostra squadra è multinazionale. Viviamo in tutto il mondo, in diversi fusi orari, e questo rende impossibile usare le versioni di stampa dei documenti per tutti e difficile avere conversazioni in tempo reale. Utilizzando strumenti come Skype (per le conversazioni), Google Drive (per condividere file), Google Docs (per collaborare ai documenti e condividere il GDD) e FlockDraw (per i disegni digitali) possono davvero aiutare con spiegazioni e discussioni.
Se ti trovi in una discussione sul fatto che mantenere un GDD sia necessario per la produzione del tuo gioco, dovresti dare una buona occhiata a come prevedi lo sviluppo. Ci sono quasi certamente momenti in cui la vita reale e i lavori a tempo pieno si intrometteranno nella creazione di giochi, o la tua implementazione di funzioni e meccaniche semplicemente non funziona.
Nei mari tempestosi dello sviluppo del gioco, un GDD sano può servire come una nave robusta e solida, e persino una scialuppa di salvataggio a volte. È un diario dettagliato delle tue lotte e trionfi, una raccolta di pensieri e idee su cui ricorrere durante i momenti difficili. Potresti scoprire che il miglioramento della qualità del GDD rientra anche nel resto dello sviluppo, aumentando la barra trasversale per la tua squadra. Dovrebbe servire da robusto hub per facilitare la discussione di gruppo e generare idee nuove, ancora più grandi. Allo stesso tempo, può mantenere questi concetti in un controllo realistico.
I benefici di questo tipo di efficienza possono sembrare piccoli se guardati individualmente, ma nel corso del lungo corso di sviluppo, costruiscono un meraviglioso tipo di impulso. In definitiva, questo tipo di documento dovrebbe spingere, costringere e ispirare te e il tuo team a completare ciò che hai iniziato. Dovrebbe mostrarti che il tuo gioco ha un piano che può essere realizzato.
E dopo aver finito il tuo gioco, il tuo GDD rappresenterà una testimonianza di tutto il tuo duro lavoro e impegno, il dietro le quinte di una esperienza elaborata di cui tutti potranno godere.
Accentsconagua