Git für die Spieleentwicklung
Massiv viel Spaß mit Git für die Spieleentwicklung Git für die Spieleentwicklung 14. März 2012 Im Laufe der Jahre habe ich verschiedene Versionskontrollsysteme für Film- und Spieleproduktionen eingesetzt: CVS , Perforce und sogar einige hauseigene Tools.
Sie erschienen mir stets als sperrige, aber notwendige Übel – unverzichtbar, um den Arbeitsfortschritt bei großen Projekten nachzuverfolgen, aber gleichzeitig eine ständige Quelle für Verwirrung, Engpässe und mangelnde Flexibilität in der Produktion. Vor etwa sechs Monaten ist Git erstmals auf meinem Radar erschienen. Es wirkte erstaunlich leistungsstark und flexibel. Die Entwickler von Massively Fun nutzten es bereits für die Code-Entwicklung, als ich zum Team stieß.
Ich war gespannt zu erfahren, ob wir es auch für die Kunstproduktion einsetzen könnten. Dieser Beitrag erzählt die Geschichte dessen, was daraufhin geschah. Hintergrund: Was ist Git?
Git ist ein verteiltes Versionskontrollsystem . Die meisten Leute in der Spieleentwicklung dürften bereits mit mindestens einem anderen Versionskontrollsystem wie Subversion oder Perforce vertraut sein. Wie diese anderen Systeme ermöglicht es uns Git, die vielen verschiedenen Versionen aller Dateien eines Projekts nachzuverfolgen.
Subversion und Perforce sind jedoch zentralisierte Systeme – alle Dateien werden in ein Repository eingecheckt oder daraus ausgecheckt, das auf einem zentralen Server liegt. Git funktioniert anders.
Es ist nicht auf einen zentralen Server angewiesen. Jeder Nutzer erhält eine vollwertige Kopie des gesamten Repositories samt seiner kompletten Historie und aller Revisionen. Dieses Design hat zahlreiche wichtige Auswirkungen , von denen die meisten positiv sind. Was Git jedoch in meinen Augen besonders hervorhebt, ist, wie es Branch- und Merge-Operationen nahezu trivial macht.
Verwandte: — Browserbasierte HTML5-Engine ohne Code, die ins Web, auf Mobilgeräte und auf dem Desktop exportiert.
Sie können einen Branch erstellen, um an einer experimentellen Idee zu arbeiten, einen weiteren, um ein unrelated Problem zu beheben, und noch einen für ein neues Feature. Sie können schnell zwischen diesen verschiedenen Branches wechseln und sie bei Bedarf wieder zusammenführen.
Dies ist eine unglaublich nützliche Funktion. Stolpersteine Trotz seiner vielen Stärken weist Git in seiner Standardausführung zwei offensichtliche Schwächen für die Kunstproduktion auf: Es ist nicht künstlerfreundlich. Die Standardoberfläche von Git ist die Kommandozeile. Es gibt viele Befehle und Optionen zu erlernen sowie zugrundeliegende Konzepte, die sich hinreichend von anderen Versionskontrollsystemen unterscheiden, um Verwirrung zu stiften.
Die Dokumentation ist zwar reichlich vorhanden, aber oft schwer verständlich. All dies ergibt ein Paket, das wenig einladend und somewhat einschüchternd wirkt. Es ist nicht dafür konzipiert, die großen Binärdateien zu verwalten, die Künstler erstellen.
Unsere Wahl: — On-Demand-Kurse zu Unity, Unreal, C++, C# und Shader-Programmierung.
Da jedes lokale Repository die gesamte Historie und alle Revisionen enthält, können schnell wechselnde Kunstwerke den Festplattenspeicher rasch auffressen. Für beide Probleme haben wir Lösungen entwickelt. Die Oberfläche zählt Es gibt mehrere gute grafische Oberflächen für Git.
Künstler müssen zwar weiterhin grundlegende Git-Konzepte verstehen, aber ein gut gestaltetes Frontend erleichtert den Einstieg und die Nutzung erheblich. Wir haben festgestellt, dass SourceTree von Atlassian in unserer Mac-basierten Umgebung hervorragend funktioniert: Es ist leistungsstark, intuitiv und (derzeit) kostenlos – ein wichtiger Aspekt für ein knapp budgetiertes Startup.
Das SourceTree-Team reagierte zudem prompt (< 12 Stunden) auf unsere per Tweet gestellten Support-Anfragen. Eine schicke Git-Erweiterung Git-media begegnet den Schwächen von Git im Umgang mit großen Binärdateien. Es handelt sich um eine Git-Erweiterung, mit der Sie Dateien außerhalb von Git speichern können. Git verfolgt weiterhin die Dateiversionen; es lagert den Dateiinhalt lediglich irgendwo außerhalb des Repositories aus.
Wir planten, unsere großen Binärdateien in Amazons S3-Cloud zu speichern. Nicht so schnell Die Verwendung von SourceTree zusammen mit Git-media bringt jedoch eine Tücke mit sich: Das Übertragen von Dateien zwischen unseren Repositories und Amazon S3 erfordert die Ausführung eines Shell-Befehls; d. h. $ git media sync Ein Workflow, der Künstler dazu zwingt, den relativen Komfort einer grafischen Anwendung zu verlassen, um Shell-Befehle einzutippen, ist nicht künstlerfreundlich.
SourceTree bietet zwar die Möglichkeit, diesen Befehl als benutzerdefinierte Aktion auszuführen, doch das war nicht gut genug. Künstler müssten sich immer noch merken, dies zu den richtigen Zeitpunkten zu tun. Früher oder später würden sie es vergessen, und jemand würde wertvolle Zeit damit verschwenden, herauszufinden, was schiefgelaufen ist, und das Problem zu beheben. Wie könnten wir SourceTree und Git-media dazu bringen, harmonisch zusammenzuarbeiten?
Git Wrap Wir haben ein generisches Wrapper-Skript geschrieben, das optional weitere Befehle vor und/oder nach dem eigentlichen Git-Befehl ausführt. Wir haben es so eingerichtet, dass es automatisch ‘git media sync’ vor oder nach Befehlen aufruft, die mit einem Remote-Repository interagieren, je nachdem, was angemessen ist. Wir haben SourceTree so konfiguriert, dass es das Wrapper-Skript statt des standardmäßigen Git aufruft.
Der Quellcode für das Wrapper-Skript ist hier auf Github verfügbar. Das Abenteuer geht weiter Ich würde Ihnen gerne erzählen, dass dies das Ende der Geschichte war, dass SourceTree und Git-media nahtlos zusammengearbeitet haben und wir alle glücklich bis ans Ende unserer Tage lebten. Sie funktionierten tatsächlich, bis zu einem gewissen Punkt.
Leider war das nicht gut genug. SourceTree leistet normalerweise gute Arbeit beim Vorschauen von Bilddateien. Dies ist für Künstler entscheidend, wenn sie Änderungen an solchen Dateien committen oder mergen.
Die Verwendung von Git-media hat jedoch die Fähigkeit von SourceTree zur Vorschau dieser Dateien gebrochen, da wir die Bilder nicht mehr in Git speicherten; wir speicherten lediglich Versionsinformationen über die Bilder. Wir konnten keinen akzeptablen Ausweg finden; dies war ein Dealbreaker. Zum Zeitpunkt dieses Schreibens unternehmen wir einen neuen Versuch mit Gits Submodul-Funktion. Das Speichern unserer Kunst-Assets in einem Submodul ist eine weitere Möglichkeit, die Größe des Hauptprojekt-Repositories zu minimieren.
SourceTree versteht und unterstützt Submodule recht gut, und seine Fähigkeit zur Bildvorschau bleibt erhalten. Submodule haben zwar einige Eigenheiten, aber nichts, was unseren Künstler-Workflow allzu sehr stören dürfte.
Bleiben Sie dran für Updates; wir lassen Sie wissen, wie die Dinge ausgehen. Blog-Kommentare bereitgestellt von Disqus
Schnellere Lieferung mit vorgefertigten Unity-Assets
Vorgefertigte Grafiken, Tools und Vorlagen, die direkt in Ihr Unity-Projekt eingefügt werden