Che tipo di gestione del progetto dovrebbe usare un progetto per sviluppatore solista?

Sto lavorando da solo a un progetto di gioco il cui sviluppo potrebbe essere suddiviso in 3 parti indipendenti (generazione di mappe, motore "overworld" e motore di battaglia), ma man mano che lo sviluppo procede, non sono sicuro di come dovrei occuparmi di la gestione di questo progetto, in particolare per quanto riguarda questi 3 punti:

1. Ne vale la pena usando un sistema di controllo della versione, dato che sto lavorando da solo?

2. Dovrei usare un metodo formale per registrare funzionalità / bug pianificati (ricordo solo cosa è necessario fare per ora)

3. La domanda più importante: come posso sapere cosa sviluppare prima? Ora che sono state fatte le basi, conosco l'elenco delle funzionalità da codificare ma non so in quale ordine dovrei farlo.

Io userei:

1. Gestione del codice

GIT (e il fantastico riferimento ), un gestore di codice sorgente distribuito, per gestire il mio codice e ospitarlo su GitHub come progetto privato se voglio tenerlo fuori dai limiti.

(Ci sono MOLTE opzioni qui, solo google per la gestione del codice sorgente, non hai nemmeno BISOGNO di usare GitHub o qualsiasi altro sito web, Git funzionerà perfettamente sul tuo computer locale, ma l'uso di GitHub farà la fatica di gestire i backup molto più facile.

Se hai due computer, puoi creare un repository su uno che chiamerai la tua macchina di backup, quindi clonare quel repository sulla rete locale e utilizzarlo per lo sviluppo, quando hai finito con una funzionalità puoi inviarlo al macchina di backup e avrai un backup 1: 1!)

2. Gestione dei problemi e delle funzioni

Vorrei utilizzare la gestione dei problemi integrata di Trello o GitHub per tenere traccia di bug e cose da fare.

3. Avere un processo di progettazione

Prima progetterei il mio gioco;

1. prima nella mia mente,
2. poi su carta,
3. quindi probabilmente uso GameMaker o PyGame per prototipare la mia idea e scorrere più di 1-3 fino a quando non avrò qualcosa che mi diverte giocare.

4. Usa il mio prototipo come guida e sviluppa il mio gioco

Quindi metterei da parte il mio prototipo e sceglierei una piattaforma per cui desidero sviluppare. Quindi cerca i motori esistenti e scegli quello più adatto alla mia idea di gioco. Quindi vorrei definire obiettivi chiari per il mio progetto, strutturarli in piccoli compiti e quindi iniziare a lavorare per terminarli. Quando avrai raggiunto questo stato, molto probabilmente scoprirai di avere il tuo modo di lavorare che ti si addice meglio, quindi segui quello!

Esistono diverse metodologie / filosofie che puoi applicare al tuo stile di sviluppo, XP, Waterfall, ecc. Basta andare con quello che ritieni ti faccia progredire più velocemente.

5. Avere un sacco di tester di gioco!

Quando hai qualcosa di giocabile, chiedi ai tuoi amici immediati di provarlo! Semplifica il loro aiuto impostando pacchetti di installazione rapida se stanno eseguendo Windows o scrivendo alcuni script di shell che possono automatizzare il processo se stanno usando Linux / Mac. Abbi molta cura nel feedback dei tuoi tester e non dimenticare di informarli sul design del tuo gioco e sul tipo di gioco che stai cercando di costruire.

6. Crea un sito Web per il mio gioco

Non appena avrò qualcosa che andrà bene, probabilmente creerei un sito Web per il mio gioco - per mantenere la mia creatività e il mio contenuto fluenti quando non possono essere applicati ai progressi del mio gioco, ad esempio, se mi sto concentrando sui miei studi o hai bisogno di una pausa dallo sviluppo!

Se uso GitHub , imposterei una pagina di progetto per il mio gioco, altrimenti ospiterei un blog WordPress / Jekyll o qualcosa di simile e scriverei i miei post con quello.

Questo ti manterrà motivato, oltre a disporre di un posto dove indirizzare potenziali giocatori / tester!

7. Partecipa a concorsi

Ci sono molti concorsi di sviluppo di giochi che si svolgono quasi sempre. Proverei a unirmi a uno di questi con il mio gioco se le regole lo consentono. Ciò aumenta la motivazione e rende tutto ancora più divertente - a chi non piace vincere!

(Se stai sviluppando entro una scadenza rigorosa, puoi almeno saltare questo punto.)

Consiglio vivamente di utilizzare un sistema di controllo della versione, anche se lavori da solo. Può farti risparmiare un sacco di tempo, una volta che elimini accidentalmente qualcosa o apporti una modifica più grande, solo per rendertene conto in seguito è stata una cattiva idea e devi annullare tutte le modifiche.

