If you’re reading this, there probably aren’t very many posts yet. But don’t worry, you can be the first! Either create a new post or just reply to this one to say ‘hi’.
The only easy approach I could come up with that you didn’t cover was to have no “client-side” movement at all - instead the player would send his inputs to the server and the server would send back the player pawn’s location, rotation and velocity. Of course the massive problem with that is the potential input lag due to network latency.
Other than that I’m aware that techniques like prediction and reconciliation exist, but wouldn’t know how to implement them. (I’m hoping these will be covered in the course.)
Absolutely will be!
Ok so I thought about:
- Simulate only on clientside and tell server about our position and rotation. Cons: Cheating
- Make the client simulated proxy and run all the code on the server. Cons: Lag
- Replicate the location, rotation and time from the server, use a fixed replication time, override the client’s location and rotation but use the time to account for the time lag since we didn’t get the info from the server. That way we could override and even if there was lag we could predict where the server will be according to this data. Cons: hmm cannot think of any, maybe this is tricky to implement?
I jumped right into this part of the course to learn more about replication, this is very interesting!
But you could make the server enforce sensible limits.
Almost impossible to make PhysX work in a deterministic way. But in this section we do implement our own fixed time step “physics” and use this approach.
- Replicate the location, rotation and time from the server, use a fixed replication time …
Fixed replication time is a great idea.
One con is that you would see teleporting when it corrects. But that could be fixed by lerping between transforms. Although it would make the physics look wrong when the car is sliding to the correct location.