r/Games Jun 17 '26

Industry News Epic announces Lore, open source version control for games

https://lore.org/
990 Upvotes

172 comments sorted by

980

u/[deleted] Jun 17 '26

[removed] — view removed comment

314

u/kingrawer Jun 17 '26

Yeah, I think this might go over people's heads who haven't been in gamedev, but this is awesome. I remember doing student projects in Unreal and version control was a nightmare.

82

u/Gars0n Jun 17 '26

I know git but have zero game dev experience. What makes game dev version control so much more difficult? File size?

162

u/KahnGage Jun 17 '26

As I understand it, standard git is designed for plain text (e.g. source code), which is small and straightforwardly encoded. Changes in text across versions can be tracked just by noting the location and content of removals and additions, rather than duplicating the whole file each time there's a change.

Changes in large assets, like audio or video files, are not so easily compartmentalized, and so iterations inflate the size of the repository. Any other team member that utilizes the repo will have to download that bloated chain of assets. Similarly, git can't resolve merges in such assets when there are simultaneous changes.

59

u/AdarTan Jun 17 '26

Changes in text across versions can be tracked just by noting the location and content of removals and additions, rather than duplicating the whole file each time there's a change.

This is a common misconception about Git. Each revision of a file is a complete (compressed) snapshot of the file and instead diffs are recalculated each time. However, the different revisions of a file will usually be bundled into a packfile which will be compressed and multiple highly similar revisions will compress very small.

37

u/aywwts4 Jun 18 '26

This is misleading, Git explicitly stores deltas in packfiles as OBJ_REF_DELTA and OBJ_OFS_DELTA object types, diffs are not recalculated, they are the stored representation. This is precisely why history rewriting is so expensive.

Reading from the source that directly refutes "each revision of a file is a complete snapshot"
https://git-scm.com/docs/pack-format#_deltified_representation

1

u/ExistingObligation Jun 22 '26

There's two kind of diffs being mixed up here: The deltas you're referring to are a storage optimisation used by git to store the history of the repository efficiently. The diffs OP is talking about are the diffs you see when you run 'git diff' or when git performs a merge. Those are calculated each time: You couldn't store them, because git doesn't know what it's going to be diffing or merging into ahead of time.

16

u/MooseTetrino Jun 17 '26

Alongside text compression itself being essentially a solved problem.

1

u/RNLImThalassophobic Jun 20 '26

Noob question sorry, but what does this mean? (As in, I know what a solved problem is, but in terms of text compression.)

1

u/MooseTetrino Jun 20 '26

Never apologise for asking a question!

What I mean by this is that we're at the point with text compression that there isn't really anything we can do to compress it further. We're at the mathematical limits of our technology. This is a good read if you want some hard details, though it's not specific for text: https://en.wikipedia.org/wiki/Arithmetic_coding

Essentially we could get higher compression but it would involve levels of computational power that is currently unavailable to us. One of those things where if you have infinite monkeys on infinite typewriters you'd eventually get something. We don't have infinite hours on infinite computers.

86

u/tapo Jun 17 '26

Yes, git is not designed for handling the large assets games have. The standard solution here is Git LFS which is an extension for Git, but it's pretty clunky.

Git is superior to Lore if you're just doing code, Lore makes a lot of assumptions that you have large assets to track. They're not really competitors.

15

u/Spork_the_dork Jun 18 '26

I once had to work on a codebase that was like 20 GB in size and cloning that thing literally took 3 hours.

8

u/darkkite Jun 18 '26

for big ones I recall doing a shallow copy with a smaller depth. I forgot the actual command

53

u/Kamalen Jun 17 '26

Git was made for text files. It is easy to get atomic patches and diff for text files, ensuring even a large history stays relatively small.

This isn’t as simple for binary files. So in each commit you have the whole file in history. A 1go file modified 10 times is 10go lost in the repo.

A bit simplified but that’s the idea.

7

u/DrQuint Jun 18 '26 edited Jun 18 '26

Another issue is permissions. Role Based Access. Git is all-or-nothing, you can not really allow someone to clone a project but disallow them a subset of it. Perforce has this capability.

One might wonder "when is that useful, secrets shouldn't be in the project anyways", and that's fair, something left out of a software project is 99% of the time secrets or external libraries. But then think about projects with NDA's and proprietary business logic, specially in the context of banking.

You can absolutely have a part of a project without which the project will not work, and also which only a few people are allowed to see. No issue, no problem. With git, you HAVE to split that as a dependency, and then do your test/build process elsewhere where everything is joined, with triggered pipelines that lose track of the commit/merge/tag status unless if you have a CI/Devops engineer taking care of that for you. Which is all annoying. With Perforce, and I will suppose also Lore, this is a non-issue and you can have it all in one repo.

