-->

main-navbar

Friday, February 28, 2014

Physics Multiplayer

Its been a while since I posted anything here, been very busy, both in college and working on this project. While I have been working on the project quite a bit, I haven't updated this blog much. Much has been changed, its practically a playable demo at this point.

Multiplayer, has been the most recent feature I have been trying to implement. Adding multiplayer to a game like this is very challenging for several reasons:
  1. This game is physics based.
  2. It has to be as lag free as possible for direct user feedback
That's it. 

Only problem is, those two things generally don't go together, especially when using unitys physics, here is why:

In most multiplayer games, you have a server and a client, the server runs the official version of the game, and the client runs a similar version that the server updates to be in sync with the server. Even with a very good internet connection, the delay between sending information to a server and receiving the resulting update of the simulation can range from .2-.4 seconds. Say if you press the space key to jump, the signal is sent from your computer to the server in .1-.2 seconds. The server receives the signal, tells your player to jump, then sends the updated position back to the client. So it takes .2-.4 seconds for your command to appear on the clients display.

To fix this delay, client side prediction can be used, how this works, is your player moves  immediately after receiving a command, and sends the command to the server. The server then sends its results back to the player. However, this data from the server cannot be used to update the player, its .2-.4 seconds old. The server is constantly sending out its idea of where the player should be. So if this old data is used to correct the players position, then client side prediction will be pretty much invalidated.
To Compensate for this, the data the server sends can be "checked" with what the players position was in the past. If the two don't match closely enough, then an extrapolation is made of where the player would be assuming the two did match. The player is then moved there.
The server also has to update the other players, since each of them also has a simulation of the world. The flowchart above shows roughly how this would work.

One of the problems with client side prediction though, is you need to predict something based off of old information. With unitys physics, you cannot do this. Unitys physics cannot "rewind" or "resimulate" nor "predict" any part of the physics system. That why making a physics multiplayer is very challenging, especially when using unity.

To get around this problem, you could simulate some data yourself, you would have to have your own simple physics engine essentially. What my project will do, is use a custom rigidbody system that supports "predicting" where it will be in the future. Unfortunately, it will not be possible to check collisions, so those will have to be handled server side, which will likely result in lag glitches during a collision.

This being a space ship game though, there should be few enough collisions that this should not be a problem.