Git for spillutvikling

Massivt morsomt Git for spillutvikling Git for spillutvikling 14. mars 2012 Jeg har brukt flere ulike versjonskontrollsystemer til film- og spillproduksjon opp gjennom årene: CVS, Perforce, og til og med noen interne verktøy. De har alltid fremstått som klumpete, men nødvendige onder – uvurderlige for å holde styr på arbeidet i store prosjekter, men også en vedvarende kilde til forvirring, flaskehalser og stivhet i produksjonen.

Git dukket først opp på min radar for about seks måneder siden. Det så utrolig kraftig og fleksibelt ut. Utviklerne bak Massively Fun brukte allerede Git til kodeutvikling da jeg ble med i teamet. Jeg var spent på om vi kunne få det til å fungere for kunstproduksjon også.

Dette innlegget forteller historien om hva som skjedde. Bakgrunn: Hva er Git? Git er et distribuert versjonskontrollsystem. De fleste innen spillutvikling vil allerede være kjent med minst ett annet versjonskontrollsystem, som Subversion eller Perforce.

Som disse andre systemene lar Git oss holde oversikt over de mange ulike versjonene av alle filene som inngår i et prosjekt. Men Subversion og Perforce er sentraliserte systemer – alle filer sjekkes inn i eller ut fra et depot som ligger på en sentral server. Git er annerledes.

Det er ikke avhengig av en sentral server. Hver bruker får en fullverdig kopi av hele depotet, med all historikk og alle revisjoner. Denne utformingen har en rekke viktige konsekvenser, hvorav de fleste er positive.

Men det som får Git til å skille seg mest ut i mine øyne, er hvordan det gjør operasjoner for grening og fletting nesten bagatellmessige. Du kan opprette en gren for å jobbe med en eksperimentell idé, en annen for å fikse et urelatert problem, og enda en for en ny funksjon. Du kan bevege deg raskt mellom disse ulike grenene, og du kan flette dem sammen etter behov. Det er en utrolig nyttig funksjon.

Relatert: Construct 3 — Nettleserbasert HTML5-motor uten kode som eksporterer til nett, mobil og skrivebord.

Hinder Til tross for sine mange styrker, har standard-Git to åpenbare svakheter når det gjelder kunstproduksjon: Det er ikke kunstnervennlig. Gits standardgrensesnitt er kommandolinjen.

Det finnes mange kommandoer og alternativer å lære, sammen med underliggende konsepter som avviker tilstrekkelig fra andre versjonskontrollsystemer til å skape forvirring. Dokumentasjonen er rikelig, men ofte vanskelig å forstå. Alt dette summerer seg til en pakke som ikke er særlig tilgjengelig og noe skremmende. Det er ikke bygget for å håndtere den typen store binærfiler som kunstnere lager.

At hvert lokale depot inneholder all historikk og alle revisjoner, betyr at mye raskt endrende kunstverk raskt kan spise opp mye diskplass. Vi fant løsninger på begge disse problemene. Grensesnittet betyr noe Det finnes flere gode grafiske grensesnitt til Git.

Vårt valg: Udemy Game Development Courses — On-demand-kurs som dekker Unity, Unreal, C++, C# og shader-programmering.

Kunstnere må fortsatt forstå grunnleggende Git-konsepter, men en velutformet frontend gjør det betydelig lettere å komme i gang og bruke det. Vi fant ut at Atlassians SourceTree fungerte utmerket i vårt Mac-baserte miljø: det er kraftig, intuitivt og gratis (foreløpig) – en viktig vurdering for en ressurssterk startup. SourceTree-teamet svarte også raskt (< 12 timer) på våre støtteforespørsler sendt via Twitter.

En smart Git-utvidelse Git-media adresserer Gits mangler når det gjelder store binærfiler. Det er en Git-utvidelse som lar deg lagre filer utenfor Git. Git holder fortsatt styr på filversjonene; det lagrer bare filinnholdet et sted utenfor depotet.

Vi planla å lagre de store binærfilene våre i Amazons S3-sky. Ikke så fort Å bruke SourceTree sammen med Git-media byr imidlertid på en fallgruve: overføring av filer mellom våre depoter og Amazon S3 krever at vi kjører en skallkommando; dvs. $ git media sync En arbeidsflyt som tvinger kunstnere til å forlate den relative komforten i et grafisk program for å taste skallkommandoer, er ikke kunstnervennlig. SourceTree gir deg riktignok en måte å utføre denne kommandoen som en tilpasset handling, men det var ikke godt nok.

Kunstnerne ville fortsatt måtte huske å gjøre det til rett tid. Før eller senere ville de glemme det, og noen ville kaste bort verdifull tid på å finne ut hva som gikk galt og fikse det.

Hvordan kunne vi få SourceTree og git-media til å samarbeide gnidningsfritt? Git Wrap Vi skrev et generisk wrapper-skript som valgfritt kjører noen andre kommandoer før og/eller etter selve git-kommandoen. Vi satte det opp til automatisk å kalle ‘git media sync’ før eller etter kommandoer som samhandler med et eksternt depot, etter behov. Vi konfigurerte SourceTree til å kalle wrapperen i stedet for den ferdige Git-versjonen.

Kildekoden til wrapperen er tilgjengelig her på Github. Eventyret fortsetter Jeg skulle gjerne fortalt dere at dette var slutten på historien, at SourceTree og git-media fungerte sømløst sammen, og at vi alle levde lykkelige alle våre dager. De fungerte faktisk, opp til et punkt.

Relatert: Amazon: Game Dev Books & Gear — Spillprogrammeringsbøker, mekaniske tastaturer, skjermer og dev-desk maskinvare.

Dessverre var det ikke godt nok. SourceTree gjør normalt en god jobb med å forhåndsvise bildefiler. Dette er avgjørende for kunstnere når de sjekker inn eller fletter endringer i slike filer.

Men bruken av git-media ødela SourceTrees evne til å forhåndsvise disse filene, fordi det betydde at vi ikke lenger lagret bildene i Git; vi lagret kun versjonsinformasjon om bildene. Vi fant ingen akseptabel måte å omgå dette på; det var en dealbreaker.

Per i dag prøver vi oss på nytt med Gits undermodul-funksjon. Å lagre kunstressursene våre i en undermodul er en annen måte å minimere størrelsen på hovedprosjektets depot på. SourceTree forstår og støtter undermoduler ganske bra, og evnen til å forhåndsvise bilder forblir intakt. Undermoduler har noen særegenheter, men ingenting som ser ut til å forstyrre kunstnernes arbeidsflyt for mye. Følg med her for oppdateringer; vi lar dere vite hvordan det går. blog comments powered by Disqus