Modifica : ci sono molte soluzioni di controllo del codice sorgente gratuite.

• Ho usato il server VisualSVN , che è facile da configurare e utilizzare in Windows.

• Ci sono anche alternative online come Codeplex (con SVNo Mercurial), SourceForge o Google Code . Il vantaggio è che non è necessario impostare e gestire un repository e i dati sono nel cloud; il problema è che non puoi ospitare liberamente progetti a sorgente chiuso.

Per quanto riguarda il tracciamento di bug e funzionalità: se disponi già di un pubblico più vasto che potrebbe essere interessato al beta test del tuo gioco, alla segnalazione di bug e alla richiesta di funzionalità, procedi.
Se, tuttavia, ci sono solo poche persone (o nessuna), non è necessario.

E per quanto riguarda le priorità di sviluppo, questo spetta a te decidere. Chi dovrebbe sapere meglio cosa fare in un progetto rispetto al suo unico sviluppatore?

Ne vale la pena usando un sistema di controllo della versione, dato che sto lavorando da solo?

Credo di si. È abbastanza banale da configurare e ho avuto più volte che sono impazzito con il refactoring o ho fatto qualcos'altro di stupido e la capacità di ripristinare i miei cambiamenti ha risparmiato tonnellate di tempo. Inoltre, se è ospitato su un server, hai un backup del nostro codice nel caso qualcosa vada storto .

Dovrei usare un metodo formale per registrare funzionalità / bug pianificati (ricordo solo cosa è necessario fare per ora)

Non penso sia necessario. Vorrei tenere un elenco scritto di ciò che intendi fare anche solo per assicurarmi di non dimenticare un bug minore, inoltre trovo che ti aiuti a ricominciare dopo aver preso una pausa dalla codifica.

La domanda più importante: come posso sapere cosa sviluppare prima? Ora che sono state fatte le basi, conosco l'elenco delle funzionalità da codificare ma non so in quale ordine dovrei farlo.

Prendi quella lista sopra, chiudi gli occhi e colpisci in modo casuale. Lavora su qualunque funzione del dito. A meno che gli articoli non dipendano l'uno dall'altro, è più importante mantenere il flusso attivo piuttosto che assicurarsi che le cose accadano in un ordine particolare.

Usa sicuramente il controllo versione

Il controllo della versione è come una rete di sicurezza per un funambolo: ti libera per tentare cose folli. Un grosso refattore che cancella enormi blocchi di codice non è un problema se puoi facilmente tornare indietro. Lo è ancora meno se sei su un ramo sperimentale nel tuo repository e puoi decidere di non fonderlo nuovamente.

Se non hai questo tipo di libertà, è probabile che lasci il codice commentato in giro ovunque per paura di averne bisogno.

Vorrei votare Git. La sintassi è un po 'strana, ma due grandi cose a riguardo sono:

• Spese generali basse . Passa a una cartella e digita git inite sei pronto per iniziare a fare il check-in. Se decidi di non voler controllarlo dopo tutto, rm -rf .gitin quella cartella e non è più un repository Git.

• Distribuito tramite SSH . Git è distribuito, il che significa che puoi avere più copie complete del tuo repository (tutta la cronologia, ecc.) In vari punti e mantenerle sincronizzate. È possibile configurare un altro repository Git su qualsiasi macchina in cui si dispone dell'accesso SSH, quindi aggiungere l'altro repository come telecomando. Successivamente, ogni volta che si desidera eseguire il backup solo git pushsu quel repository.

  Questo è un grande vantaggio rispetto, per esempio, a Subversion, in cui l'intero repository vive su una macchina e quella macchina deve eseguire un server Subversion.

Mercurial potrebbe avere questi stessi punti a suo favore, ma non l'ho usato.

1. Sì! Dato che mi stai chiedendo, suppongo che tu sia ben adottato con il sistema di controllo delle revisioni. È un must!

2. Per quanto riguarda la tua seconda domanda, esistono metodi formali di registrazione dei bug e dovresti usarli. Per quanto riguarda le funzionalità di pianificazione, penso che fare qualsiasi percorso meno formale non faccia male (quando lavori da solo)

3. Esegui prima quelle funzionalità che daranno vita al tuo gioco. Dai un'idea di come sarà il gioco finale.

1) Sì, certo. Consiglio Mercurial tramite BitBucket e TortoiseHg. BitBucket è gratuito per un massimo di 5 utenti e poiché è ospitato nel cloud ti aggiunge un po 'di pensiero (senza bisogno di backup).

