Come si fa a fare un gioco? [chiuso]

Il mio problema è che ogni volta che inizio a programmare un clone di un gioco (per esercitarmi) o il mio gioco o qualche altro problema, mi fermo da qualche parte nel mezzo dello sviluppo, perché ho perso interesse in esso.

Come mantieni l'interesse per lo sviluppo di un gioco o lo sviluppo in generale?

Come designer, tendo a pensare alle persone come raccolte di statistiche e variabili. Quando poni la tua domanda, posso facilmente immaginare [Pong_Dev_Interest] in diminuzione e [Spa_Inv_Dev_Interest] in aumento. Quando la differenza tra i due è maggiore di [Dev_Project_Inertia] (in qualche modo correlato a [Dev_Completion_Desire]), l'attività su [Pong_Dev] si interrompe e inizia [Spa_Inv_Dev].

In inglese: non riesci a completare il progetto perché il tuo desiderio grezzo di vedere un prodotto finito è annullato dalla tua mancanza di interesse per il progetto attuale. Se vuoi davvero finirne uno, l'unica soluzione è sceglierne uno (andrei con il tuo clone di pong) e finirlo . Di 'a te stesso "Sé, so che forse avrei potuto perfezionare quel clone un po' di più, ma diamine, è sicuro che è bello dare il via a un progetto fuori dalla porta". Quindi continua a lavorare.

Quando sei annoiato, continua a lavorare. Quando sta andando alla grande, continua a lavorare. Quando cade a pezzi, continua a lavorare! Perseverare! Sii il piccolo Dev che potrebbe! Ho fiducia in te!

Ahem. È diventato un po 'esagerato lì. Ma ottieni la deriva.

Seguo il mio consiglio ogni giorno. Ho fatto funzionare il mio ambiente e gli attori, costruito nelle mie condizioni di vittoria e sconfitta e creato gli oggetti che il giocatore utilizzerà. Sono praticamente pronto per iniziare a fare un po 'di design di livello e il mio interesse è cresciuto. Ma ne faccio alcuni ogni giorno. Tutti i giorni Un giorno avrò finito.

E sembrerà così bello.

Mi pongo sempre la stessa domanda e ci sono un paio di cose che puoi fare per motivarti (molte già pubblicate qui). Ciò che funziona bene per me è qualcosa che ho sentito in uno degli Indie Talks al GDC di quest'anno, penso che sia stato il ragazzo a fare il gioco di Monaco :-)

Innanzitutto, trova un progetto che rientri nella tua esperienza. Cioè non iniziare a fare un FPS se non si conoscono nemmeno le basi di OpenGL / DirectX. (a meno che tu non stia utilizzando un motore di gioco ma non è questo il punto qui ;-))

Quindi, renditi un elenco di cose da fare e pietre miliari che ti piace raggiungere, in modo da sapere sempre dove andare. I TODO sono la parte importante. Definisci le tue attività in modo tale che ogni attività possa essere eseguita facilmente in un giorno o in un paio d'ore . Quindi, quando inizi a programmare, progettare, modellare ecc., Vedi già la luce alla fine del tunnel. Niente è più deprimente della progettazione e codifica del tuo grande Game Engine per un mese senza avvicinarsi al traguardo. Suddividere i compiti più grandi in quelli più piccoli. Completare rapidamente un'attività è davvero gratificante e ti fa andare avanti. Ad esempio, questo era il mio elenco di attività per un gioco sparatutto spaziale contemporaneamente:

• Effetti sonori
• Musica
• Rimodellare la nave
• Rimodellare i razzi
• Rilevamento di Colission tra colpi e giocatore / nemico
• Fai sparare ai nemici
• Schermata del titolo
• Punteggio / Vite / Energia Qualunque sia la sovrapposizione

Tutti questi compiti erano facili da svolgere e una volta che funzionano nel gioco, puoi iterare su quelle aree e lucidarle.

Ehi, ho finito un piccolo gioco. Non è carino ma in pratica è stato davvero gratificante alla fine :-)

Devi identificare il problema prima di poterlo risolvere. Perché perdi interesse?

Per me, di solito succede perché sto trascorrendo così tanto tempo sul framework e, dopo settimane, non sono nemmeno riuscito a ottenere un singolo elemento di gioco.

Un modo in cui trovo per migliorare la mia motivazione è fare prototipi iterativi o una qualche forma di sviluppo guidato dai test. Di solito ciò comporta l'automazione dei casi di test, ma poiché i giochi richiedono molta grafica, non è possibile automatizzare schermate e animazioni come test, ma la logica del gioco potrebbe essere automatizzata.

Per le parti che non possono essere automatizzate, fondamentalmente pianificherò un paio di pietre miliari per il gioco. Milestone 1 probabilmente sarebbe rendere uno sprite sullo schermo e far funzionare WASD, per esempio. A poco a poco, aggiungerò più funzionalità e refactor.

È una forma di divisione e conquista. Rompi in piccoli pezzi, lavora su quello con cui ti senti a tuo agio, quindi integra. Risciacqua e ripeti. Alla fine potresti vedere un modo migliore di riorganizzare le cose e puoi riformattare il tuo codice. È disordinato non avere un'architettura in primo piano, ma di solito quando si inizia a programmare è difficile visualizzare l'architettura fino a quando non si ha qualche anno di esperienza.

Cerco di trovare alcune parti più facili da realizzare. Come se non riuscissi a capire come fare qualcosa o non volessi farlo, cambio marcia e modella o scrivo uno shader, ecc.

Vedi questo e questo altro post.

