# How would a simulation take into account relativistic effects (i.e. several clock tick rates)?

Please note the following question may perhaps fit as well in another stackexchange but physics. So, suppose a game in which relativistic effects are taken into account seriously. Now, I've been thinking about such a game, but always stumbled upon the same problem: in regular game simulations, there's a universal clock and everybody compares motion and events to this universal clock. But the moment you want to take these effects into account, how would you do it? Would it work to have a universal clock to which everybody else compares their own clock, or there's no option but to have everybody's clock compared to everybody else's clock? I can't imagine how such a game or simulation engine would take account of time, thing that is just trivial in non relativistic situations. Is it even possible to compute such a game without knowing beforehand everything that is going to happen? Does this have any deterministic implications regarding our own Universe, given it is computable? Thanks in advance

• Can you keep track of bullets? Then you can keep track of propagating events. Feb 11 '18 at 1:04
• @probably_someone I don't follow you : / Feb 11 '18 at 1:19
• Keeping track of everyone's time is as simple as giving every player a light-clock, which you can make out of a bullet bouncing back and forth between two surfaces at the speed of light. Then you sit at some inertial birds-eye view and count the bullet's reflections as ticks of the clock for each player. Also, whenever something changes on the field of play, information about that change propagates outward at the speed of light (which you can also model by shooting a virtual speed-of-light "event bullet" between the event and the viewer). Feb 11 '18 at 1:43
• Basically, as long as you can keep track of a bunch of speed-of-light bullets at once, then you're fine. Feb 11 '18 at 1:45
• A Slower Speed of Light manages it by being a single-player game, which is probably not what you are interested in, but it does take relativity seriously. Feb 11 '18 at 1:55

I think the main question you have to consider is: "is this a multiplayer game?" if no then it could be implemented like a non-relativistic game by keeping the game state at the edge of the past light cone. Then you would just make your update step depend on the velocity and relative position of the player. If you had some weird geometry (e.g. wormholes) then you would need to think a little bit more but should be able to follow the same procedure (as anything that was in the past, stays in the past when changing velocities).

For multiplayer games it is a bit trickier, however if you can guarantee that the players are never in each other's futures or pasts then you can do the same procedure. By this I mean keep the game state to describe the surface of the past light cones but only if they aren't in the past of another player. Everything should be consistent and there would be no causality violation (but you would have to program things carefully). Though I also realise you will also need to store the state of the game in the past where it could be observed by one of the players (which might be memory intensive).

If you want to allow players to go into each other's light cones then you are going to have to give up causality as the players will have agency. You could possibly get around it by using time waves like in achron to update the information for the player in the future. This could disrupt immersion as when the time wave hits the future player things could suddenly change and they have no way around it. It might be possible to get around this by using machine learning algorithms to predict player's moves to reduce the disturbance by the time waves. But unless the game is highly non-interactive between players I would advise against trying it (you would also open your game up to grifters who want to screw around with players who currently exist in the future).

• Thanks for the answer. Yeah my point was an online multiplayer game. Either immersion is broken or causality is broken, I guess... I will give it a second thought. Can you elaborate more on time wave updates? Feb 11 '18 at 10:50

If it's a multiplayer game and you want

1. for players to be able to interact at multiple different times, and also
2. for the game clock as presented to players to be a faithful reproduction of the character's proper time, without interruptions or artificial slow-downs,

then this is impossible. The reason is that you can encode a version of the Twins Paradox into the game, by having one player stay still and then have another player dash out and then back at a high speed: when the second player returns to their starting point, they will want to know the game state of the first player's character, but that first player will still have to clock through a nonzero (and potentially significant) length of time before that game state can be determined.

Now, you could set a master clock in some canonical reference frame and display that on players' screens; that enables you to speed up the characters' response times as their velocity increases and their clocks get dilated (so they have more time to do things) but you won't be able to implement point (2) in that framework.