Controllo del codice sorgente per la memorizzazione di tutto il progetto di gioco?


10

È solito gestire non solo il codice sorgente, ma tutte le risorse, le trame, i disegni, i file di documentazione, ecc. Nel repository git per il controllo della versione? Ad esempio, voglio tornare alla vecchia versione di texture. Se è una pessima pratica quali strumenti usi per il controllo della versione di risorse e altre cose?



1
Il codice sorgente è tutto ciò che non puoi generare dal codice sorgente. Le risorse, le trame, l'arte e la documentazione sono anche il codice sorgente sotto quella definizione.
Christoffer Hammarström,

Risposte:


12

Direi che è un'ottima pratica. Il controllo del codice sorgente dovrebbe essere utilizzato per il codice sorgente e le risorse. Puoi pensarlo come un backup, vuoi essere in grado di ripristinare dal controllo del sorgente tutto il necessario per costruire il tuo gioco.

Ho collegato una domanda relativa alla memorizzazione di risorse in un repository. Ci sono alcuni repository che funzionano meglio di altri per conservare l'arte. Ti permetteranno di "diff" l'arte e vedere cosa è cambiato. Altri tratteranno le risorse solo come dati binari, quindi dovrai verificarle per vedere cosa c'è di diverso. Questo significa anche che dovrai caricare l'intera risorsa quando cambia, poiché non sarà possibile per il repository "conoscere" (analizzare) cosa è cambiato tra le versioni.

Conservo tutto nel repository. Quando ho ottenuto il mio nuovo laptop, sono stato in grado di controllare il mio repository e creare il mio gioco, senza la necessità di copiare risorse da qualsiasi altra parte. Ciò significa che memorizzo anche le librerie, le risorse e il controllo del codice sorgente di terze parti nel mio repository.


7

Git non è eccezionale per i file non di testo. La clonazione di un repository git richiede il download di tutte le versioni storiche di un file, a meno che non si utilizzi un'estensione di file di grandi dimensioni (non standard, spesso non supportata dalle GUI) o comandi speciali (richiede di essere un git guru). Lo stesso vale per la maggior parte dei sistemi DVCS. Per una trama, un modello o una clip audio, ciò significa estrarre molte copie di un file molto grande. 1 GB di risorse può facilmente essere 200 GB di dati di revisione storici e git ti fa scaricare tutto quando cloni un nuovo repository e scarica tutte le revisioni intermedie quando acquisisci le ultime. Questo diventa un enorme collo di bottiglia lungo la strada quando puoi almeno tollerare ritardi nella produzione.

Subversion, Perforce e così via sono scelte migliori per gli asset, poiché richiedono solo il download della revisione desiderata (l'ultima, in genere). Puoi usarli solo per le risorse e usare git per il codice, o anche per fonte. Perforce ha alcune caratteristiche che lo rendono un grosso DVCS ed è migliore della funzionalità SVN (anche se molto più complessa) nella mia esperienza, tuttavia il costo significa che probabilmente userete Subversion.

La maggior parte dei professionisti dei contenuti ha poco bisogno di DVCS e alcuni hanno comunque problemi con le basi del VCS classico. Non sellare con Git. O Mercurial, DARCS, ecc.


buon punto, ma puoi clonare senza recuperare tutta la storia stackoverflow.com/questions/11497457/…
Ali

1
@Ali: i cloni superficiali non risolvono affatto il problema in modo adeguato (disabilitano molti comandi, non sono quelli predefiniti per la maggior parte delle GUI, ecc.) E sono essenzialmente inutili per la maggior parte delle cose oltre ai server CI e simili. Nuove soluzioni git come git-lfs sono sorte per risolvere i problemi che ho delineato nel tentativo di coinvolgere git in team con contenuti pesanti.
Sean Middleditch,

git lfs risolve molto bene il problema del "file binario di grandi dimensioni".
Nepoxx

3

È buona pratica, anche se come artista quando stai lavorando a un progetto tende ad esserci una qualche forma di controllo della versione, si verificano corruzione dei file o bug, senza che gli artisti del controllo del codice sorgente tendano a fare risparmi di revisione, il che è solo un enorme casino.

Un esempio del mondo reale che puoi vedere di questo è i progetti di film aperti realizzati con Blender (Big Buck Bunny, Durian, ecc.)

La pipeline artistica per un gioco è più o meno la stessa, tranne che potrebbe esserci un passaggio di costruzione per gli asset stessi per fare una conversione da grandi quantità di dati in formato specifico del motore, come la compressione delle trame e la conversione del formato del modello.

Alcuni strumenti, come GitHub, offrono anche strumenti di confronto delle immagini gradevoli e simili, che è molto meglio del confronto di un BLOB binario.

Poiché un repository di risorse può essere assolutamente enorme, la mia / nostra preferenza è quella di mantenere un repository di risorse separato che è un sottomodulo nel repository di progetto. Non vuoi abbattere gigabyte di risorse quando tutto ciò che vuoi è ramificare la fonte per esempio.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.