Git til spiludvikling
De fremstod altid for mig som klodsede, men nødvendige onder – uvurderlige til at spore arbejdet på store projekter, men samtidig en vedvarende kilde til forvirring, flaskehalse og stivhed i produktionen. Git dukkede første gang op på min radar for omkring seks måneder siden.
Det så utroligt kraftfuldt og fleksibelt ud. Udviklerne hos Massively Fun brugte allerede Git til kodeudvikling, da jeg joinede teamet. Jeg var ivrig efter at se, om vi kunne få det til at fungere til kunstproduktion. Dette indlæg fortæller historien om, hvad der skete.
Baggrund: Hvad er Git? Git er et distribueret versionsstyringssystem. De fleste inden for spiludvikling vil allerede være bekendt med mindst ét andet versionsstyringssystem som Subversion eller Perforce.
Ligesom disse andre systemer giver Git os mulighed for at holde styr på de mange forskellige versioner af alle de filer, der indgår i et projekt. Men Subversion og Perforce er centraliserede systemer – alle filer checkes ind på eller ud fra et repository, der ligger på en central server. Git er anderledes.
Det er ikke afhængigt af en central server. Hver bruger får en fuldgyldig kopi af hele repository’et med al dets historik og revisioner. Denne designbeslutning har en række vigtige konsekvenser, hvoraf de fleste er positive.
Men det, der i mine øjne får Git til at skille sig mest ud, er, hvordan det gør branch- og merge-operationer nærmest trivielle. Du kan oprette en branch for at arbejde på en eksperimentel idé, en anden for at løse et urelateret problem og endnu en til en ny funktion. Du kan hurtigt skifte mellem disse forskellige branches og sammenføre dem efter behov. Det er en utroligt nyttig funktion.
Relateret: — Færdiglavet kunst, værktøjer og skabeloner, der falder direkte ind i dit Unity-projekt.
Forhindringer På trods af sine mange styrker har Git ud af boksen to åbenlyse svagheder i forhold til kunstproduktion: Det er ikke kunstnervenligt. Gits standardgrænseflade er kommandolinjen.
Der er mange kommandoer og indstillinger at lære samt underliggende koncepter, der adskiller sig tilstrækkeligt fra andre versionsstyringssystemer til at skabe forvirring. Dokumentationen er rigelig, men ofte svær at forstå. Det hele summerer op til en pakke, der ikke er særlig tilgængelig og lidt skræmmende. Det er ikke bygget til at håndtere den type store binære filer, som kunstnere laver.
Det faktum, at hvert lokalt repository indeholder al historik og alle revisioner, betyder, at meget kunst, der ændres hurtigt, kan æde en masse diskplads på kort tid. Vi fandt løsninger på begge disse problemer. Grænsefladen betyder noget Der findes flere gode grafiske grænseflader til Git.
Hvis du handler: — Browserbaseret HTML5-motor uden kode, der eksporterer til web, mobil og desktop.
Kunstnere skal stadig forstå grundlæggende Git-koncepter, men en veldesignet front-end gør det betydeligt lettere at komme i gang med og bruge det. Vi fandt ud af, at Atlassians SourceTree fungerede fantastisk i vores Mac-baserede miljø: Det er kraftfuldt, intuitivt og gratis (i hvert fald lige nu) – en vigtig overvejelse for en lille startup. SourceTree-teamet svarede også prompte (< 12 timer) på vores supportforespørgsler sendt via Twitter.
En smart Git-udvidelse Git-media adresserer Gits mangler i forhold til store binære filer. Det er en Git-udvidelse, der giver dig mulighed for at gemme filer uden for Git.
Git holder stadig styr på filversionerne; det gemmer blot filindholdet et sted uden for repository’et. Vi planlagde at gemme vores store binære filer i Amazons S3-cloud. Ikke så hurtigt Brugen af SourceTree sammen med Git-media indebærer dog et lille problem: Overførsel af filer mellem vores repository’er og Amazon S3 kræver, at vi udfører en shell-kommando; dvs. $ git media sync En workflow, der tvinger kunstnere til at forlade den relative komfort ved et grafisk program for at taste shell-kommandoer, er ikke kunstnervenlig.
SourceTree giver dig ganske vist en måde at udføre denne kommando som en brugerdefineret handling på, men det var ikke godt nok. Kunstnerne skulle stadig huske at gøre det på de rette tidspunkter.
Før eller senere ville de glemme det, og nogen ville spilde værdifuld tid på at finde ud af, hvad der gik galt, og fixe det. Hvordan kunne vi få SourceTree og git-media til at spille sammen? Git Wrap Vi skrev et generisk wrapper-script, der valgfrit udfører nogle andre kommandoer før og/eller efter selve git-kommandoen. Vi satte det op til automatisk at kalde ‘git media sync’ før eller efter kommandoer, der interagerer med et eksternt repository, alt efter hvad der var passende.
Vi konfigurerede SourceTree til at invoke wrappere i stedet for Git ud af boksen. Kildekoden til wrappere er tilgængelig her på Github. Eventyret fortsætter Jeg ville gerne kunne fortælle dig, at dette var slutningen på historien, at SourceTree og git-media fungerede gnidningsfrit sammen, og at vi alle levede lykkeligt til vores dages ende.
De fungerede faktisk, op til et vist punkt. Desværre var det ikke godt nok. SourceTree gør normalt et godt stykke arbejde med at forhåndsvise billedfiler. Dette er afgørende for kunstnere, når de committer eller merger ændringer i sådanne filer.
Men brugen af git-media ødelagde SourceTrees evne til at forhåndsvise disse filer, fordi det betød, at vi ikke længere gemte billederne i Git; vi gemte kun versionsoplysninger om billederne. Vi kunne ikke finde en acceptabel løsning på dette; det var en dealbreaker.
Fra og med skrivende stund forsøger vi os igen med Gits submodule-funktion. At gemme vores kunstaktiver i en submodule er en anden måde at minimere størrelsen på hovedprojektets repository på. SourceTree forstår og understøtter submodules ret godt, og dets evne til at forhåndsvise billeder forbliver intakt. Submodules har ganske vist nogle ejendommeligheder, men intet der ser ud til at forstyrre vores kunstner-workflow for meget.
Hold øje med dette sted for opdateringer; vi vil fortælle dig, hvordan det går. blog comments powered by Disqus
Lær spiludvikler efter din egen tidsplan
On-demand kurser, der dækker Unity, Unreal, C++, C# og shader programmering