Risposte:
Prototipo. Prova a implementare il tuo concetto di gioco usando una sorta di strumento di iterazione rapida. Prova Python o semplicemente qualche API open source facile da usare per far funzionare la tua "idea di gioco". Cerca di semplificare il più possibile, usa le palle invece dei personaggi, abbassa la visione su una sorta di rappresentazione visiva. In questo modo puoi sempre guardarlo, discuterne, discuterne e dare feedback. Inserisci una sequenza temporale per ogni prototipo (forse 2 giorni? Forse una settimana in cima?). In questo modo puoi solo fare tutto ciò che vuoi nel prototipo.
A volte potresti essere in grado di tracciare la tua idea su un piccolo pezzo di carta se è abbastanza semplice. Una volta che hai impostato la tua idea, inizia a pianificare per vedere che tipo di sistemi e meccanici ti servono. Prova a strutturare le linee temporali per le cose e vedi se è possibile impegnarle. Se sei un gruppo di persone che vogliono fare un gioco insieme, devi farlo insieme. Fallo con una birra, di persona o usando un programma di chat vocale. Una volta che sai cosa fare, tutti possono iniziare con quello che stanno facendo. Assicurati di avere una comunicazione. Cerca di tenere un incontro di gruppo con un intervallo frequente a seconda di quanto tempo vuoi dedicare.
Se stai realizzando il tuo gioco, ricorda che il tempo è limitato e non puoi fare tutto abbastanza. Forse sfere e cubi saranno sufficienti per far funzionare la tua grafica se sei un programmatore. Realizza i tuoi limiti e lavora con loro piuttosto che contro di loro.
Spero che questi pochi consigli siano di aiuto :)
Come insegnante, vedo molti progetti di hobby per studenti che falliscono. Invariabilmente, il singolo motivo più elevato di fallimento è l'overcope: il progetto inizia come questa grande visione di una cosa enorme che è troppo grande per essere eventualmente completata, sempre più persone vengono portate avanti fino a quando non collassa sotto il peso del proprio design, e tutti lascia frustrato e demoralizzato.
Il miglior rimedio per questo è limitare il tuo ambito spietatamente. Invece di dire "come posso mantenere la mia energia sufficiente per finire un lungo progetto?" dovresti invece dire "come faccio a progettare un progetto che sia abbastanza corto da poterlo finire prima di annoiarmi?"
Gli eventi "Game Jam" (cose da fare in un fine settimana) sono un ottimo modo per iniziare e sono ottimi per costruire buone abitudini quando si realizzano prototipi rapidi. In WORST, trascorri un fine settimana a fare un gioco schifoso ... probabilmente hai imparato qualcosa nel processo ... E ti sei risparmiato mesi lavorando su un'idea che alla fine non è stata bella come pensavi inizialmente. Nel migliore dei casi, scopri che hai qualcosa di veramente speciale e puoi iniziare ad aggiungere piccole funzionalità una alla volta fino a quando non hai un progetto completo.
Nei miei piccoli progetti di hobby, l'altra cosa che ho trovato che aiuta è iniziare con un elenco completo di tutte le attività di sviluppo conosciute che devono essere eseguite, ordinate e ridimensionate in modo che ogni singola attività sia realizzabile e verificabile in forse 30 a 60 minuti, al massimo. È molto energico fare un piccolo compito, vederlo funzionare nel gioco e cancellarlo dall'elenco ... il che poi rende tutto ciò molto più probabile che farò la prossima cosa sull'elenco poiché l'ultimo era così facile, e poi il prossimo ... un po 'come mangiare patatine.
Un altro suggerimento: ogni volta che si implementa con successo una nuova funzionalità, eseguire un backup (o utilizzare il controllo del codice sorgente, che è fondamentalmente la stessa cosa, ma non tutti usano il controllo del codice sorgente se sono solo loro a lavorare sul proprio progetto personale). In questo modo se rovini completamente il codice alle 2 del mattino e non riesci a capire come ripristinarlo in uno stato funzionante, il progetto non è morto e non deve essere riavviato da zero; invece, è sufficiente tornare indietro all'ultima pietra miliare completata e funzionante e riprovare.
Direi che la cosa veramente importante è avere sempre qualcosa da mostrare.
Voglio dire, potresti passare anni e anni in un sistema di entità guidato dai dati, con rendering differito e FPS davvero elevato, e tutto il resto. Ma è probabile che ti annoierai di non avere nulla da mostrare e rinunciare. Considerando che, se prima provi a ottenere alcuni modelli sullo schermo, spostali e vai da lì, avrai molte più possibilità.
Penso che il primo sia lo sviluppo dal basso; lavorando da un framework fino al contenuto effettivo, e il secondo è top-down; lavorando per ottenere alcuni contenuti e costruire da lì.
Un piccolo punto, ma qualcosa che aiuta davvero.
Come sviluppatore solitario, trovo che aiuti a implementare presto il suono. Trovo che mi motiva a lavorare di più sulle altre funzionalità perché anche nelle prime settimane (con grafica limitata a poligoni dai colori vivaci, rilevamento di collisioni traballanti, controlli mancanti ecc.) Il suono dà ancora la sensazione di essere "quasi lì ".
Una volta ho lavorato a un progetto che sembrava fare tutto nel modo giusto. Avrebbero creato un sito Web / una bacheca per consentire a tutti coloro che lavorano al progetto di collaborare. Avevano presentato a tutti tempi e obiettivi specifici e il gioco stesso era un buon concetto. Nonostante ciò, ci sono voluti solo circa 2 mesi prima che le persone iniziassero a cadere dalla mappa. Dopo 3 mesi, lo sviluppo è terminato e il gioco non è mai stato completato.
Quindi, se lavori in gruppo, penso che tu abbia bisogno di incentivi. Hai bisogno di qualcuno in continuo contatto con tutti, assicurandoti che stiano facendo il lavoro e ricordando loro perché vogliono continuare a farlo.
Se lavori da solo; Non sono troppo sicuro Sono terribile con opere d'arte ecc. Quindi mi concentro principalmente sul lato motore delle cose. Questo è sempre abbastanza per tenermi interessato :)
Gli sviluppatori ti diranno sempre di non spostarti in nuove aree fino a quando non avrai finito quello su cui stai lavorando ora. Se stai cercando di costruire un gioco da solo, non penso che sia troppo orribile se decidi di infrangere questa regola. Lavorare su qualcosa di fresco è un buon modo per mantenere alti i livelli di eccitazione!
Ci sono molte buone risposte, ma aggiungerò anche le mie:
Vorrei ampliare un po 'l'ultimo punto, visto che l'ho visto accadere più volte: non costruire mai un framework prima. Ci sono molte ragioni, ma fondamentalmente, non avrai la visione necessaria per fare le cose nel modo giusto, perderai molto tempo a pensare alle domande e perderai il morale quando dopo X giorni / settimane di lavoro, ci saranno niente da mostrare per questo.
Il problema è che i framework sono spesso necessari per il prodotto finale, quindi cosa deve fare un programmatore? Inizia a costruire in modo specifico, con valori hard coded. Quando dovrai modificare un valore, rendilo modificabile nelle opzioni. Quando è necessario creare due cose simili, astrarre insieme i pezzi simili, ma mantenere il resto specifico. Se continui a farlo, finirai effettivamente con una struttura che nasce per necessità, invece di perdere tempo su what-ifs all'inizio.
Dopo aver creato il tuo gioco Xth, puoi prendere in considerazione l'idea di iniziare con il framework, avrai abbastanza esperienza per farlo.
Avevo due o tre quaderni di idee prima di iniziare a sviluppare il mio primo gioco. Ho trascorso diversi mesi a giocare a giochi simili a scopo di ricerca, determinando quali funzioni mi piacevano o meno. In genere cerco di concentrarmi prima sulla meccanica e di affrontare l'aspetto e la sensazione dopo (ma facendo attenzione a non ignorare l'usabilità). Consiglierei di avere un design approssimativo ma completo prima di tuffarti nello sviluppo. Non cercare di invertire ogni dettaglio troppo presto, poiché il tuo design si evolverà necessariamente per adattarsi a problemi di giocabilità, limitazioni tecnologiche, ecc.
Assicurati che la tua idea sia piena di brainstorming e di scrivere alcuni obiettivi chiave del design. Vado attraverso un processo che chiamo trovando il gioco "anima". Cioè qual è il motivo principale per cui sto realizzando questo gioco. Da qui ho sviluppato alcuni altri concetti e idee che sosterranno questo obiettivo principale. L'intero processo può richiedere ore, giorni, settimane o più a seconda di come ti viene l'idea.
Da qui, ottieni qualcosa di visibile e cinetico. Trovo che poter giocare con il gioco e ottenere feedback da esso sia vitale per mantenere alta la motivazione. Tendo a implementare effetti visivi e sonori, oltre a una semplice gestione e elaborazione degli input, così qualcosa sta "accadendo" e sembra una realtà piuttosto che un sogno.
Indipendentemente da come vada la tua strategia di sviluppo, non posso sottolineare abbastanza da non lasciarti coinvolgere dal tentativo di progettare e codificare un "motore" di gioco. Ogni caratteristica che non ha effetti visibili o tattili sul gioco offrirà una ricompensa molto piccola. Per compensare ciò con i sistemi di base essenziali, inserisci le informazioni di sviluppo sullo schermo. IE FPS, variabili AI e qualsiasi altro testo che aiuterà a rivelare che c'è qualcosa che non c'era prima. Non c'è niente di più svuotante di passare 10 ore a programmare un sistema, compilare e avere esattamente la stessa esperienza di prima.
Ho scritto un articolo diversi anni fa sulla ricerca dell'anima dei tuoi giochi che potresti trovare di interesse qui: http://deleter.phatcode.net/index.php?page=articles&a=8
edit: E un'altra cosa che vedo menzionata in un altro post che voglio approfondire. Gioca non solo durante la progettazione del gioco, ma ogni volta che non ti senti molto motivato a lavorare sul tuo gioco. Trovo che giocare a giochi simili mi aiuti a ricordare perché voglio creare il mio gioco e mi dà quella spinta in più di cui ho bisogno per andare avanti.
Inoltre, puoi creare una "banca di ispirazione" di immagini, video, musica e clip audio che contengono tutti elementi di ciò che vuoi mettere nel tuo gioco. Ogni volta che hai bisogno di indicazioni, torna a queste fonti per aiutarti a guidare le tue decisioni. Questo ti aiuterà a rimanere motivato e in pista.
Inizia con un concetto di gioco, imposta la ragione del gioco, il gameplay, l'aspetto del gioco che desideri creare.
Da lì puoi iniziare a creare un elenco di caratteristiche e risorse in modo che il programmatore e l'artista possano almeno iniziare a lavorare su qualcosa, mentre il progettista pensa o modifica le meccaniche di gioco.
In questo modo hai almeno un po 'di codice e risorse in pochi giorni o settimane per aumentare il morale e dare il via al tuo progetto.
s/moral/morale
Per me, aiuta a "mappare" mentalmente l'idea di gioco prima di avviarla. Proverò a capire le meccaniche principali, una struttura di base del gioco interno, forse alcuni piccoli dettagli su come voglio che funzioni. Quindi applico la gomma su strada e inizio a lavorare, piegando o rompendo parti della mia mappa mentale in cui il codice necessita di una configurazione diversa. Potrei scrivere alcune cose (un retroscena, forse le caratteristiche principali), ma a quel punto il design di solito si sta spostando troppo perché un documento sia utile.
Altrimenti, un po 'mi fermo con un po' finendo per essere un progetto falso all'inizio: /