# Would slo mo work for multiplayer?

I have hardly any programming knowledge but I want to get into game design but I have a question would slo mo work in multiplayer if used in this way. Where the player experience the game 10 times slower and everyone else saw him going 10 times faster would that work or is it just not possible.

• You may be interested in this recent Q&A on time dilation mechanics in multiplayer. Imagine we start the slow-mo at t=0s while the fast player is running forward. At t=10s, the fast player decides to turn left. The trouble is, for the players seeing that player move 10x faster, that decision should have happened at t=1s, or nine seconds in the past. So to draw the right thing on those players' screens, we either need to read the fast player's mind and predict the choices they'll make in the future, or correct some very large mispredictions. Sep 10, 2023 at 20:42
• Sep 13, 2023 at 11:37

As per your description, you want a player to see the other moving faster than normal. You can do that, that is an speed boost. But the other player won't see everything going slower. That won't work.

In this answer I try to reiterate some things a couple times to try to avoid misunderstanding.

To wrap our heads around this, I invite you to think of two kind of clocks:

• There is a world clock, which will be the clock for the player in the real world. I'll assume it is the same for all players, as that is sufficient to understand the case at hand.
• And there are game clocks, each with the the current time in the game world, for a player. These are multiple, because time passes differently for different players.

Now, for your setup we would have that:

• For Player A 1 minute in world clock is 1 minute in game clock.
• For Player B 1 minute in world clock is 6 seconds (i.e. 0.1 minutes) in game clock

The logic below also works if you have one player with a game clock going faster than the world clock (experiencing the game faster than normal), and the other have normal time. However, I'm doing it this way because you want one player to see the game slower.

Here, Player B sees everything going slower (including Player A, for which there must be a recording of what Player A did so it can be played back slower for Player B). To reiterate: Player B would have to see what Player A did in the past. This is viable, given a recording of what Player A did and plays it back for Player B.

But Player A could not see Player B... Why? Well, what would Player A see Player B doing, if Player B has not done it yet? - The game won't be able to show to Player A what Player B is doing... Because Player B has not done it yet!

• For Player A, 1 minute in game clock is 1 minute in world clock.
• For Player B, 1 minute in game clock is 10 minutes in world clock.

Thus Player A, 1 minute into the game, would have to see what Player B will be doing 9 minutes in the future. But the game has no way to know what will Player B do.

I suppose you could try to have the game predict what Player B would do, but that is bound to be wrong. Instead I would suggest you can come up with some narrative justification for why the player can't be seen.

Now, let us think about these players interacting:

• If Player A attacks Player B... Remember that Player B has not reached Player A's present game time. Instead Player A attack would be recorded and played back slower for Player B. At which point perhaps the attack might land, in which case Player B takes damage.

• If Player B attacks Player A, it would be attacking the past of Player A.

I'll assume that we make it impossible to push around the recording of Player A. If we let it happen, and correct for it, the result will be teleporting Player A on their present without an apparent reason why, which is not a good player experience.

However, you might do something with damage, have it play some animation, or something. But think about it for the point of view Player A... If Player B kills the recording Player A, then the first idea would be to have Player A suddenly die wherever it is at their present, which again is not good player experience.

Thus, it seems to me that interaction is either not viable, or a very bad experience for the players. And the mechanic is basically recording a ghost of the players that are experiencing game time faster.

If the effect is temporary we find both problems and solutions.

For example both players start playing with matching game clocks, but then one of the players speeds up their own game clock (or slows down the game clock of everything else, same difference)… But only for a while.

After that effect is over, then what? Logic suggest that the players that were experiencing game time faster would have to be held idle until the rest of the players catch up to their present. That is not good, it is boring gameplay.

Another option is to switch roles: those experiencing game time faster start experiencing it slower, and viceversa... Until their game time matches.

A more interesting solution is allow the players that were experiencing game time faster to appear at the present of the other players right away. You can conceptualize this as their characters traveling to the past. This means that the other players would have to deal with both the recorded ghosts and the actual players at same time.

This sounds like a boon for the players experiencing game time faster, and not the other way around. It would be like this: The player activates the ability, which makes the game both start recording what the player does (during which time the player cannot see other players) and playing it back slower for the other players... And after a while, the game stops recording and drops the player back in with both the other players (co-existing with the slowed down playback). Thus, if you want the playback to look as if it is moving at normal speed, the player would have to move much faster during the recording.

This also poses a few solutions for what happens if ghost takes damage:

