Modeling speed of light information propagation in space combat sim

Question

I'm working on a space combat sim that takes place over relatively vast areas (a cube of space ~20 light minutes to a side) and uses (mostly) realistic physics. One of the key elements I want to model is the propagation speed of information across the battle space -- that is, if Player A engages his main drive on one side of the battle space, there's a 20 minute delay before Player B sees it and can react to it

Even for relatively small battle spaces this is an important factor given the speeds involved. A 500m long ship doing 30kps is going to displace itself by its full length in 1/60th of a second, so even targeting an opponent just few tenths of a light second away are going to be affected by light lag.

I've not seen this done before, and I'm wondering if there are some best practices for modeling this. Right now I'm timestamping each event and marking it with a location, putting it into a queue, and then each tick checking to see if any of the objects in the game world are newly at the edge of the light cone and adding the event to their sensor queue. I will (but haven't yet) optimize it by removing any events that have already been sensed by all the objects that can possibly sense it, but still, I think this is going to get cumbersome pretty darn fast, and eat up a lot of cycles if there are hundreds of sensing objects in play (which is pretty routine).

Are there data models which would be better suited for this that I should check out?

Answer 1

Just brainstorming here...

Interestingly enough, network lag is your friend in this case. As in you WANT a delay to occur for some data packets, at least if it's about drawing. But instead of a base lag each player would normally have for all data packets impacted by just their network speed, you need to apply specific lag for each event to each player based on the light-speed delay.

Typically the server would send out updates to all clients at the same time, but what you need is for the server to calculate the "light lag" for each event (based on distance of viewer), and then not send out an update until that time.

So for every event, calculate time delay between event and each player, then queue up that event to not be sent for drawing to that player until the delay time has passed.

This doesn't address the effect of the player changing position or speed after the event occurs, but you could potentially adjust events that had been queued based on player changes. A player begins to move closer, move event closer in time. Player moves away, move away in time.

Doppler shift would be an interesting thing to throw into the mix, based on the movement delta between viewer and event.

Answer 2

The question is: how exact do you need your delayed image to be to how it actually played out? If you're looking for 100% accuracy you're going to need to save either the actions or the state of every object on the map at each tick and, as you say, replay them on a delay based on distance. If you don't care that much about pinpoint accuracy, which you rarely need in games, you can save the state at intervals and extrapolate between them when the delay catches up. You can optimize by not saving identical updates.

Alternatively, you can vectorize all movement and save a path for each object along with a start time seen from a universal observer. Then you can just calculate the expected position of an object for each observer based on the universal time counter the local time based on the path nodes it has saved. When a path node's timestamp goes behind the lightcone of all relevant objects you discard it.

Edit: The above assumes you're going to cheat on basic relativity by having an absolute observer (I assume the player). This would rob you of some of the more Interesting aspects of time dilation but modelling those would be a project in itself >_>