Git ist nicht für Spiele gemacht… Also hat Epic Lore entwickelt

BBetter Stack
컴퓨터/소프트웨어창업/스타트업게임/e스포츠

스크립트

00:00:00Epic Games hat sein eigenes Versionsverwaltungssystem entwickelt, weil sie von Git genug hatten.
00:00:05Sie haben es in Rust geschrieben und dann kostenlos veröffentlicht. Es heißt Lore. Also ja,
00:00:10die Firma hinter Fortnite hat eine Alternative zu Git gebaut. Git ist zwar immer noch großartig,
00:00:15offensichtlich. Aber Git wurde für Code entwickelt. Hauptsächlich Textdateien, viele kleine Dateien,
00:00:21Änderungen, die meist nur wenige Zeilen umfassen. Spiele sind im Grunde das Gegenteil davon. Also
00:00:26wie schlägt sich Lore im Vergleich zu Git und wie arbeitet man damit? Finden wir es heraus.
00:00:35Heutzutage haben wir riesige Texturen, Audiodateien, Videos, 3D-Modelle
00:00:41und alle Arten von Binärdaten, die hunderte Megabyte oder sogar mehrere Gigabyte groß sein können. Und
00:00:47sobald sich diese Dateien ändern, wird es richtig kompliziert. Das Repository wächst, Klone werden langsamer,
00:00:53die Historie wird riesig. Und irgendwann sagt jemand: “Okay, vielleicht sollten wir Git LFS verwenden.” Git LFS hilft,
00:01:01aber es fühlt sich auch wie eine Notlösung für ein System an, das nie für solche Daten gedacht war.
00:01:06Dann gibt es Quotas, Bandbreitenbeschränkungen und alte Assets, die in der Historie hängen bleiben. Deshalb
00:01:12nutzen viele Studios Perforce. Und um fair zu sein, Perforce funktioniert. Es gibt einen Grund, warum so viele Spielestudios
00:01:18es nutzen, aber es ist teuer. Es kann kompliziert werden. Und wenn das System erst einmal groß genug ist,
00:01:24gibt es meist jemanden, der dafür zuständig ist, es am Laufen zu halten. Das ist genau das, was Lore
00:01:29lösen sollte. Wenn du gerne Tools programmierst, um deinen Workflow zu beschleunigen, abonniere unseren Kanal.
00:01:35Wir veröffentlichen ständig neue Videos. Also gut. Anstatt nur über Lore zu reden,
00:01:39ist es cool, es einfach laufen zu lassen. Ich zeige dir, wie es funktioniert. Die Demo startet mit einem Installationsbefehl
00:01:44und einem Demo-Flag, das wir hier ausführen werden. Und das war's. Ein paar Sekunden später
00:01:51läuft ein Lore-Server lokal bei mir. Kein Cloud-Konto, kein Key, kein Zertifikat-Setup. Er läuft hier
00:01:57auf diesen Ports. Und um zu beweisen, dass er wirklich läuft, kann ich einfach den Health-Endpunkt hier aufrufen.
00:02:03Das mache ich jetzt in diesem Terminal. Und da haben wir es. Er ist aktiv. Er läuft.
00:02:08Es gibt keine Hintergrunddienste, die ich manuell verbinden muss. Kein Authentifizierungs-Token zu generieren. Es gibt
00:02:14keinen Setup-Assistenten. Es startet einfach. Jetzt erstelle ich ein Repository. Also erstelle ich einen Ordner,
00:02:22richtig? Und wir erstellen dieses Repository. Und jetzt erstelle ich eine große Binärdatei
00:02:27und committe sie, okay? Das ist nur eine Dummy-Datei. Aber erstellen wir eine größere Datei. Ich führe
00:02:32hier DD für Datenduplizierung aus. Anstatt diese 100-Megabyte-Datei als ein riesiges Objekt zu behandeln,
00:02:40bricht Lore sie in kleinere Stücke auf. Diese Stücke werden gehasht, mit Zstandard komprimiert und in einem
00:02:47inhaltadressierbaren Merkle-Baum gespeichert. Wenn der Großteil der Datei gleich bleibt, muss Lore nicht
00:02:52eine weitere vollständige Kopie des Ganzen speichern. Es kann die vorhandenen Stücke wiederverwenden und nur die geänderten Teile speichern.
00:02:58Das passt viel besser für ein großes Binär-Asset. Direkt nach dem Commit sieht man den
00:03:04lokalen Status, der auf der Festplatte erstellt wurde. Es gibt jetzt hier ein Lore-Verzeichnis mit der Konfiguration und den
00:03:10Metadaten. Gut, jetzt wo wir das haben, erstellen wir einen Branch. Okay, ich kann “Lore branch create” ausführen
00:03:17und den Branch benennen. Es funktioniert fast wie Git. Also wechseln wir dorthin. Lassen Sie uns eine kleine
00:03:24Änderung hier vornehmen. Ich erstelle schnell eine Textdatei und committe sie in diesen Branch. Ich ändere sie, dann können wir sie stagen,
00:03:31und dann committen wir sie, richtig? Der Ablauf ist fast genauso wie bei Git. Jetzt wechsle ich
00:03:37zurück. Und das ging praktisch sofort. Das andere Wichtige ist, dass nichts davon einen
00:03:44Zugriff auf einen Server erforderte. Staging, Committen, Branching, Switchen, Diffing – alles passiert lokal. Also
00:03:50obwohl Lore einen zentralen Server hat, fühlt sich die tägliche Arbeit immer noch schnell an und man kann
00:03:56weiterhin offline arbeiten. Es fühlt sich einfach alles leicht an. Jetzt stellt sich die Frage:
00:04:02Wo gehen all die Daten hin? In dieser Demo hier ist alles temporär. Wenn ich den Server also stoppe,
00:04:08verschwinden die Daten. Das liegt daran, dass ich nur den Demo-Modus verwende. In einer echten Umgebung würde man den Lore-Server
00:04:15mit einer Konfigurationsdatei und persistentem Speicher betreiben. Die gleichen CLI-Befehle und der lokale Workflow bleiben exakt
00:04:21gleich. Man weist den Server lediglich auf echte Verzeichnisse oder Objektspeicher hin, anstatt
00:04:27diesen temporären Ordner zu löschen. Git bietet eine Historie von Projekt-Snapshots. Obwohl
00:04:34es intern viele clevere Optimierungen durchführt, ist Lore von Grund auf auf Chunking und Deduplizierung ausgelegt.
00:04:40Bei einem großen, assetlastigen Projekt muss es also nicht jede neue Version der Datei als ein komplett
00:04:47eigenständiges, riesiges Objekt behandeln. Lore kann Dateien auch bei Bedarf “hydrieren” (nachladen), sodass du mit
00:04:53dem Repository arbeiten kannst, das eine riesige Datenmenge enthält, ohne jedes einzelne Asset vom ersten Tag an herunterzuladen.
00:04:59Du lädst nur das, was du für den Teil des Projekts wirklich brauchst, an dem du gerade arbeitest.
00:05:03Eine Sache, die beim Start von Lore ein wenig verwirrend war, ist, ob es zentralisiert oder
00:05:08verteilt ist. Es ist zentralisiert. Es gibt einen maßgeblichen Server, aber die meiste Arbeit,
00:05:15die wir erledigen, findet lokal statt. In der Praxis liegt es also irgendwo zwischen Perforce und Git. Man erhält zentrale Kontrolle
00:05:22und Zugriffsverwaltung, aber lokale Operationen fühlen sich immer noch schnell an und hängen nicht davon ab,
00:05:28dass der Server jede Sekunde verfügbar ist. Es gibt auch einige nette Unterschiede. Lore ist MIT-lizenziert, das Protokoll
00:05:34ist Open Source und es gibt SDKs für mehrere Sprachen, was das Scripting und den Aufbau von Tooling
00:05:39erheblich vereinfacht. Jetzt ist ein guter Punkt, um realistisch zu sein. Lore ist nichts, wodurch ich morgen ein
00:05:45produktionsreifes Perforce-Setup ersetzen würde. Es ist immer noch vor der Version 1.0. Epic Games sagt, die APIs könnten sich
00:05:52vor der ersten stabilen Version noch ändern, und das Projekt entwickelt sich eindeutig noch. Es gibt auch keine Git-Interoperabilität
00:05:58im Moment, und man kann Lore nicht einfach auf ein bestehendes Git-Repository zeigen lassen und die
00:06:03komplette Historie mitnehmen. Es ist auch selbstgehostet. Es gibt keinen gehosteten Dienst, bei dem man ein Konto erstellt,
00:06:09sein Repo pusht und fertig ist. Und die Desktop-App, die man vielleicht hier und da sieht, ist nicht in der
00:06:15Open-Source-Version enthalten. Was du bekommst, ist die Kern-Bibliothek, der Server, die CLI und die SDKs. Die GUI ist nicht
00:06:22Teil davon. Dann natürlich die Performance. Wie ist die Leistung? Epic sagt, Lore könne riesige
00:06:28Repositories verarbeiten, ohne so langsam zu werden wie andere Systeme. Und Epic hat offensichtlich Erfahrung mit
00:06:33sehr großen Projekten. Aber im Moment kommen die meisten dieser Behauptungen von Epic selbst. Es gibt
00:06:39noch keine soliden, unabhängigen Benchmarks. Die Performance klingt also vielversprechend, aber bis wir wirklich
00:06:45anfangen, das zu testen, ist es schwer zu beurteilen, wie es sich schlägt. Solltest du es verwenden? Nun, es macht Spaß,
00:06:50damit herumzuspielen. Erstellst du Spiele? Baust du massive Projekte? Okay, für ein neues Projekt, vielleicht.
00:06:56Wenn du einfach sehen willst, wohin sich die Versionsverwaltung für große Binär-Assets entwickeln könnte, ist es einen
00:07:01Versuch wert. Teste es an etwas Unkritischem, spiel damit herum, sieh dir an, wie es performed und wie der Ablauf ist.
00:07:07Der größere Punkt hier ist nicht, ob Lore Git oder Perforce bald ersetzen wird. Der wichtigere Punkt ist,
00:07:14dass die Versionsverwaltung kein gelöstes Problem mehr war, sobald Projekte mit riesigen Mengen an
00:07:19Binärdaten ausgeliefert wurden. Git hat bei Text und kleinen Dateien gewonnen. Lore versucht, das zu lösen, was danach kommt.
00:07:27Und ehrlich gesagt, ob es gewinnt oder nicht, es ist eine wirklich coole Richtung. Wenn dir Coding-Tipps
00:07:32und Tricks wie diese gefallen, abonniere den Betterstack-Kanal. Wir sehen uns in einem anderen Video.

