Forums » Suggestions
Debris after the explosion of ships
Here I was on a new test of ship wrecks in Latos D-14. And I instantly came up with an idea. I suggest that those small debris that have their own physics scattered after the explosions of simple players ships and stayed for a while in this sector. This will add more realism and will not affect a lot of resources.
...
Latos D14 and F12 are test sectors of stuff being developed Right Now. Give the devs some time to implement it as they see fit.
RRuslan1999: That's the whole point of what we're developing, actually. We mentioned it a bit in the last newsletter.
But, we have to make the debris work properly first, which is why they're only temporarily rolled out in a couple of test sectors.
And, frankly, they don't work quite right yet.. if you rotate a big one you can see it skipping around and not turning properly, among other things.
But, we have to make the debris work properly first, which is why they're only temporarily rolled out in a couple of test sectors.
And, frankly, they don't work quite right yet.. if you rotate a big one you can see it skipping around and not turning properly, among other things.
It's likely due to my aussie ping of ~250, but the oddest thing I see is the lag between a hit, and conc effect occurring. It's not limited to the debris, I see the same lag between hit and spin when I flare a player's ship too, but I am too pre-occupied to care much at those times. Can anything be done about it, or is it a symptom of my ping?
It's a symptom of how the system actually works. In this case, I really wanted to have physically interactive objects quickly and not "Soon" (tm), so I went for an implementation I knew would work right away, but would have inherent flaws.
Engineering like this is always a set of tradeoffs, but if I had more time, we would have probably built a system that simulates all physical interactions locally and then broadcasts them with a timestamped state to everyone else view, and then the sector records the history of state changes. Thus, when someone new enters a sector, their client re-plays from a given timestamp (super fast) to converge on the same physics simulation point.
It's challenging to do, but it has the advantage of most people's physics interactions appearing to be "instant". There is some weirdness with synchronizing the physical effects over latency for other players, but there are various ways to make that work. However.. all of this would have been really time consuming to implement.
So, instead, all interactive physics with the debris are happening on the server (the sector daemon, to be specific). That's a bummer for us, because it means the sector load increases as it has to handle more complex physics math, making the overall system more of a burden on the server and less scalable.
Eventually, that means as we roll out the new feature across the game, it could increase our server utilization overall, and make the game more difficult and expensive to operate (but, I'm pretty confident we can optimize things and find a happy medium of usage that is a good balance).
It also means that you don't see physical reactions until you get reaction packets from the server. So, you fire a rocket, it takes 250ms to reach the server, which says "hey, your rocket hit this debris and now it's spinning around", which then takes another 250ms to come back to you. Best case, you get to see something happened about 1/4 of a second after you would expect.. which is noticeable. In some cases, like ramming something with your ship, it could be even longer (in the case of the rocket, the in-game flight time may effectively absorb some of the latency).
There may eventually be some kind of happy-medium we can bolt into the system to improve the perceptible lag, where basically both the client and the server do the simulation: the client sending the action and timestamp, and the server receiving the packet and "stepping back in time" to insert the action at the right point, and then re-playing it forward to present. It doesn't resolve the delay for other players, who will still have to deal with some weirdness, but it would improve things for the individual taking the initial action.
Of course, it could also be solved in other ways, like long ago I had the notion of doing distributed sectors, globally, that would fire up as "local" as possible for the first individual to fly into a specific location. So, at 4am (Milwaukee time) you might find a lot of the game running in Australia or Singapore, and at 5pm it would probably be back on the Eastern US, etc. The locality of the sector would help resolve the latency difference. But, of course there are other problems with long-lived, popular sectors, and then the fact that hosting in Asia is really expensive, and so on.
Anyway, TL;DR - No, there isn't anything I can do right now. It'll just have to look weird. But, it's kinda neat, despite looking weird, right?
Engineering like this is always a set of tradeoffs, but if I had more time, we would have probably built a system that simulates all physical interactions locally and then broadcasts them with a timestamped state to everyone else view, and then the sector records the history of state changes. Thus, when someone new enters a sector, their client re-plays from a given timestamp (super fast) to converge on the same physics simulation point.
It's challenging to do, but it has the advantage of most people's physics interactions appearing to be "instant". There is some weirdness with synchronizing the physical effects over latency for other players, but there are various ways to make that work. However.. all of this would have been really time consuming to implement.
So, instead, all interactive physics with the debris are happening on the server (the sector daemon, to be specific). That's a bummer for us, because it means the sector load increases as it has to handle more complex physics math, making the overall system more of a burden on the server and less scalable.
Eventually, that means as we roll out the new feature across the game, it could increase our server utilization overall, and make the game more difficult and expensive to operate (but, I'm pretty confident we can optimize things and find a happy medium of usage that is a good balance).
It also means that you don't see physical reactions until you get reaction packets from the server. So, you fire a rocket, it takes 250ms to reach the server, which says "hey, your rocket hit this debris and now it's spinning around", which then takes another 250ms to come back to you. Best case, you get to see something happened about 1/4 of a second after you would expect.. which is noticeable. In some cases, like ramming something with your ship, it could be even longer (in the case of the rocket, the in-game flight time may effectively absorb some of the latency).
There may eventually be some kind of happy-medium we can bolt into the system to improve the perceptible lag, where basically both the client and the server do the simulation: the client sending the action and timestamp, and the server receiving the packet and "stepping back in time" to insert the action at the right point, and then re-playing it forward to present. It doesn't resolve the delay for other players, who will still have to deal with some weirdness, but it would improve things for the individual taking the initial action.
Of course, it could also be solved in other ways, like long ago I had the notion of doing distributed sectors, globally, that would fire up as "local" as possible for the first individual to fly into a specific location. So, at 4am (Milwaukee time) you might find a lot of the game running in Australia or Singapore, and at 5pm it would probably be back on the Eastern US, etc. The locality of the sector would help resolve the latency difference. But, of course there are other problems with long-lived, popular sectors, and then the fact that hosting in Asia is really expensive, and so on.
Anyway, TL;DR - No, there isn't anything I can do right now. It'll just have to look weird. But, it's kinda neat, despite looking weird, right?
Thanks for the detailed response Inc :)
Yeah, it's not a concern for me, I mentioned it only as it was topical, and I was curious about whether future enhancements would help. I barely notice it elsewhere, it's just more obvious when it affects a stationary object surrounded by lots of other stationary objects, as opposed to a ship that is already moving erratically. I assumed it was ping-related, but it's nice to have confirmation :)
Yeah, it's not a concern for me, I mentioned it only as it was topical, and I was curious about whether future enhancements would help. I barely notice it elsewhere, it's just more obvious when it affects a stationary object surrounded by lots of other stationary objects, as opposed to a ship that is already moving erratically. I assumed it was ping-related, but it's nice to have confirmation :)
Very interesting response inc.