Search Unity

2 Player Platformer isn't keeping in sync on client side

Discussion in 'Multiplayer' started by Jay1001, Apr 21, 2019.

  1. Jay1001

    Jay1001

    Joined:
    Mar 16, 2019
    Posts:
    1
    So I'm currently using the Mirror package (which is an extension of the now deprecated Unity multiplayer code) to setup a simple 2D platformer. Right now players can run around and jump on platforms. The network code works but the characters aren't fully keeping in sync.

    Playing as a server is fine. The characters mostly keep in sync. But from the client side things aren't really keeping in sync. I think it's because of how I implemented jumping. So when you press the jump button your character jumps, and the longer you hold jump the higher he will jump. When you release jump, your character will begin to fall. I think what's happening is on the client side it can't send updates to sever fast enough and so the server detects a jump has happened but at some point during the jump it doesn't get an update from the client and thinks the jump has stopped and hence the player begins to fall but on the client's side the character is still jumping.

    Now I know maybe I could tweak my jump code to fix this but I think it's a sign of a bigger problem, which is that the server is missing occasional inputs from clients and that can cause all kinds of other problems in a game like a platformer. Minor missed inputs can make players miss jumps or collide with enemies they don't collide with etc.

    I have my network manger setup with a 60 tick rate (which I presume means 60 fps). Is there any way I can fix these problems? Or is this a far more difficult task, requiring custom network coding?
     
  2. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    You have to design networked games to tolerate data to and from clients to come in at an inconsistent rate, and you will not get data every single frame. Also, Mirror's default transport is TCP based, and TCP is not ideal for games requiring small high frequency updates.
     
  3. thegreatzebadiah

    thegreatzebadiah

    Joined:
    Nov 22, 2012
    Posts:
    836
    You've basically got two choices here: Server authoritative vs owner authority.

    In the first case the server would own everything that actually moves. The clients would only own a single object that they use to send commands to the server. If you're using Mirror's default transport or any transport with a reliable channel then these commands are guaranteed to be delivered. The server then uses the commands to update the actual character object that everyone sees moving around. This method can be a bit tricky to implement though, because clients will not see their characters react to commands until the server receives the command and reacts to it by moving the character and syncing that movement out to clients. Usually you cover up the delay with client side prediction and other nasty tricks.

    In the second case, clients actually have authority over their characters and can physically move them and have the movement replicated to everyone else. This case is a bit simpler to set up, and especially easier to get the controls feeling responsive locally. It has a major drawback though in that it is easier for players to cheat.

    It's hard to tell what method you're going for from your description, but you probably want to send Start Jump and Stop Jump commands instead of continuously sending the jump command.

    Whatever method you go with, you're definitely going to want to use something like the built in NetworkTransform to sync the transform from the server to non-owners. Personally I recommend my Smooth Sync asset as it performs better and has a ton more options than the built in NetworkTransform.

    In the second case described above you would also sync the transform from the owner to the server and you'd be done. No need to worry about sending jump commands or anything, just do the jump locally and everything is synced.
     
    Joe-Censored likes this.