Epic Games Built Lore, a Version Control System for Games

Every game studio that has ever tried to manage a production-scale asset library in Git has eventually had the same conversation. It starts with someone noticing that clones are taking forever, migrates through a half-hearted attempt to bolt on Git LFS, and ends with someone quietly suggesting they look at Perforce. It is one of the most predictable arcs in game development tooling, and it has been playing out for a decade.

Epic Games has now put a name on the problem and an open-source repository on GitHub. It's called Lore, it's written in Rust, it's MIT licensed, and it is squarely aimed at the version control problem that everyone in game development knows exists and nobody has cleanly solved.

Why Git Was Never the Right Answer Here

Git's design philosophy made it dominant for software development. Small files, text-based diffs, distributed history, cheap branching — those properties are exactly right for code. They are exactly wrong for a modern game project.

A single 4K texture can be 50 megabytes. A high-fidelity character model with multiple LODs and texture maps is larger. Multiply that across the asset library of an open-world game and you have a repository that will bring Git to its knees, not because Git is poorly engineered, but because it was never designed to handle this kind of data.

As the Better Stack video demonstrating Lore describes it: "Git was built for code. Mostly text files, lots of small files, changes that are usually a few lines at a time. Games are basically the opposite of that."

Git LFS pushes large files to a separate server and stores pointers in the repo. It works, insofar as it keeps your Git history from exploding. But studios running on LFS tend to accumulate a different set of headaches: bandwidth quotas, storage costs, old asset versions accumulating in history, and the nagging sense that you've added complexity without actually solving anything. The Better Stack demo puts it plainly: Git LFS "feels like a workaround added to a system that was never designed for this kind of data."

Perforce is the industry's de facto answer to this, and it is an answer that works. Triple-A studios have been running on Perforce for decades because it handles large binary files, supports centralized access control, and scales to enormous repositories. The cost of that reliability is literal cost — licensing fees, infrastructure overhead, and the inevitable internal expert who becomes the person keeping the whole thing breathing.

What Lore Actually Does Differently

Lore's core technical approach is chunking and deduplication. Rather than treating a 200 MB texture as a single atomic object — the way Git does — Lore breaks files into smaller chunks, hashes each one, compresses them with Zstandard, and stores the result in a content-addressed Merkle tree. When that texture gets updated, Lore doesn't store another full copy. It stores only the chunks that changed, and reuses everything else.

This is not a novel concept — content-addressed storage and deduplication are well-established ideas. What Lore brings is an implementation built from the start around game development workflows rather than retrofitted onto a code-centric foundation.

Lore also supports on-demand file hydration: you can work with a repository containing terabytes of assets without pulling all of them locally. You download what you need for the work you're doing today. For an environment where artists and engineers routinely need different subsets of a project, that's a meaningful quality-of-life difference from the clone-everything default.

On the workflow side, Lore's local operations — staging, committing, branching, diffing — all happen offline. There's a central server of record, but you don't need it to do your moment-to-moment work. The Better Stack walkthrough clocks branch switching as "basically instant," with no server round-trip required. In practice, this positions Lore architecturally between Git and Perforce: centralized control and access management from the Perforce side, local operational speed from the Git side.

The setup friction is genuinely low. Better Stack's demo shows a server running locally from a single command with a demo flag — no certificate configuration, no OAuth token generation, no service orchestration. That's a notable contrast to standing up a production Perforce instance, which has historically been a non-trivial IT project.

The Gaps Worth Knowing About

Lore is pre-1.0, and Epic has been upfront that APIs are subject to change before a stable release. That matters for anyone evaluating this seriously rather than experimentally.

There's no Git interoperability. You cannot point Lore at an existing Git repository and carry your history across. For studios with years of Git history — however painful that history has been to manage — that's a real migration cost calculation.

Lore is also self-hosted only. There's no hosted service, no "create an account and push" path. You're running your own infrastructure. The open-source release includes the core library, the server, the CLI, and SDKs for multiple languages. The desktop GUI that has been visible in some materials is not part of it.

Performance claims come primarily from Epic, which has obvious motivation to speak well of its own tooling. As the demo notes: "Epic says Lore can handle huge repositories without slowing down the way other systems do. And Epic obviously has experience with some very large projects, but right now most of those claims are coming from Epic themselves." Independent benchmarks at scale don't yet exist. That's not a knock — it's early — but it's a meaningful gap between where Lore is and where it needs to be to credibly threaten a production Perforce deployment.

What This Opens Up

The most interesting thing about Lore may not be whether Epic uses it internally at scale, or whether it eventually displaces Perforce at other studios. It's that Lore is MIT licensed with an open protocol and multi-language SDKs. That's a surface area for tooling that Perforce has historically made expensive to build against.

Game development tools are an underserved category. The pipelines that move assets from creation tools into engines and out to builds are often held together by studio-specific scripts that nobody fully understands and everyone is afraid to touch. Version control sits at the foundation of all of that. A well-designed, open, scriptable foundation matters.

The honest assessment of Lore right now is that it's a credible technical direction in early form. The chunking and deduplication architecture addresses a real problem correctly. The offline-first local workflow is the right call. The setup experience is dramatically simpler than what it's competing against. And it costs nothing to try.

None of that makes it ready to replace a production system managing the assets of an active game in development. Pre-1.0 tooling at the center of a production pipeline is where disasters come from, and studios have enough of those already.

But the problem Lore is trying to solve is real, persistent, and expensive. Version control for large binary assets has been the game industry's unloved infrastructure problem for long enough that even an imperfect early answer deserves serious attention. The question is whether Epic has the sustained investment appetite to get Lore to a place where studios will trust it with the work that can't afford to break.

---

By Mike Wierzbicki | Buzzrag