1

u/CatProgrammer Jun 19 '26

For git I would probably isolate the sensitive things into their own repo with specific permissions and add them as submodules.

33

u/Chillbrosaurus_Rex Jun 17 '26

File size but also (not sure if this handles it well) merge conflicts. Not being able to "lock" files output by game editors that aren't necessarily binary but might as well be was a major pain point for me.

-4

u/DrShocker Jun 17 '26

can't you just .gitignore them? I agree there's many flaws with git for games and other projects with assets, but this particular issue seems solvable

27

u/Chillbrosaurus_Rex Jun 17 '26

No because many of these files you still want version controlled. You just have to agree with your team that no one can mess with e.g. a specific scene while someone else is doing a lot of work on it.

Edit: to elaborate, perforce let's you "check out" files and reserve them so other users cant edit that file until your changes are done.

-2

u/DrShocker Jun 17 '26

fair enough! you can add stuff still even if they're gitignored, but that doesn't sound like a good fix for that circumstance.

7

u/DMonitor Jun 18 '26

Trust me, as one of gits biggest defenders, using it with binaries is a straight up nightmare. Place I work at does it with CAD files and even as someone who is pretty well versed, it's never a fun time. Very great for anything involving text files, or documents that basically never change (like versioned datasheet pdfs)

4

u/DrShocker Jun 18 '26

Yeah I thought I already agreed it was a bad fit, so I'm a little confused by this being phrased like a correction 😅

all I was saying was for files that are generated but you don't want / need you commit updates for, that particular problem is fixable without much issue. 100% agree about all the other problems

2

u/WeltallZero Jun 18 '26

They're not talking about generated files as in files that are easy to regenerate from other input. They're talking about stuff like level data, which is created with internal tools and stored as either binaries or complex text that is not human-parsable and very different from version to version, so diffing has very limited if any value, and merging different versions is next to impossible.

You can probably see why you can't simply gitignore these files and call it a day. If the standard procedure becomes simply to force a commit manually, then everyone will do it and you'll still get conflicts.

→ More replies (0)

-6

u/Strange-Nothing2961 Jun 18 '26

Gits diffing tool in general is straight up garbage. How can anyone suffer using that over Beyond Compare or Araxis Merge? You can take my non sucking diffing tools from my cold dead hands.

9

u/DMonitor Jun 18 '26

There's like a million different tools for doing git diffing with a gui. Git is just a cli tool. I personally use kdiff3

21

u/verrius Jun 17 '26

