Epic Games、オープンソースのバージョン管理システム Lore を発表
(lore.org)- Epic Gamesが保守するLoreは、コードと大規模なバイナリアセットを同時に扱うプロジェクトを対象とした次世代のオープンソース版バージョン管理システム
- ローカルで素早く使い始め、必要に応じて拡張でき、共有・再利用データと必要な時点でのダウンロードによって大規模なリポジトリとチームを支援
- 集中型のコンテンツアドレスベースのストレージを使用し、Merkle tree と不変の revision chain でリポジトリ状態と変更履歴を表現
- 大容量ファイルは再利用可能なチャンクとして保存され、sparse workspace と on-demand hydration により、最初からすべてのデータをダウンロードする必要がない
- MITライセンスで公開され、CLI、C/C++、C#、Rust、Go、Python、JavaScript API と複数のSDKリポジトリを提供
コードと大規模アセットを一緒に扱うバージョン管理
- LoreはEpic Gamesが保守する次世代のオープンソース版バージョン管理システム
- データ規模、チーム規模、チームの分散、リポジトリ規模において高いスケーラビリティを目標に設計されている
- コードと大規模なバイナリアセットを同時に使うプロジェクトに最適化されている
- ゲームおよびエンターテインメント業界のプロジェクトが例として挙げられている
- 開発者とアーティストの協業要件をあわせて扱う
- ローカルモードで数分以内に始められ、その後は必要に応じて拡張可能
- チームが高速で直感的かつ実用的な協業ワークフローを構築するための基盤を提供
スケーラビリティと大容量ファイル処理のための構造
-
共有データとAPI
- 主な機能はスケーラビリティと大規模アセット処理に合わせて構成されている
- 共有・再利用データと必要な時点でのダウンロードによって、速度低下なしに拡張することを目指している
- ブランチを高速に作成・管理・同期できる
- CLIを通じてLoreの全機能に1対1でアクセス可能
- C/C++、C#、Rust、Go、Python、JavaScript向けAPIにより、拡張、カスタマイズ、統合を支援
-
コンテンツアドレスベースのストレージ
- リポジトリ構造は集中型のcontent-addressedバージョン管理システム
- リポジトリデータはコンテンツハッシュで保存・参照され、Merkle tree で表現される
- 高速な比較、整合性検証、履歴およびブランチ間でのデータ再利用を支援
- revision のハッシュ署名は、親 revision ハッシュと含まれるデータハッシュを含む revision 状態から導出される
- この構造は暗号学的整合性を持つ不変チェーンを形成する
-
チャンク保存と必要な時点でのダウンロード
- 大容量ファイルとワークスペース処理にはチャンク保存と on-demand hydration を使用
- ファイルは再利用可能なチャンクとして保存され、インデックスベースの参照を使う
- 重複を減らし、大規模バイナリアセットの更新と転送を効率化する
- workspace は必要なファイルデータだけを取得して軽量に保てる
- sparse workspace により、最初からすべてのデータをダウンロードする必要がない
-
サーバーとブランチモデル
- サーバー構造はキャッシュを含むサービスベースのアーキテクチャ
- durable storage の前段に置かれたキャッシュにより、大規模チームと大規模リポジトリのスループット拡張を支援
- ブランチは軽量な mutable reference として動作し、作成と切り替えのコストが低く、基礎データの重複もない
公開リポジトリとドキュメント
- Epic GamesはLoreをMITライセンスで完全にオープンソース公開
- Lore Library, Server & CLI
- Javascript SDK
- Python SDK
- C# SDK
- Go SDK
- ドキュメントとシステム設計文書は Lore docs と system design doc で提供されている
2件のコメント
Hacker Newsの意見
ゲームをやったことのないHN読者向けに文脈を補足すると、これは一般的なソフトウェア開発でGitと競合しようとしているツールではなく、ゲーム開発で Perforce と競合しようとしているツール
Gitはコードのようなテキストベースのファイルには向いているが、テクスチャ、3Dモデル、音声ファイルのような非テキストファイルでの共同作業には非常に弱い。たとえば、2人のアーティストによる非同期の変更を合理的にマージする方法がないので、あるアーティストが編集中のアセットに 排他的ロック をかける必要があることもある
この分野の事実上のリーダーは、プロプライエタリなシステムであるPerforce(https://www.perforce.com/products/helix-core)。ゲーム開発者の友人たちによれば、Perforceはうまく動いているときは素晴らしいが、ツールエンジニアが管理し、ときどき手作業で修正しなければならない程度には問題点も多いとのこと。Git LFSも代替案だが、3〜4人以上のチームプロジェクトではみんなPerforceのほうを好むらしい
ゲーム開発では、特定のユーザーにだけ公開すべきプロプライエタリな成果物が存在することがある
P4では必要なNDAに署名した人だけが特定のディレクトリにアクセスできるよう制限できるが、Gitでは全部渡すか全部遮断するかになりがち。サブモジュールで何か構成することはできるが、最初からそう設計していなければ、リポジトリ構造を大きくひっくり返すことになる
git clone、つまりp4 syncが テラバイト級 になり得るという点を理解する必要があるGitはこの規模のバイナリアセット、テクスチャ、モデル、サウンドなどを扱うのが苦手
履歴を消せないのはGitの精神かもしれないが、LFSの文脈ではひどく聞こえる。特にGithubを使っているならなおさら
開発初期段階で頻繁に更新されるアセットがあると、リポジトリの寿命が続く限りそのストレージコストを負担し続けることになる。ゲーム開発ではこれはよくある。ほとんどのアセットは初期に何度も行ったり来たりし、完成すると二度と触られない
今日Githubに変更をプッシュしながら、GitのUIがどれほどユーザーフレンドリーでないかを考えていた
Enumerating objects,Counting objects,Delta compression,Writing objects,pack-reused,Resolving deltasといった出力は、筋金入りのGitユーザーには何かを伝えるのだろうが、ほとんどの人にとっては完全なちんぷんかんぷん。「デルタ圧縮」ってそもそも何なのか、なぜスレッドを何本使うのかを知る必要があるのか、そして「オブジェクト」や「local」オブジェクト、「pack-reused」が何を意味するのかも分かりにくいドキュメントを見る限り、Loreはこの部分をもう少しうまく処理しているようだ。
Pushing 1 fragment(s),Pushed 1 fragment(s), 124.00 bytes,Pushed revision 1 -> a3f8c2d1... to branch mainのように見える-vのような 詳細出力オプション の後ろに置くべきだという点には、みんな同意できそう。たぶん誰も手を付けてこなかっただけで、何十年ものあいだ無視する方法を学んできただけオブジェクトはツリーから参照され、ツリーは単なるディレクトリ。さらにツリーはコミットやタグから参照されてDAGを形成し、その複数の地点を指す名前付きポインタがブランチとタグ参照: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
ルーズオブジェクトを大量に置いておくのは非常に非効率なので、Gitは定期的にオブジェクトをパックにまとめる。容量を節約するため、パック内でオブジェクト同士を比較して圧縮するが、これが デルタ圧縮: https://git-scm.com/docs/git-pack-objects, https://github.com/git/git/blob/master/Documentation/technic...
プッシュやプルをするとき、Git転送プロトコルは双方がどのオブジェクトを持っているかを列挙して差分だけを送る。さらに、まだパック化されていないオブジェクトを双方でデルタ圧縮して容量を節約する: https://github.com/git/git/blob/master/Documentation/technic...
Gitはオタクたちが作ったオープンソースプロジェクトなので、こうした情報を全部表示する。無視してしまってよい。本当に知りたいなら、上にリンクしたGitの本とドキュメントディレクトリにすべて文書化されている
だんだん納得してきた。UIの観点ではGitより大きな改善。ただ、ブランチのワークフローには慣れるまで少し時間がかかる
.gitディレクトリを直接のぞいてみることを強く勧める。そうすると、新入社員向けのGitサポート需要は実質ゼロに近くなるこの発表は特にUnrealゲーム開発にとって非常に有望だと思う。ほかの用途なら、そこまで強い関心はない
Perforce には明確に競合が必要だ。Perforce が既存の強者である理由は、使い方や運用管理がとりわけ単純だからではない。たとえばブランチ作業だけを見れば、実際には Git のほうがずっと単純だ
ゲーム開発で P4 がよく好まれる理由は、ほかのコメントでもすでに挙がっている大規模プロジェクト対応、権限管理、ファイルロックなどだ。もうひとつの重要な理由は、P4 が Unreal Engine 内で非常によくサポートされていることだ。完璧ではないが、Epic が社内で使っているツールなので、最も手厚くサポートされているバージョン管理システムだ。Git プラグインは Epic が社内で使っていないため、痛いほど未完成だ
だから Lore は一級のサポートを受けるだろうと期待している。Unreal のサポートがもっと良ければ、Git をずっと積極的に勧めていただろう。背景を言うと、私はほぼ20年間ゲーム開発をしてきて、2人規模から200人規模の会社まで、あらゆるエンジンとバージョン管理システムを経験してきた。使える場面では Git を好むが、Unreal では小規模プロジェクトか、技術に明るいチームメンバーがいる場合くらいだ。仕事とチームに合った道具を選べばいい
https://github.com/EpicGames/UnrealEngine/pull/14630
以前いたゲームスタジオでは Perforce、正確にはHelix Core Cloudを使わざるを得なかったが、クリエイティブ職の大半がすでに慣れている事実上の業界標準だ。プログラマーには不評だが、ゲーム業界で主導権を握っているのはプログラマーではない。Unreal Engine 5 と一緒に使うにも、安全で実績のあるデフォルトだ
ただし古さは残っている。私たちは小規模で自前ホスティングを望まなかったので、初期に Perforce のクラウドサービスを使っていたが、体験はかなりぎこちなかった。サービスにアクセスするには Azure アカウントを登録する必要があり、トリガーのようなものを変更するにはサポートチームに依頼しなければならなかった。GitHub やほかの SaaS 製品の世界から来ると、古いモデルに新しい外装をかぶせようとした試みに見えた
Git LFS の道も非公式サポートは多少あるが、問題がこじれたら自力で解決するしかない。Epic はそこではあまり助けてくれない。特にエンジンで完全な公式サポートを目指すなら、この領域での競争は歓迎すべきだ
テキストベースの開発から来た人向けに、ゲーム開発の世界でファイルマージが一般的でない理由を書いた: https://www.kuril.in/blog/why-game-devs-dont-merge-files/
さっき Git を使っていたチームを引き継いだところだが、Git がみんなに好かれているバージョン管理システムなのは分かるものの、ゲームにはほぼ最悪の選択に近い。Git ではアートレビューの時間を時間単位で測ることになり、Perforce なら秒単位になる。冗談ではない
UE5 が使う興味深いツール、たとえば Horde や UBA のようなものは Perforce を要求する
しかし Perforce は業界での地位にあぐらをかいて何もしてこなかった。非常に高価で、ホスティング運用にも費用がかかる。自前でホストしなければならず、性能面でもそのほうが良いが、最初のセットアップ後の保守は本当に苦痛だ。何か試そうとしている気配はあるが、明確な方向性がなく、やってきたことのほとんどが常識やユーザー層とずれている。中核製品は名前だけ変わり続け、実際の改善はない
プロプライエタリソフトウェアがどうやって牢獄になるかを示す教訓だ。Swarm より良いコードレビュー用ツールを使いたいし、自分の環境でセグフォを起こす奇妙な LUA フックなしで SSO を統合したいし、巨大な SSD やジャーナルバックアップに依存する代わりに分散ストレージバックエンドを動かしたい。しかもライセンスはメインサーバーの IP アドレスにひも付いていて、バックアップからの復旧すらできない
忘れ去られた技術で、その会社を動かしている組織はゾンビのようだ
権限の問題が整理されたのか、あるいはファイル単位のチェックアウトが従来のブランチベースの作業とどう相互作用するのか、そういう混成的な分散/中央集権型バージョン管理モデルが整理されたのかはよく分からない
FAQを見ると、実際にはまったく新しい製品ではなく、ようやくオープンソースとして公開されたものらしい。
「以前は Unreal Revision Control と呼ばれていた Lore は、UEFN（Unreal Editor for Fortnite）に組み込まれたバージョン管理システムであり、クリエイターが自分の島のバージョンを管理するために使ってきた。Epic の内部チームでも段階的に採用が進んでおり、UEFN の cook パイプラインのバックエンドリポジトリとして実装中で、既存の中間ストレージ層を置き換えて重複ファイル転送をなくし、変更を公開してからプレイ可能になるまでの時間を大幅に短縮する」という説明がある。
Epic C++ や Verse ではなく Rust なのが驚き。理由が気になる。
Verse ではなく Rust なのは、その仕事が Verse に向いていなかった可能性が高いからだろう。Simon が Verse に取り組んでいるとしても同じだ。Haskell ではなく Rust なのは、おそらく性能のためだろう。DARCS も性能問題のせいで広く定着しなかった面がある。
しかも、エンジンのあらゆる問題や遅さに自分を縛り付けることになる。Epic は Epic Games Launcher でこの失敗をした。実質的にエンジンのインスタンスを動かす形になっていて、さまざまな問題の大きな原因になっている。
Verse と Rust を比べると、Verse は UEFN 体験の中で使われるが、まだ本番運用にはほど遠い。また本質的に UEFN に縛られている。スタンドアロンのコンパイラや REPL をダウンロードできるわけでもない。
もちろん、開発をやめることにしたので公開するというケースなら別だが、ここではそうは見えない。
Full-surface API は、ここで誰も触れていない機能だ。Git が意図的にリンク可能なライブラリを提供していない点を狙った表現なのか気になる。以前にこの記事を見たことがある: https://news.ycombinator.com/item?id=48470604
porcelainがある。リンク可能な形ではないが、それでも API ではある。前提は、Git-LFS がいまひとつなので、新しい データバージョン管理システム を Rust でゼロから作るべきだということだ。この前提にはおおむね同意するが、内部的に同じような手法を使う成熟した既存のデータバージョン管理システムもすでにかなり多い。
Pachyderm（Go）: https://github.com/pachyderm/pachyderm
XetHub（HuggingFace が買収）: https://huggingface.co/blog/xethub-joins-hf
LakeFS（Go）: https://github.com/treeverse/lakeFS
Oxen（Rust）: https://github.com/Oxen-AI/Oxen
最近は AI のおかげで、誰でも Rust でコンテンツアドレス化、チャンク単位の重複排除、バージョン管理システムをバイブコーディングできる時代なのかもしれない。
冗談はさておき、Lore は本当にすばらしく見える。興味深いのは、異なるドメインや業界が似た問題を抱えているのに、アイデアの交流があまりないように見える点だ。この場合、AI とゲームの両方で、大規模な 大きなバイナリファイルのバージョン管理 ストレージシステムが必要になる。アイデアを共有する機会は多そうで、現状で共有が足りていないこと自体が機会を生むかもしれない。
この違いだけでも、異なるストレージアーキテクチャが必要になる可能性がある。
問題の一部は、Git 自体と、ハイブリッドストレージを維持するために必要な妥協にあったと思う。だから、このバージョン管理システムが Git を使わない点はうれしい。xethub も Git を使わないバージョンの製品を出し始めたが、試す機会はなかった。
oxen も使ってみて、最初は悪くなかったが、すぐにリポジトリの状態に関する奇妙な問題に遭遇し、深くデバッグはしなかった。こうしたシステムを一通り経験してみると、どれも 100% 満足できるものではなく、データのための Git は些細な問題ではないことがはっきり分かる。
どこかの会社が実際にこのシステムを、たとえば 2年以内にデプロイ するのか疑問だ。
Helix や Perforce は何十年もこの仕事をしてきていて、中核事業の一部でもあるので信頼できる。今後もしばらく製品を保守し続けるだろうと分かる。
しかし Epic は、明日このプロジェクトを捨てても事業には何の影響もない。むしろ開発リソースを取り戻せて、事業にはプラスかもしれない。
Cloudflare が EmDash に長期的に投資し続けると、なぜ信じられるのかという話に近い。Cloudflare は CMS に関心がない。読者、執筆者、サイトオーナーに最高の体験を提供することが彼らの事業ではない。本業とはほとんど関係のない副業に近い。
この領域には昔から今に至るまで PlasticSCM というかなり良い競合があった。数年前に Unity が買収したが、Unity は良い管理者ではなかった。
Epic がやっているようにオープンソース化すべきだったのに、代わりに損益責任を負わせる方向を選んだ。Unity の財務にどれだけ貢献しているのか気になる。
Lobste.rsの意見
コードと大規模なバイナリアセットを一緒に扱うゲーム／エンターテインメントのプロジェクト向けに最適化したということは、ついに誰かが Perforceの数十年にわたる独占にうんざりして何かを作ったということかな
最初に見たときは違った気がするけど、なぜ今になって vibecoding タグが付いたのか気になる
たとえば「MercurialとSaplingはテキスト履歴中心で、Loreはバイナリ優先」という説明は誤り。Mercurialもバイナリオブジェクトモデルの上にテキスト機能が載っている構造だ
Mercurial/Saplingの開発に関わった立場からすると、LLMがチームの見落とした代替案を指摘することで厳密さを高められると信じているが、この文書には失望した。判断そのものには利点が多いが、もっと 厳密に書かれた文書であってほしかった
2026-06-17 12:56 (Users)
Story: Epic Games announces Lore version control system
Action: changed tags from "release vcs" to "release vcs vibecoding"
Reason: Automatically changed from user suggestions
もしかしてこれはEpic Gamesが公開した最初の Rustプロジェクト？
これとCursorの最新のバージョン管理システムの話を見ると、最近はみんな VCS を作ろうとしている雰囲気がある
最初に思ったのが「これは lore上でホスティングされるべきでは？」だったのは自分だけ？