Since milestone 2 I have been working hard with client-side prediction and trying to figure out some way to make it work. There was one thing that was bothering me and didn’t make sense, with a lot of lag the spheres could “predict” themselves through the ground quite a bit. Now getting through the ground wasn’t the problem, with my simple rewind and fast forward that had no collision detection I knew this could happen, but they got way to far ahead. The gravity was way too strong, but the value for it was right so what was actually wrong? I tried to remove it all together and I still had issues with the clients being way off the server, so I started going through the rewind and replay step by step. Sure enough there was something quite wrong with it, when replaying I didn’t update the time properly which lead to the time delta being calculated as the time difference between the current state and the first state. Obviously it shall be between the current and previous state. I spent some more time to find errors and polishing things up before going to the next step which was adding it to the actual game.
As some would say, “Shit’s about to get real”
Previously I had discovered that forces or impulses don’t have an immediate effect on the rigidbody’s velocity in Unity, this meant I had to rework our vehicle model to work directly on the velocity vector. This was already done and we had game tested the new model and everything so that was all good. After thinking through a good deal about how I should plug everything in and then actually doing it, I pressed play to see what would happen. I don’t recall exactly what the editor said but it had something to do with a recommendation not to use absurdly high floating point values for things like position, the play screen gave me a nice picture of the sky box.
What was wrong? Previously the server moved the player to the correct spawn point and updated the client about the new state, all very simple. With client-side prediction these sort of forced positioning could be done through an RPC, or you are somewhat oblivious to the situation and are counting on large disagreements between client and server are sorted out by snapping the player to the correct position per normal client-side prediction. The first is probably for the better, but as you might guess I was doing the latter. The snapping SHOULD have worked, unless there was something wrong with it. At the moment I’m not sure if the issue was in the snapping code or if it was another thing I fixed later. You see in my test environment everything was local so I was using the regular time which worked well, when I moved things over to the game and to a network environment I kinda forgot to switch to the synchronized network time that is available. It would have worked if everybody started their game at the same time but that might be to much to ask. I found another great issue where I turned the vehicle etc through the transforms rotation but saved away the rigidbody’s rotation, these are synchronized at set times, this caused some nice issues when rewinding and replaying.
With these issues and bunch of other stuff out of the way it started to actually work, the clients moved on their own and did corrections with updates. At the moment, things are actually looking quite nice. The biggest issue right now actually is that all the others players are so far behind since they interpolate to the latest received state. This means that they can and will hit you before you even see them 😛
There is a lot left to do though, for the current version I store the player input and physics state and used these for rewinding and replaying. The internal state of the vehicle is also necessary and I’m also thinking of storing any alterations in velocity caused by the physics simulation. Then there is the whole business of extrapolating the other players behaviour, that should be quite fun.
All in all, things are looking quite good and I’m in quite the better mood regarding the whole situation than I was for milestone 2. Turns out some things are easier to predict than others.