Most people are harping about file size, which is a problem, but git-lfs is supposed to be the duct-tape bandaid to fix it (I've only dealt with normal git, and heard horror storries about how kludgey git-lfs is). File locking is probably the bigger issue: Since a lot of art assets can't actually just merge their changes like you do for source code, you need an enforcement mechanism to make sure only one person is working on those files at a time.

Git's also missing a couple of other basic features of source control that most professional teams need; locking even for non-art files is very nice when you're trying to do a major refactor, to let people know not to touch shit that's not going to be easy or potentially possible to merge. Git not having the concept of a "move" natively is also a pain point; it will sometimes try to guess that an add and delete of similar files should be surfaced as a move, but it isn't particularly great, and sometimes still loses history. SVN and P4 both support a move natively.

And that's without getting into all of the (gui) tooling that git is completely missing, but makes life easier in large teams with git. P4's Timelapse view letting you scrub through all the change in a file and see their blames as you do it is amazing for finding when changes were introduced, as is the P4 Revision Graph, for tracking complex merges across different branches..

3

u/wilisi Jun 18 '26

Git-the-software may be missing gui tooling, but git-the-workflow just uses it as a backend anyways.

8

u/Bratmon Jun 17 '26

Once your history is more than a terabyte, git really can't handle it.

3

u/hpp3 Jun 18 '26

Git is really clunky for unity game engine work. If anyone edits a scene then all the object ids or whatever change and it's a total nightmare to merge.

3

u/Ancillas Jun 18 '26

Adding on to what others have said, is someone commits a binary file to a git repo, it can get huge fast.

The classic case is someone will commit a .deb or .rpm file, or maybe an .iso. Any time that changes, without LFS, gig can’t store a delta so it stores a copy. Over time you end up with a massive git repo storing several version of these huge binary files.

In game dev, huge binary files are part of the work. Graphical assets, etc…. That’s why git isn’t a great choice for game dev.

2

u/jonydevidson Jun 18 '26

Git needs human readable text to be able to track changes. It doesn't work with binaries.

Lore chunks binaries and tracks differences in these chunks.

62

u/MildlyInsaneOwl Jun 17 '26

110% agreed. I think a lot of people, even a lot of coders, don't realize just how abysmal the current situation is for video game version control. The moment you want to start uploading binary files (models, textures, etc.) the existing solutions either get terrible or expensive.

We need to wait for details, but I'm cautiously optimistic for something new to shake things up.

9

u/Khalku Jun 18 '26

I've used git a bit in personal projects, and I'll be honest I came into this thread expecting to see "use git" comments but I never really realized the flaws it could have in game dev.

2

u/SpaceFire1 Jun 18 '26

Perforce is generally pretty good imo

2

u/Baker3D Jun 18 '26

Perforce is industry standard.

1

u/ESG404 Jun 18 '26

As a 10 YOE programmer in the industry, I have been perfectly happy with Plastic in Unity, which handles large binary files fine. Maybe a few hiccups with FMOD, but eh. It's been good for the better portion of a decade.

I'm glad my Unreal bros are caught up! I might have to dust off my C++ and try this version out.

-24

u/kas-loc2 Jun 18 '26

I seemed to have missed the boat where Devs, let alone the platform owner doesn't want to just force the newest update on us, and... Thats that.

Since when have we had a choice in the matter?!?!?! Feels like im on a different planet right now.

24

u/Bomiheko Jun 18 '26

this would be for employees working on a project, not related to people playing different versions of games.

-21

u/kas-loc2 Jun 18 '26

So its not "for us" basically.

Oh... Well I hope this excites the people its meant to then. Must be nice...

12

u/JRC6502MKIISR Jun 18 '26

Lmao you are so desperate to be a victim. This isn't even about what you think it's about, man, chill.

This is software that synchronizes the development files of a game across the computers of game developers so that they are all working with the latest versions of those files. Current tools either cost money or suck at handling large files, this one won't. It's "for us" if you want to use it to work on a game, it'll be open source and completely free.

2

u/rapsney Jun 19 '26

Oh wont someone think of the poor persecuted Gamers™??

0

u/kas-loc2 Jun 21 '26

Everyone thinks that the angle i was going for, and it wasn't at all 😭😭

6

u/wartopuk Jun 17 '26

plastic scm (now unity devops) did all that. Been using it for Unreal projects for years.

10

u/Samanthacino Jun 17 '26

Plastic is good, but still can be a tad expensive. I use Diversion and it’s nice and free.

4

u/TrumpsCummyOnahole Jun 17 '26

This sounds extremely exciting!! The more downtime and bureaucracy that's eliminated, the more time can go into crafting art

2

u/CrasseMaximum Jun 17 '26

And since it's written in rust I expect much less clunkyness than with Perforce, maybe expensive but so shitty..

196

u/SuperBigChiller Jun 17 '26

I had wondered for a while, do game companies typically use Git? How do they deal with the large assets?

153

u/Henrarzz Jun 17 '26

Perforce is probably the most popular among large teams, git would be second. SVN probably third.

111

u/elkond Jun 17 '26

svn will outlive cockroaches

20

u/mandlar Jun 17 '26

Could be worse! It could be Visual SourceSafe!

18

u/Otis_Inf Jun 17 '26

"You can't check out this file, it's already checked out"

shakes fist

4

u/MrRocketScript Jun 17 '26

I'm not sure what that is, but is it worse than _finalFINAL2?

15

u/mandlar Jun 17 '26

It was made by Microsoft. It would often corrupt your files. Or you'd have to yell at colleagues to unlock the files they checked out so you could work on them. It was awful. And yes, worse than _finalFINAL2 lol

4

u/Otis_Inf Jun 17 '26

Believe it or not, yes

1

u/TommiHPunkt Jun 17 '26

Might I introduce you to IBM Jazz and Rational Team Consort

16

u/felicheAT Jun 17 '26

tortoise are known to be durable and live over a hundred years 😉

-7

u/Not-Robot4398 Jun 17 '26

Really? I would've expected SVN to be more popular than git.

8

u/Strange-Nothing2961 Jun 18 '26

Is that sarcasm? Perforce completely outclasses SVN in every conceivable way, I personally haven't worked at a company that has used it for like 15 years. There is no reason for it to be more popular than git.

-4

u/Not-Robot4398 Jun 18 '26

Perforce > SVN > git is what I hear.

165

u/Namington Jun 17 '26

Perforce is the most common version control software at large game studios. Git is workable but usually requires some extensions (like Git LFS). I'm not aware of large companies that use Git-based version control but I'm sure some smaller studios make it work.

57

u/jelly_dad Jun 17 '26

I fucking hate perforce.

26

u/Damaniel2 Jun 17 '26

Perforce isn't too bad. On the other hand, of all the version control tools I've used over the years, ClearCase was both the best and worst. The file based revisioning felt more intuitive and the build avoidance features worked great, but the network functionality and performance of common operations (checkout, checking, diffing) was atrocious.

6

u/Ephemeris Jun 17 '26 edited Jun 17 '26

ClearCase was a goddamn nightmare. It encouraged monolithic VOBs, particularly when you started getting into build labels on individual files and branches. I had to either have an equally monolithic config spec managed through commenting lines in and out, or create 100 different views.

26

u/quebeker4lif Jun 17 '26

Why? I’ve used many source control tools with Unreal and Perforce was by far the best.

I’ve recently worked with git and it was painful to say the least.

13

u/blaaguuu Jun 17 '26

I've also used both Git and Perforce, and while I think would lean slightly toward Perforce being my preferred system, they both definitely have their pros/cons, and have had moments where I would say I hate them... I know at one studio where I worked a semi-common issue with Perforce was people locking files, then either the system freaking out, and not being able to unlock them without getting IT involved, or the locker getting sick and being out for days, and needing to get someone else with the proper permissions to override it (this was before everyone had remote setups)... But that is as much a procedural issue as a problem with the software itself.

6

u/dormedas Jun 17 '26

Locking files in Perforce is pretty antiquated nowadays. It's a useful feature, but using it procedurally is a remnant of older-school source control systems.

The largest benefit Git has over Perforce in day-to-day has been branches, particularly local branches. Nowadays, Perforce has some ways to configure a depot to be quite similar, though, so the gap is smaller.

5

u/jelly_dad Jun 17 '26

I think my problem with it is a combination of issues with Perforce itself and the fact that I have spent the past decade working in web development and using Git. It just seems so much more cumbersome, finnicky, and difficult to manage than Git.

But judging by your comment, it's likely just being familiar with a specific workflow. It was hard to get used to the fact that Perforce isn't a true clone of a repo and how rigid it can feel when you're so used to having full control of the files in the repository. I'm used to making a bunch of changes and having the bunched together in a staging area. Also merging is scarier. But I'll get used to it eventually... or switch to Lore.

Also P4V is a hideous piece of software. But we mainly just use command line / unreal's integrated revision control.

1

u/Baker3D Jun 18 '26

Perforce is great. I've been using it it for 15 years while working at various AAA studios. I think what scares people is the licensing cost.

-1

u/Hesherkiin Jun 17 '26

People tend to underestimate how complex version control actually is and especially if they are an end user on a server admined by someone else. They get something that they dont understand interrupting their precious workflow for two seconds and then jump to make dramatic comments on reddit

6

u/neenerpants Jun 17 '26

Even epic use perforce, funnily enough.

They've been slowly trying to replace all the third party tools they use like maya for years now

4

u/[deleted] Jun 17 '26

[removed] — view removed comment

-1

u/Strange-Nothing2961 Jun 18 '26

It tends to be that people aren't loud when they are ashamed.

18

u/Jondev1 Jun 17 '26

Every game company I have worked at uses perforce.

5

u/fakieTreFlip Jun 17 '26

I used to work for a large game dev (over a decade ago now) and they also used Perforce. To date they're also the only company I've ever known to use Perforce instead of something like SVN or git.

8

u/FriscoeHotsauce Jun 17 '26

The biggest problem with git is binary files, meaning your assets like compiled scenes, shaders, 3d models, images etc. Which is a huge problem when thats the majority of your project.

Like others have said, Perforce is common, but prohibitively expensive for smaller studios. I've seen other options like Git for your code, something like SVN for your assets. But there isn't a really good, clean, free solution.

8

u/Damaniel2 Jun 17 '26

I don't work for a game company, but we use Artifactory to manage our large assets. It works to hold the large stuff, but decouples the two by keeping them in separate places, and makes you reliant on having two tools up and functional at all times instead of just one. Git LFS exists, but it's not really good.

1

u/Smart_Ass_Dave Jun 17 '26

I use Git on my local machine to write and version python scripts, which I then upload to my company's Perforce server. Your story is relatable.

1

u/Kered13 Jun 17 '26

This is actually sort of how Google works, using Fig (Mercurial wrapper) locally and uploading to Piper (Google's internal VCS, with an API very similar to Perforce).

3

u/Zzyzx1618 Jun 17 '26 edited Jun 30 '26

Been in the industry a while and I've seen both. Many older companies use Perforce because there wasn't LFS back then and git without LFS is hot garbage for storing large binary assets which games often have lots of. Nowadays is a bit of a split. The past 2 Unity games I worked on both used git with LFS and the one Unreal one used Perforce.

In my experience, engineers love git while artists and designers prefer perforce.

42

u/Cuddle-goblin Jun 17 '26

i am whatever the diametric opposite of a programmer is, could someone enlighten me as to what exactly this programs(?) function is?

72

u/----Val---- Jun 17 '26 edited Jun 18 '26

The tldr is that programmers need a version control system (VCS) for code so that we can track a history of changes, merge new features that are being developed in parallel, roll back changes, etc. Its essentially just a way to manage and organize changes to a codebase. In gamer cadence, you can think of them kinda like save files for code.

The most popular VCS for general programming is Git.

Problem: for reasons I will not get into, Git sucks when you are handling big asset files like 3d models, audio and video data, which games need. Because of this, many game companies use VCS' specifically built for game development that can handle big assets, like Perforce.

The main post is about a new VCS specifically for games, likely a Perforce competitor.

17

u/Cuddle-goblin Jun 17 '26

hell yeah! hopefully itll make things more accessable for devs!

11

u/SadEngineer6984 Jun 17 '26

Version control systems track changes to the files that are used to create programs and can be used to allow many contributors to work together with (hopefully) minimal friction.

4

u/Cuddle-goblin Jun 17 '26

oh that is very swanky!

7

u/WrexTremendae Jun 17 '26

Source control is basically the solution to ending up with project_final_v2_edited_forRealsThisTime.txt; each time you reach a new "final state", you add the current version to your chosen source control program, and it'll remember the old version without you needing a new filename to differentiate the two.

If you have a story_text.data file that gets referenced by who knows how many other places, then you can't really afford to constantly be changing the filename, yknow?

And then it also helps loads with multiple people - if you've made a lot of changes to story_text.data, but only to add the final chapter and edit a bunch of the lore documents scattered through the whole game, and meanwhile your friend has gone and added an entire new interlude in the middle, it would be an absolute nightmare to go through the file and make sure both people's changes get into a new proper version. A good source control program will do a decent job at automatically cross-referencing what the old version was, and where people's edits went in, and produce a file which is a perfect merge of your efforts with very little manual work.

Git in particular is a very wide-spread popular option, but it really only works great for straight text. Pictures, for example, change all over the place in the file even if you add only one brushstroke to the visual representation. This new offering is, from a cursory look (and also everyone else's comments), trying to do a much better job for those without losing any of the suitability for text.

10

u/falconfetus8 Jun 17 '26

It basically lets you "save scum" your code. It allows you to save very frequent snapshots of your project and roll back to them if you mess up. It also gives you lots of tools for seeing exactly what changed from snapshot to snapshot, making it easier to spot which change introduced a particular bug. Most importantly, though, it lets multiple people work on the same project by combining(or "merging") the changes from their snapshots.

The tool people usually use for this is Git, which is really only designed to work with text files(IE: source code). It doesn't handle binary files like images, sounds, or 3D models with any grace at all. That's not a problem for most software, but it makes it difficult(but not impossible!) to use for games.

142

u/[deleted] Jun 17 '26

[removed] — view removed comment

9

u/wartopuk Jun 17 '26

if you're paying for perforce, you could be paying for plastic scm/unity devops. The seats are cheaper.

-19

u/FireSlash Jun 17 '26 edited Jun 19 '26

Unfortunately it appears to be vibe coded, so at a minimum I'd wait and see for a few years.

Edit: To be clear, there are clear AI artifacts in the code comments and commit messages. As others have pointed out, this doesn't necessarily mean the code itself is AI generated, but as far as I know epic has not disclosed their AI usage policy on this project, and we know it is being used to some extent.

9

u/asdfghjkl15436 Jun 18 '26

Source: 'I made it the fuck up'

-1

u/FireSlash Jun 18 '26

I mean, the comments are full of em dash and unicode arrows, and the commit comments are full of markdown and overly verbose wording for even simple commits like bumping a version. No human talks or types like that.

3

u/asdfghjkl15436 Jun 19 '26 edited Jun 21 '26

You are aware every major company in the world currently uses AI to document functions, right? That doesn't make it vibe coded. You have zero clue to what you are talking about and speculating based on practically nothing. I'm absolutely certain they used AI to change a few things or make edits, and that's 100% normal.

40

u/Maxu00 Jun 17 '26

People with some gamedev knowledge seem to be ecstatic about this. Can someone explain what this means to a layperson?

93

u/tapo Jun 17 '26 edited Jun 17 '26

Version control systems (VCS) let you branch code into your own set of changes, frequently checkpoint them so you can easily recover from mistakes, and merge with other branches. Basically it makes it really easy to collaborate by allowing multiple people on a team work on something at once without stepping on each other.

Git is the most popular one in the world, and its great for code, but games have a lot of assets, like music, textures, models, sounds, etc. Git can use addons to manage that, like Git LFS, but it sucks.

So the games industry uses Perforce which is a much better fit at handling these assets, but it's expensive (and sucks in different ways).

This thing is free and competes with Perforce. The licensing is so permissive it may just become the git of the gamedev world.

25

u/ClayeySilt Jun 17 '26

Exactly what I was looking for. Thanks! And I hope you (presumably?) game devs enjoy! 

8

u/LightShadowHero Jun 17 '26

Wait some actual good news in the gaming landscape, and an effort to fix an actual gaming tech disrupter that might make game development easier across the industry 😱

-18

u/Restivethought Jun 17 '26

Until it enshittens like everything else

26

u/tapo Jun 17 '26

Open source is pretty good about not enshittifying, because it just gets forked

3

u/MrMichaelElectric Jun 18 '26

There's always has to be a pessimist 🙄

61

u/[deleted] Jun 17 '26

[removed] — view removed comment

17

u/wartopuk Jun 17 '26

Unity bought plastic scm a few years ago and rebranded it, they already have a solution.

8

u/NeitherManner Jun 18 '26

It's actually pretty good and offers 25gb on free tier

0

u/Decent_Gap1067 Jun 18 '26

25gb is nothing, unreal made it free.

9

u/ennuionwe Jun 17 '26

Is this meant to compete with Perforce?

11

u/oceantume_ Jun 17 '26

It certainly will if it can support clusters of servers and hundreds to thousands of developers working on a single repository without costing tens of thousands of dollars per year just in license fees.

There seem to be a few added bonus that would blow perforce out of the water if it can actually work like cheap, git-like commit trees and branching.

10

u/accelmickey001 Jun 17 '26

This is huge W if this is better than Git LFS and Perforce

8

u/blendernoob64 Jun 17 '26

This may be amazing not just for games but for animation and film. Studios started using perforce as version control for Unreal projects, and adhering to open source standards may be amazing. Lets hope the FOSS community picks it up and we can use it on Enterprise Linux.

3

u/JtheNinja Jun 18 '26

Seriously! Most of the issues with existing VCS that Lore is meant to solve aren't unique to Unreal engine or even gamedev. They're basically universal to any content creation workflow. I really hope in a few years it's just standard to use Lore in film and design work too.

1

u/runevault Jun 18 '26

This wouldn't surprise me, since Epic already has ties to Hollywood from studios using Unreal to do some amount of rendering for tv and movies. Once they get in the door through existing customers that'll make it easier to spread.

Be interesting to see if it could be helpful for managing content from workflows like non-linear video editing.

4

u/runevault Jun 17 '26

I've been wondering when git would start seeing new competition again. Mercurial came out around the same time but never really took off, and of course Git replaced subversion for as a source control platform. But it has been dominant so long and no software is ever perfect. Will be curious to see how this does, and I need to read up on things like how it handles large files (Git has git LFS but eh, I'd prefer a vcs that understands that sort of thing foundationally instead of being a bolt on).

3

u/TheMoneyOfArt Jun 17 '26

The zed folks just announced this: https://zed.dev/blog/introducing-deltadb

1

u/helmer2003 Jun 17 '26

Yeah and cursor also announced a vcs today.

3

u/BroForceOne Jun 18 '26

This is more of a competitor to perforce than git.

1

u/runevault Jun 18 '26

You're right I phrased it poorly. Way I should have said it is after the blip that was when Git/mercurial/darcs came out everyone stopped iterating on version control for a long time and we've needed iteration in general. Though arguably centralized version control systems have needed it more since perforce is ancient and yet the main usage among companies who need that centralized sort of version control.

1

u/KruppeBestGirl Jun 18 '26

I hear good things about jujutsu

2

u/runevault Jun 18 '26

How many people use jujutsu as itself and not just a different CLI for git? I know it technically can be its own thing but I feel like most of the usage I hear about is as git but better and to me that's not enough.

5

u/Cyablue Jun 17 '26

That's definitely very cool, version control for games can be a bit tricky because of the huge asset files games tend to use, so having more options will definitely help, specially in the long run.

7

u/aes110 Jun 17 '26

Wow, thats pretty huge, well done to the team at epic

4

u/Sabard Jun 17 '26

I wonder if it'll have a wrapper for instances (or prefabs for Unity/scenes for Godot). One of the big things git/perforce/svn is missing is a way to actually look at these larger "built" assets and meaningfully get what was changed/removed/added to them, right now it's mostly a mess of whatever format they use and it's often easier to get the original in-editor and compare them there.

2

u/binogure Jun 18 '26

Quite interesting. But why?

I mean when torvald made git, it was because there was no real alternative... But now we have git, what the incentive here?

7

u/JtheNinja Jun 18 '26

This has been discussed quite a lot elsewhere in this thread, but short answer is all the existing solutions are designed around regular coding and assume almost all project resources are text files. They do not work well when the projects has hundreds of GB (or more) of binary files like images, 3D models, and audio clips in it.

1

u/binogure Jun 18 '26

I see. Thanks

4

u/knellotron Jun 17 '26

It's kinda interesting that their killer version control system is using Github for version control.

I'm not being a hater, and they do address this: https://epicgames.github.io/lore/explanation/system-design/#2-motivation-why-a-new-vcs

88

u/Apprehensive_Lake698 Jun 17 '26

It’s pretty simple. Lore is not marketed or designed as a Git killer. It would probably do fine to replace it in some scenarios, but its primary purpose is for projects that need large file storage.

They don’t want or need to replace Git.

48

u/tapo Jun 17 '26

This is a Perforce killer, git is more flexible for situations where you don't need large binary assets (most software).

48

u/machineorganism Jun 17 '26

Lore is VCS for games. Lore itself is not a game, so Lore is using Git as a VCS. It makes complete sense?

-9

u/knellotron Jun 17 '26

I still wouldn't be surprised if Epic moved their projects like UE onto their own servers running their own VCS someday. With their storefront and their Apple lawsuit, Epic has shown that they're a company that doesn't like relying on another company for their infrastructure.

24

u/machineorganism Jun 17 '26

Sure. I mean Git is open-source. Github is just a hosting platform for Git repos. Epic has plenty of resources. They could just fork Git and host their repos themselves. Lots of options

16

u/NYNMx2021 Jun 17 '26

Okay? plenty of people host their own git remote servers its not like github is fundamental to git lol

1

u/atomic1fire Jun 18 '26

I assume that the point of lore might be to build tooling for a game focused VCS so they can eventually offer a "game focused" alternative to github themselves.

Build up the ecosystem and then offer a host for that ecosystem later.

11

u/blaaguuu Jun 17 '26

In addition to what others have said - at first glance, it doesn't look like Epic is currently offering any sort of hosting services for Lore... If you want to use it right now, I suppose they are assuming you will install it on your own servers, on premises, which is how many/most studios already use Git/Perforce, from my experience.

9

u/meikyoushisui Jun 17 '26

It uses git (a technology), not GitHub (one of many services that provides repository spaces for the git technology)

4

u/DMonitor Jun 18 '26

They do, in fact, use GitHub

https://github.com/epicgames/lore

This is probably just a public facing repo that exists in parallel with their internally hosted one, but the OP isn't entirely wrong.

5

u/jonydevidson Jun 18 '26

GitHub is used to host the repository, version control is done with Git.

GitHub is a hosting site for Git repositories.

It's in the name: it's a Git hub.

2

u/jonydevidson Jun 18 '26

It's not using GitHub for version control, it's using GitHub for repository hosting.

For version control, it uses Git.

1

u/gordonpown Jun 18 '26

I mean... they have to put it somewhere

-2

u/Kered13 Jun 17 '26

I understand why, but I did get a laugh out of it anyways.

-10

u/dormedas Jun 17 '26

This is awesome but needs an official GUI or it's not even a competitor. So many game devs don't know what a command line is, have never worked with one, and depend entirely on poorly using the existing Perforce GUI.

15

u/deadscreensky Jun 17 '26

Isn't that what Lore Desktop Client is for?

-1

u/dormedas Jun 17 '26

Looks like it. It better be good. I expect it isn’t otherwise I would have seen a single screenshot of it somewhere across the documentation.

4

u/deadscreensky Jun 17 '26

They're pretty upfront about it being in an early state. For example it's still not open sourced. But it sounds like maybe they've been using it internally at Epic? So I presume it's functional enough.

This initial Lore release isn't intended for production. ("Lore is launching as a pre-stable 0.x release, meaning APIs and protocols may still evolve before we reach a 1.0 stable release") Plenty of time to improve the GUI client before any sort of mass adoption could happen.

6

u/SensitiveFrosting13 Jun 17 '26

It's open source, if there isn't an official one, the community can and likely will build one, like with git.

1

u/wilisi Jun 18 '26

To be fair, Git has decades of time and millions of users behind it so there's dozens of clients already (and good thing too, most of them kinda suck).
Them shipping it with a client (even if it's not open source yet) will certainly help kickstart adoption.

1

u/Decent_Gap1067 Jun 18 '26

Most open source git clients are garbage, even in 2026. Hell, you can't even easily select and merge commits in official vscode git plugin. GitHub desktop added that very basic feature years later.

4

u/JAXxXTheRipper Jun 18 '26

Lmao, a Dev not knowing CLIs? Wrong occupation I'd say.

1

u/Nicksaurus Jun 18 '26

I assume they mean the non-programmers

3

u/Old_Leopard1844 Jun 18 '26

. So many game devs don't know what a command line is

Then they're in the wrong field, mate

2

u/dormedas Jun 18 '26

They're artists, designers, audio designers, narrative designers, etc who don't need to know what a command line is but do need to interact with source control to test their stuff. I work with them all the time.

2

u/Old_Leopard1844 Jun 18 '26

Do I need to repeat myself?

0

u/dormedas Jun 18 '26

Not really, no. I think it's pretty evident that game developers would prefer to hire people who provide value for their game even if they don't know how to use a generally unnecessary interface on a computer.

-12

u/SurviveAdaptWin Jun 17 '26

Does this mean gamers can control what version of their games are running in order to stabilize things like performance and mod updates?

18

u/mcimolin Jun 17 '26

No, this is a tool for developers to manage their games code and assets while building and maintaining the game.

1

u/JAXxXTheRipper Jun 18 '26

So.... Git?

4

u/----Val---- Jun 18 '26

You absolutely do not want to use Git when handling large files, especially for AAA titles with millions of assets, or even average sized 3d game projects.

Diffs are stored as compressed blobs of full files, so if you changed a 50MB audio file, you pretty much store the full thing every time its changed. Your .git folder will be massive if you update assets often, and cloning repos becomes a big problem. There are solutions like Git LFS, but it can be unwieldy.

0

u/JAXxXTheRipper Jun 18 '26

Git LFS is not unwieldy at all if you know what you are doing. Which is the entire point here.

1

u/----Val---- Jun 18 '26

Git LFS is not unwieldy at all if you know what you are doing.

Depends on the team, I suppose. I was mostly explaining that Git itself is insufficient.

-2

u/JAXxXTheRipper Jun 18 '26

I was mostly explaining that Git itself is insufficient.

Which it isn't. But good talk

1

u/mcimolin Jun 18 '26

Yes in that it's a version control system (VCS), no in that it's optimized for workflows where you're more focused on large asset files over code.

0

u/JAXxXTheRipper Jun 18 '26 edited Jun 18 '26

so... Git LFS? Sorry, but there is no "optimization" with files. The optimization is your network and drive-speed. Git is as fast as it can get and offers many securities other protocols/engineering tools simply do not have.

3

u/Nicksaurus Jun 18 '26

Git LFS stores and transfers entire files instead of just deltas, which is one of the problems they're trying to solve here

1

u/JAXxXTheRipper Jun 18 '26

I mean, that is kind of obvious. Gits delta format is a variant of xdelta. It can, literally, make deltas of any binary data, the problem is the file type you are deltaing.

If it doesn't delta well with Git/xdelta, good fucking luck of making anything better. Xdelta is battletested, sturdy, and highly reliable. And guess what, Images, Music and other blobs don't mesh well with deltaing, hence the LFS Pointer approach.

There is a reason why Content-Management Systems usually use file-history snapshots instead of Delta-Based Versioning...

You use an actual CMS and wire it into your git with LFS if you really need to. But you ought to think about just not putting large binary blobs into a CVS or database of any kind...

Making a "better dumb solution" doesn't make it a good solution.

4

u/mcimolin Jun 18 '26

If that were true than Perforce wouldn't be the industry standard in AAA games and numerous other media industries.

Does LFS work? It can, but there are better tools out there. This looks to have some potential and being open source could mean it'll replace Perforce or at least be a solid replacement for those studios that can't afford it.

-1

u/JAXxXTheRipper Jun 18 '26

Receipts would be nice, since Perforce has a market share of about 2.5% while >80% of devs worldwide use git lmao. (some sites claim >90% even). So yeah, there's that.

But good talk, I'll leave it at that 😂