핵심 요약

Lore bietet eine auf Chunking und Deduplizierung basierende Alternative zu Git und Perforce, die speziell auf die effiziente Speicherung und Verwaltung massiver binärer Spiel-Assets ausgelegt ist.

하이라이트

  • Epic Games entwickelte Lore, ein in Rust geschriebenes Versionsverwaltungssystem, um die spezifischen Anforderungen bei der Verwaltung großer binärer Spiele-Assets zu erfüllen.

  • Lore zerlegt große Dateien in kleinere Stücke, die gehasht, mit Zstandard komprimiert und in einem inhaltadressierbaren Merkle-Baum gespeichert werden.

  • Im Gegensatz zu Git speichert Lore bei Dateiänderungen nicht das gesamte Objekt neu, sondern verwendet vorhandene Stücke wieder und speichert nur die geänderten Teile.

  • Das System ermöglicht die selektive Hydrierung (Nachladen) von Assets, sodass Entwickler nur die für den aktuellen Arbeitsschritt benötigten Daten herunterladen müssen.

  • Lore fungiert als zentralisiertes System, bei dem dennoch alle täglichen Arbeitsvorgänge wie Staging, Committing und Branching lokal und offline ausgeführt werden können.

타임라인

Problematik der Versionsverwaltung bei Spielen

  • Git wurde für Code und kleine Textdateien konzipiert und stößt bei großen binären Spiel-Assets an seine Grenzen.
  • Systeme wie Git LFS wirken oft wie Notlösungen, während Branchenstandard Perforce kostspielig und wartungsintensiv ist.

