Gestione patrimoniale, database o sistema di versioning?

Durante lo sviluppo delle risorse per il gioco, (mesh, trame, suoni, video), le gestisci?

1. Tenendoli insieme al codice sorgente all'interno del sistema di versioning? (perforce, git, ecc ...)
2. O avere un database centrale back-upped dedicato alle risorse e avere gli editor sempre graditi? (PostgreSQL, MySQL, ecc ...)
3. Altro?

Quali sono i pro e i contro di ciascuno e perché uno dovrebbe sceglierlo rispetto agli altri?

Per molti di noi - specialmente lavorando su giochi più piccoli - dovresti assolutamente avere risorse nello stesso repository della tua fonte .

Il suggerimento che gli asset appartengano a un repository separato ha senso solo per insiemi di asset molto grandi o per insiemi di asset piuttosto grandi quando esiste un confine motore / dati chiaramente definito. A meno che non ci sia una ragione tecnica specifica per questo - è un cattivo consiglio!

Si desidera che il controllo della versione si comporti come il controllo della versione . Vuoi essere in grado di riavvolgere, avanzare rapidamente, ramificare e unire le revisioni e far funzionare il gioco. E il codice e le attività saranno dipendono l'uno dall'altro.

Ad esempio: il codice potrebbe prevedere di essere in grado di impostare un parametro su uno shader e tale shader potrebbe dipendere da una trama presente. O forse il formato dei dati dei tuoi livelli potrebbe dipendere da una particolare versione del tuo codice di gioco.

Quasi sicuramente diventerà disordinato. E hai cose migliori da fare che cercare di mantenerlo in ordine.

Ora, come ha commentato Mike Wagner ( su questa risposta ), non vuoi o non hai bisogno di tutte le versioni "in progress" delle tue risorse sotto il controllo delle versioni! Solo la versione finale / funzionante, come utilizzata dal tuo codice, farà - spesso questo è ciò che esporti dal tuo strumento.

(Anche se si desidera controllare la versione delle versioni in corso degli asset, va bene. E ben si adatta a un repository separato. Trovo personalmente che una buona organizzazione delle cartelle e un sistema di backup adeguato siano sufficienti.)

Detto questo, a volte è bello avere l'opzione di bloccare le risorse "in progress" sotto il controllo della versione. In genere ciò implica avere una pipeline di contenuti in grado di gestire qualsiasi passaggio di "esportazione", ad esempio l'appiattimento di un'immagine multistrato su una singola trama.

Sistema di versioning.

Con un approccio personalizzato, finiresti effettivamente per creare un sistema di versioning, quindi è meglio usarne uno standard che ha già avuto anni di cicli di progettazione / codice / test.

Mantieni le risorse in un repository separato dalla fonte, per rendere più semplice ridurre al minimo i tempi di checkout / sincronizzazione e prendere decisioni diverse sulla quantità di cronologia da conservare (anche se lo spazio su disco è economico, conservalo tutto quando possibile. cambieranno molto durante la vita di un progetto).

Contrassegna i file XML come binari, gli strumenti di unione tendono ad essere molto difficili da unire il markup nidificato e gli artisti non sono in grado di individuare markup interrotti se lo strumento ritiene che non vi siano conflitti.

Se è possibile, organizzare un controllo della sintassi o persino costruire un asset su ogni commit e rifiutare il commit con una e-mail di nuovo alla persona che commette in caso di fallimento; questo farà risparmiare molto tempo alla squadra.

Tutto in un repository, se puoi permettertelo in termini di dimensioni. Ho sentito parlare di repository Subversion in prossimità di 1 TB. Al momento siamo leggermente al di sotto di 400 GB.

Inoltre, gli artisti controllano molto tutto, compresi i 30 contorni di un concetto; usiamo alberi di cartelle separati per "risorse di origine" e per "esportati" - quelli che vanno nello script di creazione delle risorse. Se il tuo artista viene investito da un autobus domani, devi essere in grado di avere qualcuno che continui a lavorare sui suoi beni il giorno successivo, solo guardando attraverso il repository (senza archeologia sulla sua macchina personale). C'era una volta in cui i giochi erano in 2D e gli sprite erano prerenderizzati da complesse scene animate di Max, dovevamo spedire un gruppo di unità in un gioco RTS con un aspetto un po 'schifoso e molto incoerente (rispetto al resto delle unità), anche anche se si trattava di eseguire nuovamente il rendering con impostazioni di illuminazione e antialiasing leggermente diverse - perché l'artista originale aveva smesso e non avevamo le sue scene Max originali. Don'