Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

2D Physics client side prediction

Discussion in 'Multiplayer' started by Dodreamer, Jul 19, 2016.

  1. Dodreamer

    Dodreamer

    Joined:
    Aug 31, 2015
    Posts:
    4
    Hi,

    We have a fast-paced, 2D physics based game with a lot of collisions. As we are testing whether it is possible to implement a real-time online multiplayer mode, we need to implement advanced client side prediction.

    As far as we know the framework does not expose the underlying physics so that we could rewind and recalculate physics steps to correct transformations of game objects. Is this correct?

    If this is the case, we would greatly appreciate any insight how developers usually approach this problem.
     
  2. YinXiaozhou

    YinXiaozhou

    Joined:
    Oct 19, 2013
    Posts:
    133
    We also encountered this problem when we made a 2d platformer on Unity 3-4.
    I'm surprised that they still didn't addressed that. Because this is the essential for any multiplay 3D shooter.

    What we did in our game is using box2d's csharp version, and forget the buildin physics engine.(They don't have 2d physics in Unity 3.)
     
  3. thegreatzebadiah

    thegreatzebadiah

    Joined:
    Nov 22, 2012
    Posts:
    836
    Yeah ran into this problem as well when trying to perfect our networking. AFAIK there's no way around it, you just can't do true client side prediction in Unity. In our case that turned out to be more or less ok because our game doesn't really require that level of accuracy, but if you really need it you may have to look into some other engine.

    I'm really hoping I'm wrong though and someone will step in and correct me.
     
  4. Iron-Warrior

    Iron-Warrior

    Joined:
    Nov 3, 2009
    Posts:
    838
    The way I approached this problem was to switch to Unreal for my project.

    ...but before I did that, I wrote a prototype that implemented client-side prediction and reconciliation. You're right that Unity does not expose enough of the Physics engine to do this natively, so I wrote a custom character controller that would be able to be updated multiple times per frame. So it's definitely possible, and as 2D collision is far easier than 3D it shouldn't be overly complex. Like @YinXiaozhou said, using the Box2D lib would be a good idea (I think Unity already uses Box2D for it's 2D stuff right now).
     
  5. Dodreamer

    Dodreamer

    Joined:
    Aug 31, 2015
    Posts:
    4
    Thank you for your replies.

    Unfortunately changing Unity to another engine is not a viable option to us, so we'll have to manage with what we've got. Hopefully there exists a usable solution for us where we don't have to replace Unity's box2d wrap with our own.
     
  6. Dave-Hampson

    Dave-Hampson

    Unity Technologies

    Joined:
    Jan 2, 2014
    Posts:
    150
    > we need to implement advanced client side prediction.

    I guess it depends what you mean by advanced client-side prediction.

    I asked the Unity Networking team and here's what they said: "As far as i remember we have this feature in to do list. But i cannot say anything about ETA".

    I should hopefully have a bit more information on 4th August when the programmer who knows a bit more about this is back from vacation.

    For the current version of Unity, it seems that if you are looking (as it sounds like) to capture the current state and then project forward with the current local input, this may well be beyond the current feature set of Unity's 2D physics. In that case. as you guessed, wrapping Box2D directly might be the only remaining option. But of course it depends on how physically accurate you want the client-side prediction to be: perhaps a simple rigidbody integration might not be so hard to implement manually, and as long as the prediction times are short, not too different from the 'real' Box2D.

    Or how about this as an idea: run two physics scenes, one next to the other. One would represent the 'real' network synchronised state, and the other a forward projected version of the network synchronised state with local input (copied from the synchronised state). You'd still have to integrate rigid bodies manually of course, but maybe you could leverage the collision resolution of Box2D/Physics2D.