Spieleprojekte enthalten riesige Texturen, Audios und 3D-Modelle, die bei herkömmlichen Git-Repositories zu extrem langen Klon-Zeiten und einer aufgeblähten Historie führen. Epic Games reagierte darauf mit der Entwicklung von Lore, um eine spezialisierte Lösung für binäre Daten zu schaffen, die die Komplexität von Perforce und die Unzulänglichkeiten von Git umgeht.

Funktionsweise und Workflow von Lore

  • Lore startet ohne komplexe Setup-Assistenten oder Zertifikatskonfigurationen als lokaler Server.
  • Die tägliche Arbeit wie Branching, Diffing und Committing erfolgt lokal und erfordert keinen ständigen Serverzugriff.

Nach einer einfachen Installation startet Lore einen lokalen Server, der über Endpunkte direkt abfragbar ist. Dateien werden automatisch in kleinere Stücke zerlegt und mittels Zstandard komprimiert. Dieser Prozess findet im Hintergrund statt, während für den Anwender der Workflow ähnlich wie bei Git vertraut und leichtgewichtig bleibt.

Architektur und Zukunftsaussichten

  • Lore verwendet einen zentralisierten Server, kombiniert dies jedoch mit einer schnellen lokalen Arbeitsweise.
  • Das Projekt befindet sich aktuell noch vor der Version 1.0 und bietet derzeit keine Interoperabilität mit existierenden Git-Repositories.
  • Die Verfügbarkeit beschränkt sich auf den Kern, den Server, die CLI und SDKs, während eine grafische Benutzeroberfläche fehlt.

Lore ist ein Open-Source-Projekt unter MIT-Lizenz, das vor allem für neue, assetlastige Projekte in Betracht kommt. Da unabhängige Benchmarks zur Performance noch fehlen und die API-Stabilität noch nicht erreicht ist, dient es derzeit primär als spezialisierte Alternative für Teams, die die Grenzen herkömmlicher Versionskontrolle bei großen Binärdateien austesten wollen.

커뮤니티 글

모든 글 보기