Lore VCS - a gamedev’s perspective

date: 2026-06-21
author: Peterino

I work at a studio pretty close to epic, and I have a little brother that plays with UEFN and Roblox. To be honest none of the announcements at UnrealFest 2026 really surprised me regarding unreal engine itself.

It's been clear that Tim Sweeny has wanted unreal to become an engine for the metaverse for quite a while and UEFN has been on a collision course with the main releases.

UE6 was always going to be verse + uefn + unreal.

What was unexpected that epic would largely move towards open standards- adopting GLTF, and USD as first class engine formats.

Amongst these other ecosystem announcements, lore was the most surprising (but welcome) announcement... I never would've thought that a perforce competitor was on the bingo cards.

So... is lore the perforce/ git replacement we always wanted as gamedevs?

The Good - It works!

MIT license, rust based, open source. buildable as a library you can embed in your apps. Tim does know how to make a dev happy sometimes.

It has git style workflows.

Workflow in lore is commit and branch based so folks familiar with git will immediately feel at home.

As a user- cloning a repo is as you'd expect.

D:\rb\test\loretest>lore repository clone lore://127.0.0.1:42337/testdepot
Cloning repository 019ee62546697ed392b407e6f0267097 branch main into D:\rb\test\loretest\testdepot
Pull state ef3b958f56899a0599ede1ed21d293ee69444d68ef592f5bd641e40d065c5f1a
Cloned 2345/2345 files (9.18 MiB/9.18 MiB)
Branch main revision ef3b958f56899a0599ede1ed21d293ee69444d68ef592f5bd641e40d065c5f1a
Clone complete in 1.15s

To scan for active state and make a commit:

D:\rb\test\loretest\testdepot>lore stage --scan .
Staging file system changes
Staging 1 files (1 modified, 0 added, 0 deleted, 0 moved)
Staged repository state 0cd593ca55fb3d4cc4fdc746714ece33714b92a173d825e200f81f0881560f7c

D:\rb\test\loretest\testdepot>lore commit -- "What the heck did you just flipping say about me, you big meanie? I'll have you know I graduated top of my class in the Ti"
Fragmenting files and updating tree hashes
Committing staged changes
Committed 1/1 directories, 1/1 files, 110.00 bytes/110.00 bytes (1 modified, 0 deleted)
Stored history for 1 nodes
Repository: 019ee62546697ed392b407e6f0267097
Revision  : 3
Signature : a5036cc4723e0f7f7da2300939607b7090b882bb934a5c28bf84630900d425fc
Parent    : a4c0301a8528b0ad839f344e53c5d377082c8dabff9226e9e1de4222912e3002
Branch    : e726318bbc3fd75ac8733a7e030cc35b
Date      : Sun, 21 Jun 2026 17:21:44 +0000
    What the heck did you just flipping say about me, you big meanie? I'll have you know I graduated top of my class in the Ti
Commit succeeded

D:\rb\test\loretest\testdepot>lore status
Repository 019ee62546697ed392b407e6f0267097
On branch main revision 3 -> a5036cc4723e0f7f7da2300939607b7090b882bb934a5c28bf84630900d425fc
Remote revision 1 -> ef3b958f56899a0599ede1ed21d293ee69444d68ef592f5bd641e40d065c5f1a
Local branch is ahead of remote

However, being a centralized VCS means it can do some intelligent stuff with how it stores the actual bytes during a commit.

For small changes like text that I'm doing here, it will commit to the local store. But doing large binary assets it will actually upload the bytes to the server remotely upon commit rather than during branch merging. You can influence this behavior with --local or --offline. See the reference here: cli

Branching and merging works and basically looks exactly like git but it also shows the three way merge in the file itself upon conflict.

In terms of performance, I haven't directly ever profiled perforce but from my music server stress test we can see a clone happens on the order of 100MB/s which is fine tbh. Not amazing but serviceable and way better than git lfs.

The bad - it works like git

Don't get me wrong I LOVE git. I use that shit every day, I'm the first to say "git gud" when people have skill issues.

But... Skill issues are still issues... and I foresee this being a huge issue at larger productions.

One critical feature of VCS-es (though some would argue its not really a revision control problem.) is they resolve the question of "how do I collaborate on work?"

Git's primary answer is to have your own branch where you integrate the changes you want into your working branch. Then merge back into the main trunk when you're ready to, going through a review process of cleaning up your history at that merge point.

This has issues for art heavy productions.

Big games are /BIG/ I mean.. REALLY BIG. One AAA game depot can be casually >2TiB in size of assets upon checkout.

At those scales you physically can't fit a lot of branches on your disk at the same time. So at these studios- we often use shelves in perforce as a way to quickly cherry pick over changes.

"Yo Buddy, grab my shelf and see if it fixes your problem" - Literal conversation that happens on a daily basis

Buddy then types in my changelist into perforce. They click one button and my code is applied to their codebase like a patch.