Se non sai come strutturare correttamente un gioco, dovresti iniziare a imparare come astrarre i loro elementi in blocchi indipendenti dal gioco. Questo può aiutarti in molti modi (oltre ad essere interessante), come ad esempio: esperienza nel dividere le astrazioni dalle implementazioni, un migliore sfruttamento dell'ereditarietà e del design dell'interfaccia, o semplicemente come mettere il gioco in più file per renderlo professionale (o fornire una flessibilità delle implementazioni mediante l'uso di librerie a collegamento dinamico o altri usi dell'interfaccia). Prima o poi ti renderai conto che tutto può essere fatto e poi ti ritroverai più senza quel problema di motivazione (lo fai e basta).

Ho avuto lo stesso problema quando mi sono bloccato all'inizio, ma la soluzione migliore è quella di continuare a muoverti, oppure puoi fermarti per sempre finché qualcosa non ti ripristina in qualche modo (e potrebbe richiedere troppo tempo). Non importa se un giorno digiti solo 2 righe, ma ogni giorno devi almeno aprire il progetto e provare a migliorare qualcosa (è un compito infinito, ma non è questo il problema).

Se a un certo punto il programma non funziona, dovresti annullare ciò che hai fatto per ultimo (mantieni un backup usa uno svn o almeno un .rar con il nome della data) fino a quando ha funzionato, e prova a farlo di nuovo o lavorare su altre modifiche che è necessario apportare fino a quando non si desidera riprovare.

All'inizio dovresti provare a correggere l'errore con l'aiuto del debugger, ma non so se la tua lingua supporta anche un debugger ... ma se per caso usi C ++ o qualcosa del genere (che consiglierei se tu vuoi creare giochi), dovresti utilizzare meglio il tuo debugger in quanto ti aiuterà molto a trovare rapidamente l'errore in una singola corsa.

Leggere sulla programmazione del gioco è anche una buona cosa da tenere sull'argomento se non si desidera lavorare su qualcosa in particolare. Ci sono alcuni buoni libri e articoli sui motori di gioco e sul design che puoi trovare online.

Non sarai in grado di fare nulla se non ti eserciti. Cercare di trovare un bug all'inizio può essere molto frustrante, ma poi apprendi che in realtà è facile se sai come farlo. Questo è qualcosa che impari a evitare con il tempo, codificando in modo tale che le modifiche non influiscano sull'intero programma, diminuendo la quantità di posizioni in cui cercare l'errore. Se ogni volta che diventa difficile ti arrendi, allora ogni volta che pensi di fare un gioco ti arrenderai prima di iniziare. Basta imparare a superare il brutto momento superandolo: P Se non passi quel momento in cui perdi motivazione, la tua pigrizia vincerà e perderai, ecco come funziona, fino a quando non impari a ritrovare la motivazione senza troppi sforzi.

PS Mi stavo chiedendo ... cosa stai usando per fare il gioco?

[voleva essere lasciato come commento alla risposta di Anon, che è stata cancellata mentre l'ho pubblicata. Ha detto che aveva tutte queste funzionalità funzionanti, quindi ha diviso il codice del singolo file in più file, solo perché tutto cadesse a pezzi]

Ri: refactoring, possono succedere cose, anche ai professionisti. A volte anche con buoni strumenti come Git, un'unione può fallire, quindi invece che la funzione A e la funzione B funzionano entrambe, non funzionano! L'unica scelta è tornare ad A e riprovare. Fortunatamente il controllo della versione salverà questo codice per te; se non usi il controllo della versione reale, almeno fallo manualmente comprimendo regolarmente la tua cartella dev - lo spazio HD è economico! In conclusione, torna a ciò che funziona e rifletti in passaggi più piccoli, assicurandoti che il gioco funzioni ancora ad ogni passaggio. È davvero deprimente ripulire il codice solo per vedere tutto a pezzi. Torna al vecchio codice.

Per rimanere motivati, continua a dirti che stai creando un gioco, non un motore di gioco - beh, a meno che non sia il tuo genere. Ed è bello, i motori di gioco sono fantastici, ma troppo spesso ostacolano la creazione di giochi.

Per illustrare il mio punto, posso dirti come vanno spesso le cose: all'inizio crei alcuni sprite, spostali sullo schermo con il tuo proto-framework e sei elettrizzato! Puoi vedere i tuoi progressi e sta andando bene; puoi mostrare ai tuoi amici.

Quindi, una volta che hai giocato un po 'con il tuo concetto, ti rendi conto che devi rendere il tuo framework (o motore di gioco) più flessibile. O che dovresti ricodificare alcune classi che non seguono gli schemi più recenti. E da lì, ti avventuri in una spirale di morte: smetti di lavorare su un gioco e inizi a lavorare su un motore di gioco. E i motori di gioco non sono altrettanto divertenti da realizzare. Puoi passare ore a eseguire il refactoring e non hai nulla da mostrare per questo - nel gioco. E poi, perdi interesse.

Quindi, ricorda: crea giochi, non motori di gioco. Rifattore solo quando è necessario. Non essere troppo flessibile - solo il minimo indispensabile. *

*: ovviamente il refactoring e la flessibilità sono importanti. Ma non è importante quanto avere un gioco finito.

Prova a creare una versione giocabile in un giorno, non importa quanto sia semplice. Quindi iterare.

1. Non cercare di rendere il tuo gioco troppo complicato!

2. Dividi il tuo compito in attività secondarie piccole, specifiche e misurabili. Se una sottoattività sembra troppo grande, allora suddividila ulteriormente.

3. Assicurati di scrivere "FATTO" a grandi lettere nell'elenco delle attività (utilizzo un file .txt) al termine dell'attività. Non rimuovere l'attività, perché non sembrerà che tu stia facendo progressi.

Questo è ciò che faccio. Ha funzionato in passato.