Cataldo "Aldo" Fanelli

Yes, that's correct. We had to update the backend services with the trajectory constantly, if you allow me to say this word, and do a little prediction in order to be able to detect when someone is actually being enforced by another player. So we have to track both the position of the player who is activating a quantum snare and the player who is quantum traveling, in order to detect when they get caught by the Mantis. This was basically the main challenge in this development cycle that we had to tackle.

It was a lot bigger too, because for the longest time since we've had quantum drive, the moment you activated the device was when we determined whether you were going to get interdicted or not. And I know some players used that to their advantage, because that's when we streamed in the mission, and they could go, oh, I could cut off my device and not get interdicted. So now, other than knowing we're going to fix that, some of the work Aldo did was... well, what did you do to fix that?

Oh yes, we basically had to send constant messages to the backend services, and we had to tweak the probability of being interdicted by an environmental mission, and we basically had to run this sort of prediction of the trajectory to have the backend services correctly locate you and the enforcement device.

Before, you had the jump from A to B, we detected that you get interdicted, cool. Now, since we have player devices, they could just turn it on, but we still wanted you to get interdicted during that travel. So some of the work that you had to do was: as you're traveling, we now send consistent messages with your prediction model to see how far out, or whether, you would get interdicted. And I know there were some fun complications that you ran into with the notification and the effects of the interdiction, because we have that warning that we want to give you that you're about to be interdicted. But if someone just pops up a quantum interference device right in front of your face, there's only so much time we can give you before you're smacking right into it.

And to get out of quantum travel in the exact predicted position where you should. Yeah, we had to do a little bit of math for that. Just a little bit.

Do you want to talk about how some of the difficulties came from how fast quantum travel actually occurs, and the fact that the quantum travel path isn't always a straight line?

Correct. Oh yes, the spline quantum traveling thing. When you travel on the surface, the predictive model needs to be a little bit more complicated than if you travel in deep space, because that's basically a straight trajectory, if you will. When you quantum travel on the surface, it's a curve, and so the predictive model needs to be tweaked and adapted, hopefully in an optimized way, I do hope so, to factor this in and have the trajectory correctly calculated by the backend services, in order to correctly find the intersection between the trajectory and the interdicting bubble. This was one of the problems we had to tackle, and we are actually still working on it.

There was actually another fun one too. This goes with Kirk saying that quantum drive isn't always traveling in a straight line. It depends on your perspective. If I'm traveling from point A to B, it will look like I'm going in a straight line. But the moment you hit one of those planets that orbit, from your point of view, you're going in a straight line, but from another person's point of view, you're actually orbiting around, because as you orbit, you're traveling toward the planet. And the backend services don't know anything about zones or this orbital rotation. So some of the work that Aldo had to do was not only to send the information in world space to the backend, but also to predict where the quantum jump would be during that rotation. I know that's ongoing work right now, and there are some complications with the sampling, because you're sending, I think it was every two seconds, roughly...

Roughly.

And then the backend does a smooth interpolation. But there was a problem with that, because our quantum drive does, was it fourth-order motion, where it does velocity, acceleration and jerk.

Yes, the rate at which acceleration changes when you jump. That caused complications.

So the time that the backend gave us corresponded to a completely different position than where we thought we were going to get interdicted. That's where the fun maths had to come in: this is where the backend thought we were, and we have to readjust to figure out where we would actually be.

Yes, you reproject the time in space, and that enables the code to calculate where that point is on the correct trajectory of the quantum travel. And that triggers the calculation of where you're going to get out of quantum travel correctly. So we hope we got it right.

We'll find out when we see how players use it. To sum up, one of the major changes we made is this: before, with the AI mission interdiction, we could basically calculate or predict where you were going to get stopped. Now we actually have to dynamically figure out whether you would get stopped, and, when you actually enter the position that we predicted, whether the quantum snare volume is still active at the time. So that was the major change.

And then some future stuff. I was mentioning before that we want to move some stuff into the backend services. Well, we're bringing in some new technology to write our services in a way that's more focused on how the game objects work. Right now, a lot of our backend services are written in C# or some other language, I forget which, but it's a whole different story. It doesn't know how the game world works. It just makes some approximations. These new service APIs are very hooked into the game, and they know about the same structures as the game does. They're more on the C++ level, which allows us gameplay programmers to write the code ourselves and not rely on another engineer whose sole focus is the backend stuff. And that would hopefully open up the doors to account for some of the issues with the zones, so we could account for them correctly in the backend rather than doing these little hookups and fixups on the game side. So again, it's just one of those tier zero things. This is the tech that we have, here's how we can solve it, and then when the newer tech comes online, we can improve it.

Right. And the improvements that Mark's talking about would maybe allow us to do longer-range radar or longer-range pings, or just get further distance and more fidelity for scanning, for example.

And less CPU consumption with this new technology once it's available, and it will also enable more features and more power. Space is big. And it moves. Everything moves.

The most difficult technical hurdle is probably what we talked about earlier: the predictive model, and having it work with backend services whose model is very simplified. They don't know anything about zones at the moment, so they don't know that you could be in a certain zone that rotates because it's orbiting. So the game server has to do the math and the calculations, hopefully in an optimal way that consumes as little CPU as possible, and send this prediction of the trajectory to the backend services in a simplified but not too approximate way. So I do believe this was the biggest challenge we tackled in this implementation.

There's also the interdiction device itself. For this functionality to work with player interdiction, we had to have the backend be aware of all the interdiction devices that are active at a time. We didn't have the nice new API I was referring to earlier, where we could hook into that with the new services. So we still have the old, or I wouldn't call it old, but our current service that determines whether or not you're going to get interdicted. I think it was the probability volume service. And so we had to work with Tony to figure out how we could give the backend information about these interdiction spheres, along with those segmented interdiction points, to determine whether we actually have been interdicted. Aldo was mentioning those rotating zones: when the interdiction device is on, we have to relay to the backend that we have this bubble and it's at this location, but that location is in world space. So you have to worry about the frequency of these updates, because if you're orbiting and you're going this way and the dot's right here, it will rotate around, and maybe you don't get interdicted, but the backend says that you are. So then we have to take the information that we gave to the backend and go: okay, when we gave them the information, we were over here; when we got the information back, because there are delays sending and receiving, we're now here. Are we actually going to interdict, or is the interdiction point at a new location? So we use the backend service to give us a hint, and then on the game side we look at that and go: that's right, but we're actually going to be here; or, we're not going to get interdicted, but it looks like we are, so let's send another one to see if that hits the backend, because maybe it's on or off. So the problem is not just the device itself, but how to send where the interdiction is and where we're jumping to, and have everyone agree that we actually did do an interdiction.

I think the general issue we had to overcome was that we're dealing with quantum travel. Quantum travel is very fast, and with that speed come big distances. So being able to ensure that we're actually going to hit the mark and be accurate with the collision of the quantum snare volumes and these quantum travel paths, and ensuring that it will work every time, was the biggest hurdle we had to overcome.

Asynchronous communication.

Asynchronous communication.

And we have acceleration getting higher and higher as we move along. One second into your jump, you could be a few thousand kilometers along, which is a lot. But a second later, you could be a few million, just because of our acceleration ramp. So a little small error can add up to a lot of error.