User Tools

Site Tools


Time Bubbles


How do we allow time compression to occur at different rates for different players in a multiplayer game and still allow them to interact?


At t=0,

  • Player A is driving a vehicle. Time is compressed to 1 second = 1 game-minute.
  • Player B stops to sleep. Time is compressed to 1 second = 15 game-minutes.
  • Player C dismounts and goes on an adventure. Time is decompressed to 1 second = 1 game-second.

At t=300 real seconds later (five minutes),

  • The time for Player A is +300 game-minutes, or +5 game-hours.
  • After resting 8 game-hours (32s) and driving for 268s, the time for Player B is +13 game-hours and 24 game-minutes.
  • The time for Player C is +0 game-hours and 5 game-minutes.

Implementation: Time Bubbles

A Time Bubble matches a player's location to a relative time specific to that player. When Time Bubbles collide in space, the relative times are checked.

  • If the times are too far apart, the players do not see each other.
  • (maybe) Game-time advances at the rate of the slowest of the colliding bubbles.


Design goal: Players who spend enough real time together will exit each others' time bubbles at the exact same game-time.

Implementation: When players interact, the rate of time compression is adjusted for both players relative to the times of their time bubbles. The player who is behind in time advances through game-time slightly faster than the normal time compression rate for the mode of game play. The player who is ahead in time advances at a slightly slower rate. This continues until their game times equalize.

Example: Player A is at +10 hours. Player B is at +2 hours. They meet and spend an amount of time together that would normally be worth 1 hour of game time. Player A's clock advances by one half-hour. Player B's clock advances by 2 hours.

Obvious bugs


At real time t=300, Player B, with a false-time of +13 hours, may steal an object or talk to an NPC.

At real time t=400, Player C, with a false-time of +1 hours, should be able to interact with the same object and NPC because Player B has not yet interacted with these objects in the game's timeline. Player C should be able to steal the same object or kill the same NPC. This creates a paradox and an item duplication bug that users would line up to exploit in any massively multiplayer game.

Possible resolution 1: Everything other than the player is in game-time. If the item was moved at real time t=300s, it is no longer available to Player C even if Player C's game-time is earlier.

Possible resolution 2: Give every item a list of times and locations that a player has interacted with it in any significant way. The item becomes immutable until that event occurs, either by directly denying players the ability to interact with it or through the game engine contriving some reason: The item is not for sale, the NPC survives being set on fire, a legion of guards show up to force you away, etc.

Consider a more serious version of this paradox:

  • Player B at game time +13h goes to a store and buys an item.
  • Player C at game time +1h goes to that location and waits until Player C's game time is equal to that of the game time when Player B bought the item. Player C should see Player B's avatar appear and make the transaction.

What if Player C wishes to interact with Player B? Player B is far away by now. Hours may have passed in real time.

What if Player C locks the door and burns down the store with Player B's avatar inside?

Hello Neighbour

Players with different enough times should not see each other. Imagine that this limit is 24 game-hours.

  • Player A has a game time of +0 game-hours.
  • Player B has a game time of +30 game-hours.
  • Player C has a game time of +15 game-hours.

Player A and Player B are in the same area. Since their game times are far enough apart, they are invisible to each other and cannot interact.

Player C's game-time is close enough to see both Player A and Player B. What should happen when Player C pops into the same area?

Possible resolution 1: Chain the bubbles. Anyone close enough to any bubble in the chain can see any player in the chain. This has the unwanted result that Players A and B will suddenly see each other appear next to each other when there was nobody else in the area before. Or they may appear on top of one another and collide.

Possible resolution 2: Don't chain the bubbles. This has another unwanted result. Imagine that Player B attacks Player C. Player A will see Player C's vehicle taking damage but will not see any attacker or source of the damage.

Slow Ride Paradox

  • Consider the proposed rule that game time advances at the rate of the slowest player in a time bubble.
  • Consider that players in the normal mode of operation continue to move at the same rate relative to real time in game space.
  • Consider that some part of the the game gives an advantage to players who maintain the lowest game-time. This could be winning a race, delivering materials within a given time, or racing to interrupt another player's action.

There is an exploitable side effect in which a string of several players can position themselves in a row of colliding time bubbles and the player in the lead can enter a mode where game-time moves slowly. Other players can use this ladder to rapidly move through space while minimizing the change in game-time.

Possible resolution 1: Make the game universe so large relative to the size of time bubbles that the advantage gained from this exploit is insignificant.

Possible resolution 2: Force all players entering a slower time bubble to enter the slower mode of operation. Your spaceship on autopilot falls out of autopilot until you are clear of the other ships. Your disembark from your dune buggy when you see another driver on foot until you are done interacting with the other driver and the game allows you to leave. A game may allow players to meet some gameplay condition that allows them to reenter the faster mode of operation, from which point they leave the slower player(s) behind in game-time.

time_bubbles.txt ยท Last modified: 2015/07/12 02:16 by deltatango