Vale la pena pianificare prima di saltare nel codice?

Ho sempre pensato che la pianificazione fosse importante per un gioco. Ma non so a che punto. Alcuni mi stanno dicendo di programmare invece di pianificare, ma mi sembra che sia ancora importante perché quando sarai nel codice saprai cosa fare più facilmente dopo. Attualmente sto lavorando a un gioco che avrà molti contenuti, quindi ho deciso di iniziare un documento di progettazione che introduce questi contenuti e, a livello laterale, sto facendo delle prove concettuali per verificare se è possibile farlo. Parti di ciascuna dimostrazione del concetto potrebbero essere utilizzate successivamente nel gioco reale.

EDIT: sto lavorando da solo su questo progetto.

Quindi la mia domanda è: vale la pena pianificare prima di saltare nel codice? Sono ancora interessato a sapere cosa ne pensano gli altri. Perché continuo ad avere un po 'di gente che dice che dovrei programmare invece di pensare .. quindi quale opinione hai su questo?

Hai detto due cose intelligenti nella tua domanda:

1. "codice invece di pensare" - c'è un'intera filosofia che descrive questo: http://gettingreal.37signals.com/toc.php
2. "prove del concetto per verificare se si può fare" - ho visto e ho avuto molte idee che sono diventate impossibili o estremamente difficili da realizzare quando erano quasi finite. A volte non riesci proprio a prevederlo, perché è il tuo ambiente di programmazione (linguaggio, librerie, prestazioni hardware) che ti limita.

Ecco perché dico:

• progettare, ma non creare un enorme documento progettuale se non stai cercando collaboratori o investitori, a meno che non sia divertente per te e lo prendi per una pausa dalla programmazione;
• avere sempre in mente ciò che si desidera ottenere; ogni modulo dovrebbe avere un input e un output progettati; in questo modo puoi facilmente testare il modulo e non avere la sensazione di vagare nella nebbia;
• ricordati di progettare la maggior parte delle volte, poiché la digitazione del codice richiede solo circa il 5% del tempo (almeno digitando il codice finale);
• la programmazione non è una scienza teorica, invece di verificare se qualcosa funzionerà su un pezzo di carta, puoi semplicemente codificarlo e provare; il prodotto finale consiste principalmente nel rendere l'input dell'utente infallibile, l'interfaccia grafica gradevole e la gestione di casi speciali - un test sporco di un'idea può essere fatto immediatamente;
• crea un elenco di cose da fare se hai paura di dimenticare le tue idee
• parla con i tuoi amici delle tue idee, in quanto saranno meno entusiaste e potrebbero avere più esperienza in un campo; una volta ho avuto l'idea di mantenere segreti i parametri dell'unità (in un gioco strategico), ma il mio amico mi ha detto che è una cattiva idea, dato che ha giocato un gioco come questo ed è stata un'esperienza terribile per l'utente.

Sì, ma solo un po ' .

Per la programmazione del gioco, in particolare la programmazione del gioco, è essenziale avere un buon caso d'uso prima di scrivere qualsiasi codice. Ad esempio, cosa dovrebbe fare il giocatore, dove dovrebbe andare e come, come interagisce con il mondo, ecc. Questo può essere uno storyboard abbozzato su carta o uscire da una discussione con un pari ... Questo fa parte del design del gioco e sarà sciocco iniziare a scrivere codice senza nemmeno avere una vaga idea di come dovrebbe essere giocato.

Ma i giochi devono essere creati in modo iterativo . Non puoi creare un'enorme specifica per il tuo gioco e spero che sia divertente giocarci. Hai bisogno di test di gioco regolari per scoprire cosa funziona e cosa no e continuare a ripetere. Più veloce viene eseguito, più veloce può essere testato il design del gioco, migliore sarà il gioco alla fine. Quindi è sempre meglio iniziare a programmare al più presto, da un design del gioco molto non formale, vedere cosa esce e andare avanti.

Una cosa è certa, poiché stai programmando da solo, non hai bisogno di alcun documento o metodologia di progettazione software sofisticato, il codice sorgente è il design.

