BetterCharacterControl sync between server and client

Hello, I was wondering what the best way to sync the physics between the server and the client when using BetterCharacterControl. At the moment, I am sending the location and view/walk directions. I am using warp on the Node to move the player on the client. But this is very choppy and I know there must be a better way but I have not look into it that much. What have others done? Is there a proper way to do this?

Thank you,

You should always interpolate between the received vectors for look and position, because the network is not continuous. So if one packet comes in that says the player is now at (1, 0, 0), you should not instantly move the player to that position. Instead, smoothly interpolate the value using vector3f.interpolateover the course of about 200ms (tweak that number to your liking based on your own tests).

Thanks, yeah that is a really good idea.
So do I have the correct general idea then?
It still just seems clunky, but I guess it works fine in game.
I just figured that someone would have come up with a better way of synchronizing the BetterCharacterControl.

Yes, this is the way many games handle it. You can’t have a steady stream of position updates every frame because networking just doesn’t work like that.

The question is way broader than this. First, personal advice, don’t interpolate the eye direction, let the player decide it (and the server will have to accept it, with maybe a check on the rotating speed). Otherwise, you’ll have motion sickness.
For movement you can use interpolation, but:
1 - You already have a latency between client and server. So, if you add to this a interpolation, you add a latency between the time the client know an information and the time a client display it.
2 - If you do linear interpolation, the client will be able to go (with its camera) through walls for very acute angles.
3 - A solution to 1 is to add extrapolation client-side.
4 - if 3 is a linear extrapolation, it makes problem 2 worse (the player will be able to go through every wall, provided he walks fast enough).
5 - if 3 is a physical extrapolation, then you need to have a physic engine client-side that supports rollback and fastforward. Tip: bullet engine doesn’t support that.

(you need rollback because if your extrapolation of the movement of a ball makes it hit a brickwall and destroy it and the the server say “nope, the ball never touched the wall”, you need to “rebuild” your wall … and re-place objets hit by bricks, and re-place objects hit by objects hit by bricks and restore forces and … and then calculate in fastforward what happened since that time where you made this wrong decision, with the correct result you have now, and all of this in a very short interval etc)

The problem in 5 is a way bigger problem, it’s an “arrow” problem. The root of the problem is that most programs have differents part and each parts is subordinated to an other, at most. In most non-network games, the game logic is subordinated to the game physic, i.e. it have to accept what the physic engine say, you design it with that in mind. In a network game, the client is subordinated to the server. If you add a physic engine client side, the physic engine is no longer the “big boss” and have to accept orders from the network. A part of this subordination is rollback.
Alas, most game engine are not designed with this in mind, as developpers are too much focused on implementing a good engine with a lot of optimizations and tricks everywhere to think further than that.

And the nice thing is (but it’s personnal): i made a new physic model (theory) to explain the gravity, based on this. The latency between the server and the client exists between particles, as the speed of light is not instant. There is always a latency, even in real world. So, there is always actions performed by particles locally that may be illegal because they “thought” the universe was in a way and they was wrong. It’s fascinating.

1 Like

Obligatory reading:


I found this link really helpful too:

1 Like

They even link my second link at the end. Heheh.

One thing to note is that the scenario they describe “I hit the key and the thing didn’t move for 1/10th of a second” is most noticeable when movement would be instant as in their scenario at that point in the paper.

For physics based games, there is always a bit of lag anyway as the momentum of the physical object has to be overcome. So in the best case scenario, 100 ms won’t be noticed too much but in the worst, you have the time the event happened and can potentially back-rev the physics a little on the server to compensate.

I started skimming the article by that point so maybe they mentioned it.