2) I bug devono essere corretti prima di implementare nuove funzionalità. Vorrei utilizzare un semplice elenco TODO accessibile per tenere traccia delle cose - in sospeso / fatto. Potresti semplicemente usare un file di testo semplice, non dimenticare di aggiungerlo al tuo repository di controllo del codice sorgente.

3) Fai quello che vuoi fare in un dato giorno, tenendo presente che fornire qualcosa di giocabile dall'utente finale è un obiettivo primario. Ad esempio, se sei stanco di ottenere la fisica giusta, lavorare sul rendering o forse aggiungere alcuni test unitari mancanti per quell'intelligenza artificiale.

Pezzi di lavoro dovrebbero essere abbastanza piccoli da essere eseguiti in circa un paio di giorni. È fondamentale rimanere motivati ​​ed evitare il burnout.

Se l'architettura viene eseguita correttamente, dovresti essere in grado di aggiungere facilmente una modifica delle parti del motore / gioco senza influenzarne altre (altrimenti inizia con alcuni refactoring :).

1) Come dicono tutti: SÌ (direi addirittura, noleggiarne uno economico online)

2) Mantieni un semplice elenco o se il tuo progetto diventa grande e ottieni beta tester, installa Mantis Bug Tracker

3) Non lo so, ma ti dirò come lo sto facendo: sviluppa prima le cose meno interessanti e / o più difficili. Ripeti fino a quando tutto è fatto. In questo modo lo sviluppo diventa solo più divertente e più facile (e non colpirai quel problema che non puoi risolvere troppo tardi se mai dovesse succedere).

Grazie per aver posto questa domanda. Questo è esattamente quello che sto facendo attualmente.

1) Controllo versione: è obbligatorio. In questo momento, sto mantenendo il backup manuale. È utile almeno quando qualcosa che funzionava alla grande ha improvvisamente gettato errori (o non funziona come previsto). Confronto le versioni e trovo spesso errori sciocchi (principalmente commentando qualcosa)

2) Ho creato un documento word e ho elencato tutte le funzionalità che il mio gioco avrà in un ordine categorico e con rientri a più livelli che elencano le funzioni secondarie (e relative a client / server o qualsiasi cosa sia applicabile).

3) Dopo la lista che ho ottenuto (che di solito non è completa, continuo ad aggiungere qualcosa ad esso) penso al mio flusso di gioco e evidenzio tutti i punti necessari per far funzionare il gioco e iniziare a farli. Contrassegno giallo per lavori in corso. verde quando completato. arancione per indicare che deve essere migliorato o presenta alcuni bug noti

spero che sia di aiuto

1.) Vale la pena usare il controllo versione per qualsiasi progetto. Anche quelli molto piccoli se sai già come usarne uno. Ho usato Subversion per anni su Linux e Windows con TortoiseSVN . Anche quando realizzo un piccolo progetto (<500 righe) creerò un repository per esso in modo da poter annullare le modifiche, tenere traccia di ciò che stavo facendo se abbandono il progetto per un po ', ecc.

2.) Dipende dalla dimensione del progetto. Se hai intenzione di giocare-test con una squadra e distribuire, probabilmente vale la pena avere un sistema di tracciamento dei bug. Attualmente sto lavorando da solo (anche se ho un artista) su un progetto di oltre 20.000 righe e tengo solo la mia lista di cose da fare in un file di testo che è anche nel mio repository SVN. Anche se non ho esattamente bisogno di condividerlo con altri ancora, quindi non avere il tracciamento dei bug si adatta alle mie esigenze per ora. Non mi preoccuperei fino a quando non sarà necessario. Il peggio che può succedere è che dovrai inserire tutti i bug che hai già scritto e rimuovere / rivedere quelli che hai corretto. Quando inizi a perdere la traccia mentale delle tue note, ottieni un bug tracker.

3.) Traccialo su carta. Inizia con quello che vuoi che sia il tuo gioco finito, scrivine l'essenza. Quindi suddividilo in quello che ci vorrà per farlo: rilevamento delle collisioni? codice di rete? tipi di giocatori e mostri? gerarchie di classi? Lavora all'indietro dalla tua visione in modo da avere un'idea chiara di come costruirla da zero. Presumo che tu stia usando un linguaggio orientato agli oggetti. Il passo più cruciale per iniziare sarebbe quello di impostare quelle gerarchie di classi in modo ragionevole. Fai del tuo meglio per non avere alcuna eredità multipla (anche se a volte è inevitabile), traccia le relazioni di classe in un editor di diagrammi (io uso Dia ), ecc. I principi di base fanno molto per evitare il mal di testa in seguito.