Handling Networked CharacterControllers
Posted: Thu Jun 28, 2018 11:39 pm
Hey Ross,
First, just wanted to say thanks again for the fantastic library; it's really been invaluable for me and a blast to work with.
I have a question about the best approach for handling networked character controllers. In the past, I've implemented fairly decent-feeling networked character movement system with Unity's physics engine, and I have a decent recollection of how that works. However, I'm struggling a bit to figure out the best way to implement this kind of thing on BEPU physics; I think I might need to re-think my structure a bit.
My world basically just consists of (at the moment):
* Static geometry, mostly boxes, but some convex meshes as well. All static, non-moving, etc. Same between client/server
* Player character(s), each with a BEPUphysics.Character.CharacterController attached.
The way I implemented my movement logic, prediction, and error correction in Unity was basically:
* Clients send input packets to server, with timestamps
* Server processes input packets one at a time, simulating the Unity CharacterController for each individual timestep, with each individual input state
* Client also processes individual input state packets one at a time, in the same manner.
* Server sends a "correction" packet back to the client if the state becomes too de-synced (each side keeps a small list of past physics and input states).
* When a client gets a correction packet, it goes back to that state and reapplies the input states that occurred after the corrected timestamp. To smooth out the "correction jitter", I simultaneously apply a rendering offset which gets smoothed out over time.
I'm trying to do the same thing in my custom engine using BEPU physics, but the results are not great at the moment. The part that I'm missing (unless I'm completely off-base, which is likely ), is the part above where individual characters are simulated with individual input states for a particular time slice. With BEPU, "processing the input packet" currently just involves setting the CharacterController's desired direction, velocity, jump state, etc. and letting the physics simulation run as normal. As you can imagine, this works fine when the server and client have low latency, low packet loss, and are operating at the exact same timestep duration. The approach I used above was much better about being resilient to those sorts of problems.
At this point, I certainly wouldn't rule out bugs in my networking or sync code, but any help about the general approach I should be taking would be much appreciated. Am I way off-base with how I'm handling things?
First, just wanted to say thanks again for the fantastic library; it's really been invaluable for me and a blast to work with.
I have a question about the best approach for handling networked character controllers. In the past, I've implemented fairly decent-feeling networked character movement system with Unity's physics engine, and I have a decent recollection of how that works. However, I'm struggling a bit to figure out the best way to implement this kind of thing on BEPU physics; I think I might need to re-think my structure a bit.
My world basically just consists of (at the moment):
* Static geometry, mostly boxes, but some convex meshes as well. All static, non-moving, etc. Same between client/server
* Player character(s), each with a BEPUphysics.Character.CharacterController attached.
The way I implemented my movement logic, prediction, and error correction in Unity was basically:
* Clients send input packets to server, with timestamps
* Server processes input packets one at a time, simulating the Unity CharacterController for each individual timestep, with each individual input state
* Client also processes individual input state packets one at a time, in the same manner.
* Server sends a "correction" packet back to the client if the state becomes too de-synced (each side keeps a small list of past physics and input states).
* When a client gets a correction packet, it goes back to that state and reapplies the input states that occurred after the corrected timestamp. To smooth out the "correction jitter", I simultaneously apply a rendering offset which gets smoothed out over time.
I'm trying to do the same thing in my custom engine using BEPU physics, but the results are not great at the moment. The part that I'm missing (unless I'm completely off-base, which is likely ), is the part above where individual characters are simulated with individual input states for a particular time slice. With BEPU, "processing the input packet" currently just involves setting the CharacterController's desired direction, velocity, jump state, etc. and letting the physics simulation run as normal. As you can imagine, this works fine when the server and client have low latency, low packet loss, and are operating at the exact same timestep duration. The approach I used above was much better about being resilient to those sorts of problems.
At this point, I certainly wouldn't rule out bugs in my networking or sync code, but any help about the general approach I should be taking would be much appreciated. Am I way off-base with how I'm handling things?