• You can redirect damage from the ghost to the player in real time. This means that attacking the ghost is a viable way to harm the player.
• Or you might have the ability cost health, which will also be the health that the ghost will have. Then if the ghost finishes, you can have the game replenish the health the ghost had left to the player. On the other hand, if the ghost dies, it does not affect the player. In my opinion, this is the best version of this mechanic.

Furthermore, this approach allows versions of the mechanic where a bot handle what the ghost does if - for example - something knocks it out diverging from the recording, or if you want the ghost to stick around after the recording finished.

But no player is seeing everything going slow.

If we say that interaction is not possible, then you could have a player play in slow motion, and have it recorded... With anticipation. Then the other player can see the playback of what this player did, moving faster.

With anticipation is key here. Since the recording cannot be played back at meanwhile it is being recorded but faster. There is no way to play it back faster than it is being recorded, while it is being recorded... Because it would have to playback what has not been recorded yet!

Of course, the player doing this recording cannot see what the regular player will do, since the recording has to be done with anticipation, meaning that at the time of recording the other players have not played their corresponding part yet.

I don't think this is a great experience either. What you have is a ghost of a player doing a solo gameplay. But hey, you have a player seeing everything in the game going slower (except the other players, who this player does not see at all), and then everybody else sees said player going faster.

As others have stated it's not possible to have different timeframes for different players, because at some point you need to be able able to send information back in time. That said you may be able to do something interesting if you can incorporate the real world flaw (of not being able to travel backwards in time) into the games cannon in some way.

For example the multiplayer mod for KSP (Kerbal Space Program) allows multiple players to start in the same timeframe. This doesn't cause an issue since updates can be sent in (near) real time between the players as they each take actions.

Then a player can accelerate time - in single player this just calculates how every ship in the universe will move (at a faster rate).

For the player that accelerates time, they see the same thing they would in single player all the updates are calculated based on the moment they "jumped". For all the other players the ship that the "jumper" was controlling effectively becomes unmanned - it just continues to orbit with no new actions taking effect.

Effectively there are now two games going on. The one in the "present" and the one in the "future" - each has its own state which are disconnected from each other.

KSP allows any players "in the past" to jump forward in order to "sync up" with a player in the future. When this occurs there are several possible situations:

• A ship exists that wasn't controlled/interacted with by either player - in this case the future prediction should be the same in both timelines so it shouldn't be a problem.
• A ship was only controlled by the first "jumper" in that case when the second player syncs up the second player now see the new position - this isn't a problem since they see the new position as they jump forward in time.
• A ship was only controlled by the second "jumper" - this is a little jarring because the first "jumper" will see the ship change state/position when the second player jumps into their timeline.
• If a ship is controlled by both players it will be a problem as one could have destroyed the ship and the other moved it - in short there is a conflict.

KSP "resolves" this conflict by cloning said ship so both players now both see a ship in the "moved" position and wreckage where the ship was crashed.

Taking this idea to its logical conclusion....

You can record any actions taken by a future player and play them back when a later player gets to the same point.

For actions taken in the "present" state you could calculate the impact on a future game and apply them to those players games.

However at some point there will be at least two problems:

• In the future games changes may occur with no context (an item just disappears because it was moved in the past).
• There will inevitably be conflicts - the future player stood on a block to reach a ledge then the block was deleted by the earlier player.

You may be able to get around these issues by using a movie trope such as "you are protected from SPECIFIC past changes by the time vortex"...

Where the specific protections are anything you can't easily code around.

However I am not sure the work to do this is worth it - unless you can come up with a really cool way to incorporate it into the core of your game.

Its a relatvie question so lets break it down this way.

Your question suggest that Because player A is relatively faster, it sees everything slower. Because player B,C,D is relatively slower, it sees player A faster.

Uhh yes. it can simply done by making player A have faster input and player B,C,D have slower input.

But such design is often called "latency" or "lagging" if not set with a theme.

But if you meant all of them A,B,C,D sees the game as normal speed and it magically is different in speed at third party perspective.

No, its impossible unless physically we can bends time.

Where the player experience the game 10 times slower and everyone else saw him going 10 times faster would that work or is it just not possible.

Let's say this is a racing game. Solution is simple, have player A drive a Ferrari and have players B,C,D drive old VW Beetles.

Problems arise if/when you want to have interactions with the World - it needs a clock to run by too (in a certain light, it can be thought of Player E). And now you need to choose that clock, will it be suited for Ferrari's speed, or to Beetle's speed. Still, not impossible if you slightly bend the "experience the game X times slower" condition :-)