# Verse aims to make concurrency invisible to game programmers

Markdown copy of https://realalpha.app/s/verse-aims-to-make-concurrency-invisible-to-game-programmers/ on Real Alpha, the best minutes from long interviews with the people building AI. Cite and link the page, not this copy.

- Speaker: [Tim Sweeney](https://realalpha.app/people/tim-sweeney/) · Tim Sweeney is founder and CEO of Epic Games. · Created Unreal Engine and co-created Fortnite, and has led Epic Games since founding it in 1991.
- Host: [Lex Fridman](https://realalpha.app/people/lex-fridman/) · Host, Lex Fridman Podcast · Robotics and AI researcher at MIT; started the show in 2018.
- Show: Lex Fridman Podcast
- Episode: [Tim Sweeney: Fortnite, Unreal Engine, and the Future of Gaming | Lex Fridman Podcast #467](https://realalpha.app/v/477qF6QNSvc/), Apr 30, 2025
- Moment: 3:13:28 to 3:21:14 of the episode (8 min), playing on https://realalpha.app/s/verse-aims-to-make-concurrency-invisible-to-game-programmers/; the episode from there: https://realalpha.app/v/477qF6QNSvc/?t=11608

## Quote

> “the key is that you're running these updates speculatively and you're **not committing their changes to memory** until you're sure that they're free of conflict.”
> — [Tim Sweeney](https://realalpha.app/people/tim-sweeney/) at [3:20:05](https://realalpha.app/v/477qF6QNSvc/?t=12005) · Lex Fridman Podcast

## Takeaways

1. Game-object updates can run speculatively in parallel.
2. Conflicting changes are rerun instead of committed.
3. The goal is safer simulations with many more objects.

## About this segment

Tim Sweeney describes speculative transactions that run game-object updates in parallel, then commit only conflict-free results. The approach aims to remove concurrency work from programmers and scale simulations beyond today's limits.

From “Tim Sweeney: Fortnite, Unreal Engine, and the Future of Gaming | Lex Fridman Podcast #467”, Apr 30, 2025. [Watch the full episode](https://realalpha.app/v/477qF6QNSvc/)

## Transcript

Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.

[3:13:35](https://realalpha.app/v/477qF6QNSvc/?t=11615) verse that allows for concurrency at the scale that you need this is the one biggest technical problem that uh we're working to solve in this generation um and that is taming concurrency so that any ordinary programmer can achieve it by just writing ordinary code it's hard you know So programming on a single-thread computer is hard enough, but it is completely predictable. If you have a language that's deterministic and you run the same code over and over, it's always going to do exactly the same thing.

[3:14:09](https://realalpha.app/v/477qF6QNSvc/?t=11649) And there's no unpredictability about what might happen, right? You're reading and writing variables in some order, and you're always going to see it behave the same. The problem is when you introduce multiple threads or multiple nodes in a data center all working together on a single problem, is that they each want to read and write different pieces of data and change the state of the world as they go.

[3:14:30](https://realalpha.app/v/477qF6QNSvc/?t=11670) And still almost all concurrency in real-world programs today is achieved manually. Programmers are writing this code that might run in multiple threads very, very carefully so that they are negotiating among each thread to get access to data in a way that's going to give them predictable results. and it's incredibly hard it's so hard that we've in five generations of unreal engine every single generation decided we're not going to try to scale up all of our gameplay code to multiple threads manually it's just much much much too likely to go wrong not only for ourselves but for every partner company who licenses unreal engine and tries to use it for building a game.

[3:15:13](https://realalpha.app/v/477qF6QNSvc/?t=11713) It's just a massive foot gun. There's a variety of solutions to concurrency that are all rather suboptimal. One attempted solution was like, just don't try to solve this problem at all. Let's break our program down into microservices. And almost all online websites of massive scale, like amazon.com, work with hundreds of microservices where different servers negotiate with each other by sending messages to each other.

[3:15:37](https://realalpha.app/v/477qF6QNSvc/?t=11737) And by programmers writing those things very carefully, they eventually get to being able to take your orders and not make a mess of them reliably. But, you know, this is totally not scalable to the metaverse, where you have millions of programmers who are mostly not going to be computer scientists. They're mostly going to be hobbyists and enthusiasts and first-time programmers doing stuff for fun. That's never going to work for them, because they'll never be able to envision all the different dependencies between different computations they're running in parallel. But it turns out that there was amazing foundational work done in the 1980s that was made very real by a paper on Haskell Concurrency. Composable Memory Transactions is the name of the paper. And it described the system for transactional updates to programs. And the idea of a transaction is a transaction is a block

[3:16:28](https://realalpha.app/v/477qF6QNSvc/?t=11788) of code that does a bunch of operations on memory. It might read, might write. It might process an order. It might accept an order or reject an order. It might transfer money between one bank account and another. It might make conditional decisions like, oh, you asked to transfer $100 from your account to this guy's account. We're going to see if you have $100. If you don't, we're going to reject it. And if you have $100, we're going to take $100 out of your account and add it to this other guy's account. Without transactions, if everybody's just randomly adding and subtracting each other's bank balances, then you might have somebody read a bank balance, subtract 100, and write it out.

[3:17:03](https://realalpha.app/v/477qF6QNSvc/?t=11823) But in the meantime, somebody has written something else in the meantime, and so you might get inconsistent bank balances arising if you don't have a way of ensuring that these all run in a specific order. So the idea of transactions is its way of dividing an entire program into updates, self-contained updates, that do an arbitrary amount of computation but must run in a single-threaded manner. And in the case of a game engine, that's a gameplay object update.

[3:17:30](https://realalpha.app/v/477qF6QNSvc/?t=11850) When you're playing Fortnite, You see a gameplay object. Every other player is a gameplay object. Every enemy is a gameplay object. Every rocket and projectile and car and thing you see moving around and interacting, it's not just a fixed static part of the world. That's a separate game object. And each of those objects is updated at a rate of one update per frame at 60 frames per second. And so then in the course of Fortnite Battle Royale gameplay, you have tens of thousands of object updates happening every frame with 100 players.

[3:17:58](https://realalpha.app/v/477qF6QNSvc/?t=11878) In a simulation with billions of players, you'd have a whole lot more than that. So right now that's done single-threaded. Yeah, that's done single-threadedly in each game session. This is why Fortnite is 100 players limitation. If you absolutely maxed out a server, maybe today you could get it up to 140 or something. But, you know, it's not going to thousands or millions or billions. and so what we need is a technique for magically automatically scaling our code to that and transactions are the idea and the idea is a transaction is a granule of code that runs its entirety and so the idea of this transactional memory concept is that we're going to have programmers write completely ordinary code reads and writes variables in the completely ordinary way and they're not going to have to worry about concurrency at all and then the system like today

[3:18:42](https://realalpha.app/v/477qF6QNSvc/?t=11922) a program, a computer just runs your program. There's no amount of speculation going on at the programming language level. The idea of transactions is, since we have a bunch of operations we need to know we apply, we apply a large set of them concurrently, but instead of each one reading and writing from global memory shared by all, in which case they might be reading and writing and contending with each other for the same data and might be doing contradictory things to it, we're going to track all of our writes locally. We're not going to write changes out to global memory. We're going to keep track of it in a buffer that's just for that one transaction. It's going to look to that code exactly as if it's running on the global system affecting global game state, but it's going to be isolated to just that one transaction, and it's going to be set aside and buffered up

[3:19:32](https://realalpha.app/v/477qF6QNSvc/?t=11972) for consideration later. We're going to run tens or hundreds or thousands of the updates concurrently. We're going to see which ones had read-write conflicts, because if two transactions don't read and write any of the same data, then you could have run them in either order or simultaneously and it wouldn't have changed the end result. Yeah, the order doesn't matter. This is so fascinating. To imagine this kind of system, arbitrarily concurrent running millions of updates in parallel of gameplay objects, that's the thing that enables the thing that we're talking about, which is tens of millions of people together in one scene.

[3:20:11](https://realalpha.app/v/477qF6QNSvc/?t=12011) Yeah, exactly. And the key is that you're running these updates speculatively and you're not committing their changes to memory until you're sure that they're free of conflict. So you might update 10,000 objects. You might find 9,000 of them were conflict-free. So you apply those 9,000 updates to memory. And they could have run in any order and it wouldn't have changed the result. Now there's 1,000 objects left over.

[3:20:34](https://realalpha.app/v/477qF6QNSvc/?t=12034) Now you have to run those again, try them, maybe interleave them in a different way to get them to eventually commit to memory. And in the meantime, you just throw all their computations away and redo them later. And by doing this, removing this from being a programming problem for the programmer to deal with to being a language problem for us language designers to deal with. And we're moving a vast amount of pain that would be imposed on a million people instead of a vast amount of pain imposed on a small number of people who have to actually make this work.

[3:21:05](https://realalpha.app/v/477qF6QNSvc/?t=12065) That's amazing. That's really incredible. So what's the state of things with Verse?