Alcuni dicono che dovresti programmare invece di pensare? Bene per programmare devi sapere cosa vuoi creare, per sapere cosa vuoi creare devi prima pensare a quello che vuoi avere, quindi devi pensare prima di scrivere;).

E seriamente, probabilmente non hai bisogno di un piano dettagliato all'inizio, ma avere uno schema e / o pietre miliari è sempre vantaggioso - anche per la tua attitudine, quando attraversi le cose come fatto, sarai più incoraggiato a fare di più opera.

Sono necessari sia la programmazione che la pianificazione. Primo piano, quindi codice, ma non pianificare tutto in una volta. Pianifica un core, codificalo, aggiorna il tuo piano secondo necessità, quindi pianifica le funzionalità che si aggiungono a giocabilità, grafica, suoni, sprite ecc. Puoi eseguire un ciclo del genere più di una volta, ovviamente, e ti consiglio di prendere decisioni che sosterranno l'upscaling in caso di necessità.

Devi sapere dove stai andando prima di scrivere codice e scrivere / disegnare può essere un buon modo per materializzare ciò che vuoi ottenere. Dico disegnare perché disegnare diagrammi, schizzi ecc. Può anche aiutarti molto. Non è necessario creare un documento meraviglioso realizzato con Word o altro, basta prendere una matita e un pezzo di carta (molti pezzi di carta?) E disegnare, scrivere tutto ciò a cui potresti pensare.

Per me, è una buona pratica usare carta e matita, aiuta a materializzare le tue idee e anche a stabilire dove vuoi andare per evitare di andare ovunque, a fissare il tuo obiettivo. Funziona per tutto ciò che ha bisogno di riflessione. Ed è ovvio in molti domini scrivere le cose prima di fare il vero lavoro.

Fai tutto ciò che funziona per te. Personalmente, pianifico le cose in piccola parte, ma non ho documenti di progettazione sono piani estremamente dettagliati prima di iniziare a scrivere qualcosa. Fai quello che è più produttivo per te, soprattutto perché lavori da solo.

(Suppongo che la domanda sia fatta dal punto di vista della progettazione del codice / dell'architettura, non di quella della progettazione del gioco, sebbene la risposta almeno in una certa misura si applichi ad entrambi.)

Come già detto, hai bisogno di entrambi e devi bilanciarlo. Sia la sovrascrittura che la sotto-progettazione del flusso / struttura del codice possono causare problemi. È difficile dire quale sia il giusto equilibrio, ma generalmente trovo che ho bisogno di avere almeno una vaga idea di come il resto del codice si unirà a ciò che sto programmando in questo momento e pensare a possibili problemi, altrimenti tendo a "codificarmi in un vicolo cieco" - entrare in una situazione in cui mi rendo conto "ok, ora grazie a come ho risolto questo problema, ho creato un nuovo problema che ha reso l'intera mia precedente soluzione (o anche di più, nei casi peggiori) ) inutile ".

In generale, a mio avviso, puoi giudicare approssimativamente se hai il giusto equilibrio pensando a scenari "what if" come in "what if in seguito (quando tutto sarà completamente implementato nel paradigma simile che sto usando ora) quella parte A deve funzionare in modo leggermente diverso, il che significa che devo rielaborare completamente la parte B che si collega ad essa per adattarsi alle modifiche? ". Se la modifica dell'architettura in una parte non richiede la modifica di più di una o due altre parti e le modifiche non si sovrappongono (ciò significa che a sua volta è necessario modificare anche le parti successive che si collegano alla parte B, quindi le parti che si connettono a loro, ecc.), il codice è suddiviso in compartimenti in un modo relativamente buono.

Ma davvero, questo è qualcosa per cui ti sentirai dopo aver acquisito esperienza. Questo è in parte il motivo per cui tutti danno consigli all'inizio a Gamedev di programmare prima qualcosa che è noto e facile (Breakout / Tetris / Snake) e di farlo completamente, con tutti i menu, i suoni, gli effetti, tutto per renderlo completamente finito - è meglio rovinare un progetto più piccolo, e farlo (sia in modo positivo che negativo) ti aiuterà esattamente a capire fino a che punto si estendono gli effetti delle varie decisioni architettoniche.