The consensus on client/server movement
Author
Hello,
I've been doing research on client/server movement techniques, and this is my approach:
EITHER:
Client performs instantaneous movement of controlled character, sending updates to server say, 5 times a second, which performs its own jerky movement of the character on the server. Server then verifies the clients movement, and replys with confirmation or adjustment messages as necessary.
OR:
client sinply sends control messages to server, which validates them. Sever then sends movements to player character, along with NPC movements etc.
Second approach seems to have higher bandwidth demands, more lag issues, and less responsive gameplay for user.
First approach is there for best - agreed?
Simon
Agreed. That's pretty much what FPS do. For LAN games, with frequent updates, second solution can be viable. It's less complicated, but higher bandwidth, to keep the game responsive.
Whichever technique you use, make sure that the server is checking that the data being sent from clients is reasonable. If this isn't done, then its concievable that a cheater could modify the data to allow them to teleport anywhere in gamespace, now its not exactly the sort of thing thats likely. I only bring it up because I've been working on an open source game where it is likely someone will modify the client.
It's worth noting that you can combine the two methods to get a third option. Use the second method, but instead of relying on the server to send back movements to respond to, have the client predict the movement that the server is going to send to it and simply have the server confirming the movement. The only time that the client will notice that there is jerkiness is when the client is either lagging horrendously or the client is going where it's not supposed to (i.e. cheating).
That method can prove to be very bandwidth friendly if your game doesn't require a ton of twitch action. It's the method most MMOG's use, I believe.
That method can prove to be very bandwidth friendly if your game doesn't require a ton of twitch action. It's the method most MMOG's use, I believe.
I believe that's what he proposed already.
In my experience, what the server does is mostly send confirmations (but that's not even necessary), which is just say, the command packet number, being confirmed as valid.
When the client diverge, then a correction is sent, again this is very small. A vector, for the corrected position, and the timestamp, the that new position can be inserted into the client's movement interpolator.
These corrections occur only when an unpredictable movement happens on the client or server, which throws the simulations onto different paths. This mostly happens when a player collides with another moving player (since you can never predict player inputs; at best, guess them), or with a physics object falling over. Counterstrike:Source is a good example of that. This is in my opinion, why the barrel collision is so dodgy, since it was made intentionally unnatural to smooth out potential corrections.
In my experience, what the server does is mostly send confirmations (but that's not even necessary), which is just say, the command packet number, being confirmed as valid.
When the client diverge, then a correction is sent, again this is very small. A vector, for the corrected position, and the timestamp, the that new position can be inserted into the client's movement interpolator.
These corrections occur only when an unpredictable movement happens on the client or server, which throws the simulations onto different paths. This mostly happens when a player collides with another moving player (since you can never predict player inputs; at best, guess them), or with a physics object falling over. Counterstrike:Source is a good example of that. This is in my opinion, why the barrel collision is so dodgy, since it was made intentionally unnatural to smooth out potential corrections.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
