Git per lo sviluppo di videogiochi
14 marzo 2012 Nel corso degli anni ho utilizzato diversi sistemi di controllo versione per la produzione cinematografica e videoludica: CVS, Perforce e persino alcuni strumenti sviluppati internamente. Li ho sempre percepiti come mali necessari ma goffi: indispensabili per tenere traccia del lavoro su progetti di grandi dimensioni, ma anche una fonte costante di confusione, colli di bottiglia e rigidità produttiva.
Git è apparso per la prima volta sul mio radar circa sei mesi fa. Sembrava incredibilmente potente e flessibile. Gli sviluppatori di Massively Fun lo stavano già utilizzando per lo sviluppo del codice quando mi sono unito al team. Ero curioso di vedere se potessimo adattarlo alla produzione artistica.
Questo post racconta cosa è successo. Contesto: cos’è Git? Git è un sistema di controllo versione distribuito. Quasi tutti nel settore dello sviluppo di videogiochi avranno già familiarità con almeno un altro sistema di controllo versione come Subversion o Perforce.
Come questi altri sistemi, Git ci permette di tenere traccia delle numerose versioni diverse di tutti i file che compongono un progetto. Tuttavia, Subversion e Perforce sono sistemi centralizzati: tutti i file vengono archiviati o prelevati da un repository ospitato su un server centrale. Git è diverso.
Non dipende da un server centrale. Ogni utente ottiene una copia completa dell’intero repository, con tutta la sua cronologia e le sue revisioni. Questa architettura ha una serie di implicazioni importanti, per lo più positive.
Ma ciò che rende Git particolarmente eccezionale ai miei occhi è il modo in cui rende le operazioni di branch e merge quasi banali. Puoi creare un branch per lavorare su un’idea sperimentale, un altro per risolvere un problema non correlato e un altro ancora per una nuova funzionalità. Puoi spostarti rapidamente tra questi diversi branch e unirli quando necessario. È una funzionalità incredibilmente utile. Ostacoli Nonostante i suoi numerosi punti di forza, Git “così com’è” presenta due evidenti limiti per la produzione artistica: Non è adatto agli artisti.
Correlato: — Grafica, strumenti e modelli già pronti che vengono inseriti direttamente nel tuo progetto Unity.
L’interfaccia predefinita di Git è la riga di comando. Ci sono molti comandi e opzioni da imparare, insieme a concetti sottostanti che differiscono sufficientemente dagli altri sistemi di controllo versione da generare confusione.
La documentazione è abbondante ma spesso difficile da comprendere. Il risultato è un pacchetto poco accessibile e piuttosto intimidatorio. Non è progettato per gestire i grandi file binari creati dagli artisti. Il fatto che ogni repository locale contenga tutta la cronologia e le revisioni significa che molte opere d’arte in rapida evoluzione possono occupare molto spazio su disco in breve tempo.
Abbiamo trovato soluzioni per entrambi questi problemi. L’interfaccia conta Esistono diverse buone interfacce grafiche per Git. Gli artisti devono comunque comprendere i concetti base di Git, ma un front-end ben progettato rende l’apprendimento e l’utilizzo considerably più semplici.
Se stai facendo acquisti: — Motore HTML5 senza codice basato su browser che esporta su Web, dispositivi mobili e desktop.
Abbiamo scoperto che SourceTree di Atlassian funzionava alla grande nel nostro ambiente basato su Mac: è potente, intuitivo e gratuito (per ora) – un aspetto importante per una startup agguerrita. Il team di SourceTree ha anche risposto prontamente (< 12 ore) alle nostre richieste di supporto inviate via tweet. Un’estensione Git efficace Git-media affronta le carenze di Git riguardo ai grandi file binari. È un’estensione di Git che consente di archiviare i file esternamente a Git.
Git continua comunque a tracciare le versioni dei file; semplicemente memorizza il contenuto dei file da qualche parte fuori dal repository. Avevamo pianificato di archiviare i nostri grandi file binari nel cloud Amazon S3.
Non così veloce Utilizzare SourceTree con Git-media presenta tuttavia una complicazione: il trasferimento di file tra i nostri repository e Amazon S3 richiede l’esecuzione di un comando shell; ovvero, $ git media sync Un flusso di lavoro che obbliga gli artisti ad abbandonare il relativo comfort di un’applicazione grafica per digitare comandi shell non è adatto agli artisti. SourceTree offre effettivamente un modo per eseguire questo comando come azione personalizzata, ma non era sufficiente. Gli artisti dovrebbero comunque ricordare di eseguirlo nei momenti appropriati.
Prima o poi se ne dimenticherebbero e qualcuno perderebbe tempo prezioso cercando di capire cosa è andato storto e risolvendo il problema. Come potevamo far collaborare armoniosamente SourceTree e git-media?
Git Wrap Abbiamo scritto uno script wrapper generico che esegue opzialmente alcuni altri comandi prima e/o dopo il comando git stesso. Lo abbiamo configurato per chiamare automaticamente ‘git media sync’ prima o dopo i comandi che interagiscono con un repository remoto, a seconda dei casi. Abbiamo configurato SourceTree per invocare il wrapper invece di Git standard. Il codice sorgente del wrapper è disponibile qui su Github.
L’avventura continua Vorrei dirvi che questa è la fine della storia, che SourceTree e git-media hanno lavorato insieme perfettamente e che siamo vissuti tutti felici e contenti. In effetti hanno funzionato, fino a un certo punto. Purtroppo, non era abbastanza.
SourceTree svolge normalmente un ottimo lavoro nell’anteprima dei file immagine. Questo è cruciale per gli artisti quando confermano o uniscono modifiche a tali file. Ma l’utilizzo di git-media ha compromesso la capacità di SourceTree di visualizzare in anteprima questi file, perché significava che non stavamo più archiviando le immagini in Git; stavamo archiviando solo le informazioni di versione relative alle immagini.
Non siamo riusciti a trovare un modo accettabile per aggirare il problema; è stato un fattore decisivo. Al momento della stesura di questo articolo stiamo facendo un altro tentativo con la funzionalità dei submodule di Git.
Archiviare le nostre risorse artistiche in un submodule è un altro modo per minimizzare le dimensioni del repository principale del progetto. SourceTree comprende e supporta fairly bene i submodule e la sua capacità di visualizzare in anteprima le immagini rimane intatta. I submodule presentano alcune idiosincrasie, ma nulla che sembri troppo dirompente per il flusso di lavoro dei nostri artisti. Restate sintonizzati per gli aggiornamenti; vi faremo sapere come andrà a finire. commenti del blog offerti da Disqus
Scrivi un codice di gioco migliore, più velocemente
IDE .NET/C# multipiattaforma con supporto Unity e Unreal Engine di prima classe