In this interview segment, Rashid Mansoor explains MetaGravity’s ambition to transcend the constraints of conventional game engines. He outlines how current engines support single‑player narratives and multiplayer experiences limited to roughly 100 players due to the need for a causally self‑consistent world—where every action (e.g., moving a cup) must be reflected identically for all participants. Mansoor identifies the core technical barrier: real‑time computation on a single CPU cannot scale arbitrarily, and slowing down is unacceptable for games. The proposed solution is to parallelize and distribute the simulation across multiple CPUs or server nodes, but this raises complex problems of partitioning the world into sub‑programs while preserving a unified, consistent reality across them. The discussion highlights the open research problem of achieving large‑scale, real‑time, distributed simulations without breaking causal consistency.
Chapters
Because now we're looking at simulation as a proxy or as a mean of understanding the world around us, which also leads us to what you're building today with MetaGravity, which is essentially a hyperscale simulation engine. But I let you explain it and let you make the bridge between these complex systems and MetaGravity.
Yeah. So I wouldn't quite describe it necessarily as a simulation engine. What we are doing is we're working— so today, if you look at game engines, they've done a good job of building a lot of the features you need to build an interesting, entertaining simulation. And that the games have tried to approximate nature to an extent.
Right.
So what MetaGravity is really doing is looking at the limitations of game engines. And today, individual game engines, you have single-player games and you have a story. But then you have multiplayer games and you're interacting as part of a world. And that can kind of be pushed to the extreme. We have games like Fortnite, which have about 100 players. in a shared experience where you're playing competitively for a period of time. Yeah. There have been games from the late '90s and early 2000s that have tried to push this even beyond and have these big immersive worlds that you're all part of. But there's a limitation to how many players you can have in any single kind of causally self-consistent reality. You can only have about 100 players. And by causally self-consistent, what I mean is, so if I move this cup, then for 100 other, for 99 other players, this cup should have moved as far as their reality is concerned. You can't continue to extend that arbitrarily because at some point your CPU can't compute that world without slowing down. And if you are a game, you have to do it in real time, so you can't slow down. So you set a limit on how big your world can be.
Yes.
The alternative is to find a way to parallelize that, but that's a very difficult I would argue, open problem.
Parallelize that. What do you mean by parallelize?
You need to distribute that compute. Like, instead of having a single world where that reality is self-consistent and all running on one CPU, you need to be able to do it on multiple CPUs, multiple server nodes, and so on.
Oh, so then it becomes hard to align and make sure that everything runs smoothly at the same time in a coordinated manner.
Yeah. So it's not even just about it running smoothly, but how do you really take a simulation of reality and break it down into multiple smaller subprograms? And then if you do that, how do you make sure the subprograms are self-consistent, that they are representing the same view of reality in their sum rather than incongruent realities across them?
