La 4.0 de Star citizen aura un Serveur meshing "QUASI Dynamique !" INTERVIEW Benoit beauséjour (CTO)

For sure, yes. But the key with server meshing is really that each of the servers will simulate fewer elements. We already know that when the server has fewer elements to simulate, its performance is much better. So for sure it's going to speed up development. Above all, it's going to speed up the time it takes us to deliver a patch. That is, from the moment we get ready to... for example, 3.24, which just arrived, or a 3.24.2, 3.24.1 patch, it's a lot of effort. Bringing the patch live, and that's really where we discover new things. That is, when players arrive on the server, they always do something more. Developers have a way of testing that's a bit cursory. Players go in depth. So that's mainly what it's going to help with: it's going to give us a bit more buffer on performance, which will let us go a bit faster. And it also gives us some control over that. That is, if we do more subdivisions, we get more of that effect. So it gives us control we didn't have before.

For sure, static server meshing included all the development of the technology behind it. The low-level code that handles the network, so all the network transmission, the packets, the transmission of packets that are 'reliable' versus 'unreliable'. So we have two types of updates. All of that technology was rewritten for server meshing. Then, the concept of authority. And right now we're fixing all the bugs related to authority transfer, that is, when you change server, all the game's components have to respond to that change of authority. There are a lot of them that didn't do the work properly, or where it wasn't necessary in their case. Now it has to be handled, so we're going through that. To get to the dynamic level, we're talking about authority transfer on a massive scale. I have a server simulating, say, let's take a big mesh, all of microTech, and then we decide to bring in a server to take care of New Babbage. At that point there are a lot of entities currently being simulated that have to be transferred. So we do 'mass transfers of authority' that will really carry the whole transfer over to the new server. That's part of the development for dynamic meshing. Plus the reconciliation loop, which will look at where players are, where we need to have servers to benefit players as much as possible. That is, not just grouping them, because there's also a cost aspect to it. For sure, if we could give every player their own server, we would. But at some point, you have to... But on that side, it means there's less development to do for dynamic than to get where we are now with static. I hope we'll be able to do it quickly. There are already some dynamic elements in the 4.0 build. That is, the ability to shut down servers where there's nobody, and to create servers where there are people. We're trying right now to make sure we have all that flexibility, even in 4.0. We kind of call it 'quasi-dynamic'. We're short on words, but we're trying to bring as many features of the dynamic mode as possible into the current version, and we don't think we're heading into a multi-year development for dynamic. We're on a good path right now.

Yes. Actually, for sure we're not super happy with the timing. That is, 3.24 was a really, really difficult patch. It brought a lot of new features. So, persistent hangars, instanced hangars, all the elevator systems, which really touched a lot of systems that are problematic. So in the game — I talked about it a bit on SC Live last time — there are really three systems that are very problematic in the game, because they're a bit old and we try to update them, but we never get the priority on them. It's the traffic control system, the ASOP terminal system and the transit system. Transit handles elevators, trains. Let's be honest, we know what the problem is with that. Server meshing makes it even more complex. 3.24 really slowed us down on our way. Then we identified things during the tests in March, on the performance side, where we had to take a detour to build the RMQ system, which gives us more performance on the networking side. So we're not quite on our timing, but we're still happy with the result. That is, right now we can see the technology is functional. It's really a first step. That is, right now we're on a single replicant. We want to scale wider, we really want to get to player counts that are much higher. But at the same time, as I said in my action reports, we're not chasing a number, we're chasing an experience. So we're going to go with what's stable and what's functional.

Yes, that's cool. On the technical side, we have game servers. They're the ones that are part of the mesh, the server mesh. We have the replicants that handle networking. Right now, for example, in 4.0, we have one replicant and several game servers that share out the zones. The system is able to assign a server to a zone. That lets us make sure that wherever there are players, there's good performance. The further we go into dynamic, the more reactive it'll be. So if, for example, everyone goes into an 890 Jump, we'll give the 890 Jump a server. It's a bit crazy, but that's what's cool. Now, there are other levels to this. There's what we call the Star Services, which are actually game services that aren't assigned to a shard but that take care of the global universe. They run the game server; it's the same fundamental software core. However, they're only there to respond to remote procedure calls so they can coordinate several shards together. Things like dynamic weather, for example, are something we can completely put in a service that can serve all the shards. Everything VoIP is voice servers. Everything social, group management, etc., are services like that. The entity graph, which handles all of the game's persistence, is also services that are part of the game server, but they're deployed as services that serve everything. One of the big elements we're working on right now for 4.0, which is the hot item, is the mission system. So, for example, the mission system in 3.23, how does it work? When you accept a mission or a contract, it creates a mission entity on the server, which is actually at 0,0 of the universe. It's an invisible entity that persists and follows you. But it's there. But now, today, you can't have that anymore. 0,0 is another server. So we're in the process — we've already moved it all — of moving the whole mission system into services that will be able to serve all the shards. So we're talking about the Contract Broker, which handles the contracts available in your mobiGlas, the Mission Factory, which handles creating the missions in the game, so which will coordinate the game servers to know, for example, if I have a delivery mission, we create an entity at the location, the marker is also extracted. For example, something as simple as a party marker in another system is super hard to do in the old model. In the old model, we'd just place a marker. Now we need a service for it. So it's all this extraction of what's in the game server into services that will let us manage it at a larger scale.