Is it possible to allow players to join and leave TrueSync scenes dynamically?

Hi everyone,

My use case is to have a persistent level, part of a persistent real-time world, that players can enter and leave at any point, but while they're there, their player objects, level data etc.. must be in lockstep.

I followed the moving cube with projectile tutorial and adapted it to be one scene. Instead of loading the new game scene with all players present I activate the TrueSyncManager when there is more than one player present to avoid offline mode.
It works fine for one player. The problem with this is that new players joining trigger an index out of range error or an unhandled event Event 196 warning. I'm guessing I'm missing something important here!

So my question is, is this possible with TrueSync? And if so, how can I adapt this basic situation to make it work?

I've investigated a bit access to AbstactLockstep.AddPlayer and it seems it's only used on start up, so I'm guessing there's no support for this kind of use case...

Thank you in advance!
Loren

Answers

  • I believe you are correct as I have searched around online to discover that all players must enter the game session before the lockstep simulation begins. I, too, would like to be able to insert and remove players from a running simulation, but TrueSync does not appear to be readily setup to do this. It does seem possible to find a workaround for this; however, probably by modifying the code base.

    If you haven't already found this thread, it verifies my findings: forum.photonengine.com/discussion/9148/players-cant-join-later
  • Hello @Loren and thanks @ScriptGeek for clarifying. TrueSync doesn't support later join as we move each step of the simulation based on all players's inputs connected, it is a little bit complex to allow a player being added at the middle of game and keep it synced with other players state without disturb those players gameplay.
  • It's complex but it's totally do-able, in Factorio (a lockstep game), a player will join but the client will wait until it has the whole state and a buffer of inputs before starting interaction. This would work with a rollback window system too, as once you have enough local history stored, the new starting player can use rollback correctly. I used the same solution years ago for my own deterministic rollback multiplayer game several years ago.
  • Sure @Dunk, it is pretty possible but as I said it will disturb other players gameplay because we still need to improve our physics simulation execution. A long wait to enter the game and sync the state with other players is not what we want, we have solutions in mind to keep this very fast, but we need to do some needed steps first.