Controllo della versione con lo sviluppo del gioco - Quando devo diramare?

Di recente ho iniziato a utilizzare Version Control con i miei progetti (anche se ci sto lavorando da solo). Trovo che offra un modo piacevole per conservare la cronologia dell'intero processo di sviluppo (con tracciamento dei problemi) e mi consente di mantenere i backup dei miei progetti lungo la strada.

Mentre scopro lentamente le funzionalità e i vantaggi dell'utilizzo del controllo versione, sono bloccato sull'idea di ramificare. Quando dovrei farlo?

Dovrei essere ogni volta che vado a sviluppare una nuova funzionalità o solo una volta ogni tanto quando raggiungo un determinato traguardo?

Ovviamente, la ramificazione è piuttosto inutile quando si lavora da soli, ma preferirei prendere buone abitudini ora e abituarmi.

Mentre stavo leggendo il libro Game Coding Complete di Mike McShaffry (che è un ottimo libro tra l'altro), mi sono completamente perso quando l'autore mi ha raccomandato di tenere tre rami, qualcosa del genere:

• Principale : principale ramo di sviluppo in cui vengono apportate modifiche regolari.
• Oro : viene conservato il ramo d'oro in cui è stata raggiunta l'ultima pietra miliare.
• Ricerca : Branch per testare cose che potrebbero avere un impatto negativo sul ramo Main (modifica di componenti importanti del motore di gioco, ecc.).

È così che dovrebbe essere? Come funziona davvero nel mondo dello sviluppo di giochi con grandi team di sviluppatori?

Fondamentalmente: quando di solito si ramifica (e si fonde) nello sviluppo del gioco?

La ramificazione dipende un po 'dal supporto VCS per la funzione (ovvero: se il VCS lo rende facile o difficile).

Ma come minimo, vuoi un ramo per ogni versione del tuo progetto supportata indipendentemente. Cioè, se hai "Game 2" e "Game 2 + Expansion" che sono prodotti separati creati dalla stessa base di codice e sui quali devi essere in grado di patchare ed emettere aggiornamenti, allora vuoi avere ognuno di questi esiste nel proprio ramo al di fuori della base di codice principale, in modo che le correzioni alla base di codice principale possano essere unite in ciascuno di questi prodotti in modo indipendente. (In genere, questi rami vengono creati quando viene rilasciato ciascun prodotto, o forse qualche giorno / settimana prima, se nella base di codice sono presenti persone che lavorano su cose che non si desidera uscire con la versione iniziale)

Quando lavori con un VCS che rende l'uso dei rami complicato o doloroso (SourceSafe, svn, ecc.), Probabilmente sarai più felice di mantenere un ramo di "rilascio" per ogni prodotto rilasciato e di fare il tuo sviluppo principale in "trunk", unendo le modifiche da "trunk" ai rami "release" se e quando è necessario rilasciare aggiornamenti rapidi per tali versioni.

Se, d'altra parte, stai lavorando con uno dei più recenti sistemi VCS che si basano su ramificazioni e fusioni (git, Bazaar, Mercurial, ecc.), Allora probabilmente sarai più felice di fare il tuo sviluppo in breve tempo rami "feature" viventi. Ad esempio, se stai lavorando sul pathfinding AI, puoi creare un ramo "pathfinding" e implementare il codice lì dentro. Al termine, unisci nuovamente quel ramo nel tuo tronco principale di sviluppo ed (facoltativamente) elimini il ramo in cui stavi lavorando. Il vantaggio di questo approccio è che ti consente di lavorare su più attività contemporaneamente, invece di doverne completare uno compito prima di iniziare il prossimo.

Nel mio attuale progetto a casa (usando git), ho cinque diversi rami di funzionalità attivi in ​​questo momento, lavorando su varie funzionalità diverse. Due di questi sono approcci alternativi per fare la stessa cosa (per la profilazione), due sono idee di meccanica di gioco sperimentale, e uno è un grande refattore dei miei sistemi di intelligenza artificiale, ed è effettivamente rotto in modo tale che il codice non si compili correttamente adesso. Ma è impegnato nel suo ramo di funzionalità per riferimento e per il backup e la sua rottura non mi impedisce di lavorare sulle altre funzionalità; Gli altri rami delle caratteristiche (e anche il principale tronco di sviluppo) vengono comunque compilati ed eseguiti correttamente.

Nella mia esperienza di sviluppo di giochi professionali per grandi squadre, siamo ancora per lo più bloccati con sistemi di controllo di versione più vecchi (e supportati commercialmente). Perforce è probabilmente il più comunemente usato, seguito da Subversion. Ovunque abbia lavorato, abbiamo avuto un ramo 'trunk' e quindi un ramo 'release' separato per ogni prodotto (pietra miliare / demo / release / ecc.). Occasionalmente qualcuno creerà un ramo personale per alcuni enormi cambiamenti che stanno facendo o testando, ma questo è estremamente raro, e di solito è per cose come "convertire il gioco per funzionare con questa diversa libreria di fisica" che potrebbe non passare effettivamente al prodotto rilasciato.

Già un'ottima risposta sopra, ma una cosa da notare è quando vuoi diramare e quando vuoi taggare.

La maggior parte dei vcs ti permetterà di taggare (a volte lo chiamano etichettatura). È necessario applicare un tag ogni volta che si esegue una build principale (o per un test di riproduzione, un beta test o per una funzionalità in corso). Se si utilizza un tipo di integrazione continua (e si dovrebbe), il sistema CI dovrebbe etichettare le build riuscite. Praticamente ogni volta che fai qualcosa a cui potresti voler tornare (o per creare un ramo o per controllare come hai fatto qualcosa in quella versione) fai un tag / etichetta. Di solito sono a basso costo e semplici da aggiungere.

L'altra cosa che consiglio vivamente è di mantenere le risorse e il codice nello stesso sistema di controllo delle versioni. Avere un ramo (o tag) di codice è completamente inutile se non puoi abbinare (e quindi ramificare) le risorse. Questo è uno dei motivi principali per cui le aziende di videogiochi adorano Perforce: è altrettanto felice di archiviare file di arte binaria in quanto memorizza codice e (a differenza di git) è comprensibile a tipi non tecnici!

Oh, e ogni volta che hai voglia di controllare i file compilati nel tuo VCS stop e pensa a come puoi evitare di farlo. Nella mia esperienza, quasi sempre porta a dati non corrispondenti, alla fonte mancante (dove ad esempio viene verificata una trama DDS compressa ma non alla png sorgente) e al caos lungo la linea. Se hai una pipeline di risorse che è meglio servita dai file esportati che vengono memorizzati nella cache da qualche parte (quindi tutti non stanno rigenerando lo stesso set di file), hai sicuramente un processo che costruisce le risorse di origine nel tuo VCS e posiziona i file esportati in un cache (o unità condivisa, o anche un VCS separato). Ma non controllare manualmente i file esportati: ti morderanno (specialmente se stai lavorando come parte di una squadra).

Ho adorato quel libro e lo consiglio a tutti coloro che hanno interessi rilevanti. Per i progetti indipendenti di un uomo, non c'è alcun reale bisogno di ramificarsi a meno che tu non abbia bisogno o voglia di creare versioni separate; come uno per Android e uno per PC, o qualcosa del genere.

Come hai detto, se vuoi prendere buone abitudini, seguirei l'approccio di Mike. Ha molto senso ed è l'approccio che uso nei miei progetti indipendenti di due uomini.

Tutto ciò di cui hai bisogno per poter tornare indietro e lavorare di più, dovrebbe essere personalizzabile (ma non necessariamente ramificato ... ancora).

Il motivo è semplice. Devi essere in grado di emettere una versione fissa di quel codice, non qualsiasi altro codice, quindi in quel momento devi lavorare su un ramo.

I VCS sono diversi. Alcuni - come Git - sono molto facili da ramificare da qualsiasi commit in qualsiasi momento successivo, altri - come CVS - sono molto ingombranti con cui lavorare in seguito.

Forse vuoi aprire una domanda su StackOverflow, chiedendoti come lavorare al meglio con il sistema di controllo versione che hai scelto? Se non si è in realtà ancora iniziato con un sacco di storia, si consiglia di aprire una domanda che descrive il modo di lavorare e chiedere una raccomandazione del miglior sistema di controllo versione per te?