Vangelys wrote:This is an interview of Benoît Beauséjour (Chief Technology Officer at CIG) that was made during CitCon 2954 at a French content creator's Twitch channel (Joueur du Grenier).
I've translated the entire interview from the language of Moliere into that of Shakespeare, for those who are interested.
Benoît and Fran
I'm making this publication following this post:
https://www.reddit.com/r/starcitizen/co ... ntext=3AndHere's the source of the interview:
https://www.twitch.tv/videos/2280687172?t=4h50m38sEnjoy!
EDIT : I forgot a last minute question very insightful that was asked to Benoit past the goodbyes, it's Q11.
----------------------------------------------------------------------------------------
// Q1:
- Will the performance boost provided by server meshing (static and dynamic) help speed up feature development and give us the stability we're looking for (moving NPCs/Recruiting NPCs/Increasing the number of NPCs)?
BB:
Yes, of course it will. The key with server meshing is that each server will simulate fewer elements. So we already know that when fewer elements are simulated, the server's performance is much better. Sure, it'll speed up development, but it'll also speed up the time it takes us to deliver the patch, yes. At a time when we're getting ready for 3.24 or 3.24.2 or 3.24.1, bringing the patch live is a lot of effort. That's when you discover new things...!
When players arrive on the server, they always do something extra haha. The developers have a way of testing that's more diagonal, right? Players go deeper. So it's going to help us with that, it's going to give us more buffer on performance, which is going to allow us to go a bit faster. And with more subdivision, it also gives us a degree of control we didn't have before.
// Q2:
- Is Dynamic server mesh easily achievable in terms of implementation time, compared with static mesh? Are you confident that this one will come quickly?
BB:
Of course, static server meshing included ALL the technology development. So the low-level code that deals with the network: transmission of packets that are reliable vs. those that are unreliable, all this technology has been rewritten for server meshing. Then the concept of authority, where we're in the process of ironing out all the bugs linked to the transfer of authority, i.e. when you change servers, all the game components must respond to this change of authority.
There are a lot of elements that were badly done at the time, or done unnecessarily, that need to be dealt with. And we're dealing with that right now.
To continue on the subject of server meshing, we're talking about massive transfers of authority. Let's take a large Microtech mesh in its entirety, and decide to bring in a server to look after New Babagge alone. So here we're doing mass transfers of authority that will bring all the transfers to the new server, part of the dynamic meshing development, plus the reconciliation loop that will look at where the players are, where there's a need for servers, and which will distribute the server needs to best serve the players.
That means not only grouping them together, because there's a cost dimension involved. Of course, if we could give each player a server, we'd do it haha!
To sum up, there's less development to be done with dynamic than with static. I hope we'll be able to do this quickly, but already in 4.0 there are certain elements of dynamic meshing that are implemented in the code. That means the ability to switch servers on and off depending on whether there are players or not.
We're trying to make sure we have this same flexibility in 4.0 (internally we call it “almost-dynamic” for a lack of better words haha). But here we are, trying to bring you as much of the dynamic mode as possible in the PU version. But we don’t think we’re heading into a multi-month development for dynamic, we're on the right track at the moment.
// Q3:
- What in-game technology are you most looking forward to, apart from server dynamic meshing?
BB:
Oh. Base building, big time. Everything that's done in the background of base building, everything that's related to manufacturing, there's a lot of new databases, a lot of new services, new schema transfer and so on. Because we want to make sure that if you claim a territory and build a base on it, that it's available on all the shards.
That's a pretty major challenge, but it's really interesting, it's going to change the game a lot, along with crafting. It's going to bring a universe where it's the players who make the economy, and I really think that's the direction the game needs to go in, and we're well on the way to doing that, and that's what I'm most excited about.
// Q4:
- Will the planet systems be placed on a single megamap, or will they be on separate game maps, each with its own skybox?
BB:
In fact, each system is a part of the map. We still have the mega map concept, but we have a branch principle, and each solar system has its own branch. What we call the root of the universe, you really can't have players there, they're always in the star systems. In fact, they're not quite maps as such, but it's the same concept, but it's a big data-set.
So as more systems are added, it's still just the streaming system that comes into play.
// Q5:
- When you jump into a wormhole, do you move physically via coordinates, or is it more of a teleportation system?
BB:
Actually, that's what's really cool. The way the jumps are made, when you enter the jump there's a zone, imagine it's a big ship or a big train.
When the passage opens, all the players who enter the wormhole become part of this train, and as the players move through the passage, the zone moves with you. And the moment you fall into Pyro's authority, into its branch, that's when the zone and the players have arrived in Pyro, then the train/zone is destroyed. Think of it as a big bus haha. So it's really a change of coordinates: one universe.
// Q6:
- Question about the rotation of planets and whether at some point we're going to have elliptical systems, do you have any answers to that?
BB:
Actually, we already have the systems in place, but they're disabled for the moment, because we've discovered a lot of effects through that. It's something we're going to try to bring back, but it's not the priority at the moment, our focus is on bringing gameplay into the game.
But it does have an effect, i.e. if we implement this principle, it will have an impact on the systems for changing zones, etc.
First and foremost, we need to have something stable and solid at the moment before we consider moving on to a new system rule like this.
// Q7:
- You managed to propose 4.0 to the Evocati before CitizenCon, so congratulations on that, but aren't you disappointed that it's only happening now, whereas your goal for 2023 was a summer 2024 release?
BB:
Yes. Of course we're not super happy with the timing, which is to say that 3.24 was a really difficult patch. It brought a lot of features (persistent personal hangars, freight elevator systems...) that really touched on a lot of systems already in place that were problematic.
I talked a bit about this on SC Live last time: there are really 3 systems in the game that are problematic. The traffic control system, the ASOP terminal system, and the transit system (we all know what's wrong with that). Because they're a bit old, we try to update them, but we never have priority over them.
And then server meshing adds to the complexity, so 3.24 really slowed us down. Then in March, during performance testing, we identified that we had to make a detour to install the RMQ system, which gives us better networking performance.
So we're not entirely happy with our timing, but we're happy with the result in the sense that we can see that the technology is functional, and it's really just a first step. As I said in my Action Reports, we're not chasing numbers, we're chasing a real quality of gaming experience. We'll go with what's most stable and functional.
// Q8:
- A more personal question, does Benoit Beauséjour play the game regularly? When was the last time you played the game?
BB:
Well, I play every day or so haha, yes yes yes, I'm a big player! I love it, I made the Simpit at CIG, so at home I've got joysticks, paddles, the big kit, I'm a Sim Games fan in general.
// Q9:
- It was a tough question for John Crewe because all his ships are his babies, but do you have a favorite ship, and if so, which one?
BB:
Yeah, the Hornet. I always want to play the Hornet. The Hornet MKII is my workhorse. That's for the single seat fighter, in the medium fighters: the Hurricane, I love that ship. With a good gunner the Hurricane: Simply unstoppable. And in the big ones... Exploration is Carrack 100%. Back when I heard about Carrack, I was really crazy about it, a real fanboy haha! And as for Cargo, I have a little thing with Drake, so it's definitely Caterpillar.
// Q10:
- We saw in the panels that they talked about Castra, and we saw Nyx too. With the Base Building coming up, of all the systems which one would you like to settle in?
BB:
Nyx. To me, it has to be unlawful, because i like the action. So for me, it has to be unlawful and... it's gonna be hot. :D
// Q11:
- Another question about server meshing, (which is potentially dynamic), with servers managing small zones, generally on planets: What about more global events, how are they managed, are the servers managing them?
I'm referring in particular to cloud movement, or something that hasn't been mentioned for a long time : the movement of stars?
Cause I think that might be pretty complicated.
BB :
Yeah. Actually, on a technical level, we have game servers. These are the others that are part of the Mesh, the Server Mesh. We also have Replicants, which take care of networking. So at the moment in 4.0, we have a Replicant and then several Game servers that distribute the zones to each other. So the system is able to assign a server to a zone.
So we can make sure that wherever there are players, there's good performance, right? The further we get into implementing dynamic mesh, the more responsive it's going to be. So folks, if everyone goes off in an 890 jump, well, we're going to give the 890 jump a server. Okay, it's a bit silly, but that's it. That's what's cool, you know.
Now, there are other levels to this. There's what we call Star Services, which are game servers that aren't assigned to a shard, but take care of the overall universe. They run the game server, it's the same fundamental core of software, but they're only there to respond to calls for remote procedures to coordinate several shards together. So things like Dynamic Weather, for example, are something that can be put into a service and used by every shard.
(Another guy mumble in french to make sure he understood what Benoit explained)
Exactly. Everything that's VOIP is Voice Servers, everything that's social is the group manager and so on. So there are services like that. The entity graph, which handles all the game's persistence, are also services that are partly in the game server, but they're deployed as services that serve everything,
One of the big elements we're currently working on for 4.0, which is a hot feature, is the mission system. So, for example, the mission system in 3.23 or even 3.24, when you accept a mission or a contract, it creates a mission entity on the server. In fact, it's located at 0,0 of the universe! It's an invisible entity, obviously, that persists and follows you, but it's there. TODAY, you can't have that anymore! Because now 0,0 it's another server!
So now we're in the process of moving all mission systems, but into services that will be able to serve all shards. We're talking about Contract Broker, for example, which takes care of all your contracts that are available in your MobiGlass. There's also the Mission Factory, which takes care of creating missions in the game and coordinating the game servers, for example: if I have a delivery mission, we'll create an entity at the first location, and another entity at the drop location, and that'll make it possible to follow up.
The marker system has also been released. For example, something as simple as a party marker in another system... It's really hard to do in the old model. In the old model, you just put in a marker, but now with the new architecture, you have to have a service dedicated to that.
So there you have it, it's all about extracting what's in the current game server (PU) into services that will enable us to manage this more widely.
Interviewer: So we can understand clearly why 4.0 takes so much time.. haha. Thanks for your time, Benoît!