They discard the patch with another button when I confirm that my change made it into the main trunk.

For you git enjoyers that don't use p4 much. Shelves in p4 can be thought of as a git patch that is stored on the server, and anytime anyone can grab one and apply it against their current tip.

This is honestly the most missed feature in git for gamedev teams.

Because the equivalent in git is to use cherry-pick to effectively add their change to your revision tree. This works /fine/ for the average cs major who has probably taken at least one algorithms course and can reason about what that means.

But if I have to ask my level designer to resolve merges in his git history, I don't think we're getting anything done today.

The Ugly

All of my complaints in this category are going to be largely based on it's reputation and a general vibes thing.

I did do some sleuthing and had a chance to talk around. It seems lore was originally an in-house revision control system called URC- "Unreal Revision Control."

Various users have reported that it has a lot of instability, and one uefn creator I talked to directly blamed urc for an incident where they lost 3 days worth of work.

Quick search of the support forums finds issues appearing in recent days.

I.. have some skepticisms about how overtly negative some of the chatter I've heard is. I do sort of expect that there will be some complaints about this, for a variety of reasons but primarily one of the bigger ones is that uefn is used by a lot of amateurs, and less technically minded folks. And a lot of the issues seem more like service side problems than issues with lore itself.

I personally can't imagine 3 days of work being lost without shelving/committing in some way. But being on a large production means working with a lot of incredibly talented people and not everyone thinks about data safety all the time so this does speak a bit to lore's state with respect to 'idiot proofing'.

I will also say that when testing lore I ran into a few crashes but they were mostly involving the --stats command.

Attempting to clone my 16GB music library causes caused a crash when invoking --stats. Doing just a quick checkout it seems related to the stats collector itself when doing a commit with fragments that are already uploaded:

> lore commit --stats "crash repro"

Fragmenting files and updating tree hashes
Committing staged changes
Committed 1/1 directories, 128/128 files, 2.00 MiB/2.00 MiB (128 modified, 0 deleted)
Stored history for 1519 nodes
Commit self
  Written fragments         : 0
  Written raw bytes         : 0
  Written payload bytes     : 0 (0% compression)
  Deduplicated fragments    : 0 (0%)
  Deduplicated raw bytes    : 0 (0%)
  Deduplicated payload bytes: 0 (0%)
  Written final bytes:      : 0 (0%)
  Written list fragments    : 0
  Written state fragments   : 0
Chunk size distribution:
panic: panicked at library\alloc\src\raw_vec\mod.rs:28:5:
capacity overflow

Bugs happen and crashes happen but... this is like literally one of the very first commands I ever ran. So... yeah the vibes around quality of the service are not the greatest out of the gate.

I am cautiously optimistic. Being open source and rust, I was able to fix the bug myself locally, and I'll probably open an issue on their github if when I get around to remembering how to log into that site again.

I will definitely put it through its paces and build some tooling around it and try to do a gamejam or two with it as the backing vcs. Because the promise of being free from p4's yoke while still being fully self hosted is far too enticing.

New Possibilities and ideas?

There is a second way to use lore that I think is maybe being a bit undersold right now and it's kinda interesting.

Basically you can use lore as an object server. All objects uploaded to lore as part of a commit or branch is content addressable

For example if i upload an mp3 file:

I can see that it produces these content addressable hashes.

root:
    3bfe886eb6c0754407c7e28c3e9829a34fc08f1a7991205c33b194477e04e576-019ee2ee88dd7b9293b737d8c75aa694

    leaf fragments:
    018b75c41d4942008ceafac6ebef55597943c17a53de46e11a4c21e019f4d573-019ee2ee88dd7b9293b737d8c75aa694
    b47ad88c8f77487adb5c403efc3efe23d2bfa5e56b6c9f345ec6df5818ddbc62-019ee2ee88dd7b9293b737d8c75aa694
    3b9e81abdb35dc0e24395ab21e42a91461112b7528f8ba67dbefe3062a39c5f9-019ee2ee88dd7b9293b737d8c75aa694
    c64070cc2e6b66310792a46c86f8e2641b93926af4be8971131c1fa698cfb8a3-019ee2ee88dd7b9293b737d8c75aa694

I do some testing on this later but the design here is very interesting. I've certainly played with git before in the past as a degenerate object store but this is almost supporting it directly.

What's cool is basically it becomes kind of easy to implement some sort of virtual file system over this backend?

I've certainly worked on some productions where we just stashed compiled binaries directly into perforce itself. Works great for small teams and cheats a lot of the devops work you'd need to ship binaries to your artists.

A psychopathic idea... but with a bit of elbow grease i can easily imagine a world where you're cooking content directly into lore then using it as a content delivery system. EG. shipping thin binaries to your devkits that just have a list of lore content references.

Anyway rest of the subpages here are the amalgamation of my notes and performance capturing from using this thing all week, if you're still interested in having some more data on lore.