Git voor game-ontwikkeling
14 maart 2012 In de loop der jaren heb ik verschillende versiebeheersystemen gebruikt voor film- en gameproductie: CVS, Perforce, en zelfs een paar interne tools. Ze voelden voor mij altijd als onhandige maar noodzakelijke kwaadaardigheden: onmisbaar om werk aan grote projecten bij te houden, maar tegelijkertijd een voortdurende bron van verwarring, flessenhalzen en starheid in de productie.
Git kwam ongeveer zes maanden geleden voor het eerst op mijn radar. Het zag er ongelooflijk krachtig en flexibel uit. De ontwikkelaars van Massively Fun gebruikten het al voor code-ontwikkeling toen ik bij het team kwam. Ik was benieuwd of we het ook konden inzetten voor art-productie.
Dit verhaal vertelt wat er vervolgens gebeurde. Achtergrond: wat is Git? Git is een gedistribueerd versiebeheersysteem. Bijna iedereen in de game-industrie is wel vertrouwd met minstens één ander versiebeheersysteem, zoals Subversion of Perforce.
Net als deze andere systemen helpt Git ons om de vele verschillende versies van alle bestanden in een project bij te houden. Maar Subversion en Perforce zijn gecentraliseerde systemen: alle bestanden worden ingecheckt of uitgecheckt vanuit een repository die op een centrale server staat. Git werkt anders.
Het is niet afhankelijk van een centrale server. Elke gebruiker krijgt een volwaardige kopie van de volledige repository, inclusief de hele geschiedenis en alle revisies.
Dit ontwerp heeft een aantal belangrijke gevolgen, waarvan de meeste positief zijn. Maar wat Git voor mij het meest onderscheidt, is hoe het branch- en merge-bewerkingen bijna triviaal maakt. Je kunt een branch aanmaken om aan een experimenteel idee te werken, een andere om een niet-gerelateerd probleem op te lossen, en weer een andere voor een nieuwe functie. Je kunt snel schakelen tussen deze verschillende branches en ze naar behoefte weer samenvoegen.
Gerelateerd: — Kant-en-klare kunst, tools en sjablonen die rechtstreeks in uw Unity-project terechtkomen.
Het is een ongelooflijk nuttige functie. Struikelblokken Ondanks de vele sterke punten heeft standaard Git twee duidelijke tekortkomingen voor art-productie: Het is niet kunstenaarsvriendelijk.
De standaardinterface van Git is de command line. Er zijn veel commando’s en opties om te leren, samen met onderliggende concepten die voldoende verschillen van andere versiebeheersystemen om verwarring op te roepen. Documentatie is overvloedig aanwezig, maar vaak moeilijk te begrijpen. Alles bij elkaar resulteert dit in een pakket dat niet erg toegankelijk is en enigszins intimiderend overkomt.
Het is niet gebouwd om de grote binaire bestanden te beheren die kunstenaars maken. Het feit dat elke lokale repository de volledige geschiedenis en alle revisies bevat, betekent dat veel snel veranderende artwork snel veel schijfruimte kan opslokken. We hebben voor beide problemen oplossingen bedacht.
Als u aan het winkelen bent: — Browsergebaseerde HTML5-engine zonder code die exporteert naar internet, mobiel en desktop.
Interface matters Er zijn verschillende goede grafische interfaces voor Git. Kunstenaars moeten nog steeds basisconcepten van Git begrijpen, maar een goed ontworpen frontend maakt het aanzienlijk eenvoudiger om ermee aan de slag te gaan en het te gebruiken. Wij ontdekten dat Atlassian’s SourceTree uitstekend werkte in onze Mac-gebaseerde omgeving: het is krachtig, intuïtief en gratis (voorlopig) – een belangrijke overweging voor een krap bemiddelde startup.
Het SourceTree-team reageerde ook snel (< 12 uur) op onze supportvragen via Twitter. Een flitse Git-extensie Git-media pakt de tekortkomingen van Git ten aanzien van grote binaire bestanden aan.
Het is een Git-extensie waarmee je bestanden buiten Git kunt opslaan. Git blijft de bestandsversies bijhouden; het slaat de inhoud van de bestanden alleen ergens buiten de repository op. We waren van plan onze grote binaries op te slaan in Amazon’s S3-cloud. Niet zo snel Het gebruik van SourceTree in combinatie met Git-media levert echter een addertje onder het gras op: het overbrengen van bestanden tussen onze repositories en Amazon S3 vereist dat we een shell-commando uitvoeren; bijvoorbeeld: $ git media sync Een workflow die kunstenaars dwingt de relatieve comfortzone van een grafische applicatie te verlaten om shell-commando’s te typen, is niet kunstenaarsvriendelijk.
SourceTree biedt wel een manier om dit commando als een aangepaste actie uit te voeren, maar dat was niet goed genoeg. Kunstenaars zouden nog steeds moeten onthouden dit op de juiste momenten te doen.
Vroeg of laat zouden ze het vergeten, en dan zou iemand kostbare tijd kwijtraken om uit te zoeken wat er misging en het op te lossen. Hoe konden we SourceTree en git-media toch goed laten samenwerken? Git Wrap We schreven een generiek wrapper-script dat optioneel enkele andere commando’s uitvoert vóór en/of na het git-commando zelf. We hebben het zo ingesteld dat het automatisch ‘git media sync’ aanroept vóór of na commando’s die interactie hebben met een externe repository, al naar gelang passend.
We hebben SourceTree geconfigureerd om de wrapper aan te roepen in plaats van de standaard Git-installatie. De broncode voor de wrapper is hier beschikbaar op Github. Het avontuur gaat verder Ik zou jullie graag vertellen dat dit het einde van het verhaal was, dat SourceTree en git-media naadloos samenwerkten en we allemaal nog lang en gelukkig leefden.
Ze werkten inderdaad, tot op zekere hoogte. Helaas was het niet goed genoeg. SourceTree doet normaal gesproken goed werk bij het previewen van afbeeldingsbestanden.
Dit is cruciaal voor kunstenaars wanneer ze wijzigingen aan dergelijke bestanden committen of mergen. Maar het gebruik van git-media brak de mogelijkheid van SourceTree om deze bestanden te previewen, omdat we de afbeeldingen niet langer in Git opslaan; we slaan alleen versie-informatie over de afbeeldingen op.
We konden geen acceptabele oplossing vinden; dit was een dealbreaker. Op het moment van schrijven doen we een nieuwe poging met Git’s submodule-functie. Het opslaan van onze art-assets in een submodule is een andere manier om de grootte van de hoofdrepository van het project te minimaliseren. SourceTree begrijpt en ondersteunt submodules redelijk goed, en de mogelijkheid om afbeeldingen te previewen blijft intact.
Submodules hebben wel enkele eigenaardigheden, maar niets dat onze artistieke workflow al te zeer lijkt te verstoren. Blijf deze ruimte in de gaten houden voor updates; we laten jullie weten hoe het afloopt. blog comments powered by Disqus
Leer game-ontwikkeling volgens uw eigen schema
On-demand cursussen over Unity, Unreal, C++, C# en shader-programmering