Hello.
I ll be short on it.
1. I am running an authoritative mp model.
2. The loop works like this - client generates inputs using an inputManager class ,now ,based on the inputs it moves the player ,then , it will RPC the server with the inputs and a moveID,and finally saves its own state for later rewinding and replaying.
3.Server does movements as soon as it gets inputs from player.
4. I use character controller (unity engine )for colission detection.
5. Everything runs in a fixed time step using fixed update set at a 25 fps rate.
THE PROBLEM
Everything works just great but if I push into corners and walls and more sophisticated geometry , and I keep pushing into it intensely, after a while it starts to lose synchronisation with the server.Everything else works perfect though.. Is this normal? Should I use more simplistic geometry in order to prevent that, or is this happening because of some errors in netcode?
Synchronisation problems and complex geometry
Is this normal?
No, it is not "normal." It's a bug, somewhere.
What is the nature of the de-sync?
Does the server ever send corrections/baselines to the client?
Unity is not a deterministic physics simulation, so you cannot use ONLY client inputs/commands for sync over time -- you have to occasionally send "make-right" messages for the client from the server. If the server sends "at time T you were in position P," then the client can look back to its time T, calculate the difference between P and that, and then apply that same delta to its current time.
Author
Thanks for reply.
The de-sync is for example : my client while pushing an edge ,keeps moving slowly until it reaches the end(and then it "bursts" in speed ), well..on the server, the position might be a bit different (i don't know why) and it gets to the edge quicker,"bursting" quicker, therefore the server sends the correct position, and since they are different I get snapped to the server position.
Unity physics might be the issue,I heard they are not precise, and me using the default character controller for collisions and movements might result in different positions.
As a side note, I am not using time to measure things,I rather use ticks, like each commands I send to the server are coming with a move_ID int, that keeps increasing by 1 each frame(this happening on a fixed update).
Since all happen in fixed update ,all done carefully to be deterministic, I guess unity physics are to blame. It never ,ever de-syncs while I am not pushing hard into complex geometry, so I am sure its physics to blame.
I guess unity physics are to blame.
The Unity physics engine is not billed as being deterministic, so I wouldn't blame it for not doing something it's not supposed to do :-)
Author
I am not even using the raw physics( rigid body and dynamic things ), I actually use the character controller they made it especially for movements and such.
I think my only solution is to build a manual character controller, which is not easy at all.
OR is there any other work around this?
OR is there any other work around this?
Yes; I already suggested what to do: Send checkpoint messages from the server, containing the full position/orientation of the simulated entity.
You could, for example, send a checkpoint message for one entity per update packet. If you have 40 entities and send 20 messages per second, that means each entity would get corrected once every two seconds, which is probably fine.
Author
But this already happens every 1 second , sending server positions to client, client checking if the difference is not too large.
My idea would be to send the client position ( as I already send inputs 25 times per second), and then the server would do checks and correct player as soon as differences occur. But that would fill bandwidth , I think I would rather simplify my geometry and avoid too many glitchy corners and edges, and also try and maybe tweak the player physics.
My idea would be to send the client position ( as I already send inputs 25 times per second), and then the server would do checks and correct player as soon as differences occur. But that would fill bandwidth , I think I would rather simplify my geometry and avoid too many glitchy corners and edges, and also try and maybe tweak the player physics.
this already happens every 1 second
Then the maximum time that you have de-sync is 1 second? That seems OK for seldom-happening corner cases.
If you want to simplify the geometry, that's entirely up to you -- would it take away from the game?
Author
Seems ok, but it is still annoying to get snapped back to correct position.
Will try to simplify geometry and see how that works.
Will try to simplify geometry and see how that works.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
