Lots of games have some version of server meshing [e.g. Dune: Awakening]. How is ours different from what you're seeing in every other game?

Well, so you're right. It's not like server meshing isn't already a thing, right? In the past, even Ultima Online had server transitions. Now, they were not necessarily seamless, but you still had server transitions and gridding, which is a typical approach, which is you take the world, you split it into a grid, and then you have servers between them. And then the rest of the different strategies come from how the servers communicate to each other, and how the state is distributed, and how you transition from one to the other. And I think that the areas where our approach differs is that we've extracted the simulation from the game and the replication of the game. So replication is how game server and clients stay in sync. And so when you're in an area and somebody opens the door, the door opens on your client. That's because it's been opened on the server, and it's also because somebody else had authority to send that message to open the door. So this is all replication. Well, normally, you have one game server, and it does both replication and simulation. So we've taken the Star Engine. We've extracted the networking from it, so the replication, into the hybrid. Now, we call it the hybrid because it's the first stage of server meshing, right? But the hybrid has all the networking components. It has the state in its memory. It holds all of the information for the shard. And it does the replication. So you're connected as a client to the hybrid. So you're not connected to the different servers you're actually on. The game server that's simulating your area, you're not even on it. You're not even in active connection to that server. You're actually actively connected to the hybrid. And the game servers are actually clients with authority, if you want, if we simplify. And so that's one area where it differs. The second one is how we separate space. And you alluded to it, which is that our territory mappings, our mappings of how the authority is managed, are in 3D space. So it's not a grid. It's fully made in 3D space. It's 3D space and a tree, which is the other bit. And so what that means is, I'm going to try to make that simple. Let's say I'm on the yellow server, and suddenly there's not enough players on the yellow server, and the location is a bit low cost, then we might want to despawn that server. Well, we can transfer the authority from everything the yellow server is doing to its parent. There is a parent. Whereas when you're doing gridding, that's a bit of a different model. In the past, I've seen solutions for meshing which include adjacent servers talking to each other, for example, things like that. The client actually disconnecting from one server, connecting to the next, which in all of these cases were things that created side effects that we didn't want. So in the past, we did try these things. If I go way back to when we started the server meshing project, that was the first approach, a bit more classical. But we realized, to properly offer what we've shown in, for example, the meshing demo Paul did a couple of years ago, or what you're actually playing now on live, to be able to have bullets completely traverse the transition and hit on the other side of it, we needed to have a solution that was native to how we were doing it. The bet behind it was that the hybrid was going to be fast enough. And so far, it seems like it's working out, though it is a lot of work to keep it at that speed with all the needs that we have. So that's, I would say, the differences in the approach. And every game is going to have its own approach, right, tailor-made to its gameplay. So in our case, we're trying to make the biggest universe ever. And so we need the most scalable way to approach it. Also, we've taken the most difficult route, I feel.