Sending change or exact position?
I've been reading how networking works in games, and have found several, specifically Quake 3, send the different over the net. Is there an advantage to sending the change since a given time to what the latest position of everything is? Thanks. -Nick
If you send the change then your packets might be a little smaller. However consider what happens if a packet get dropped. As little as one dropped packet will result in the players being out of sync with each other, and this problem will become worse as the game progresses until it becomes unplayable
I believe allowing the player to send its position opens the door to various cheats like teleporting. Its easier to check that position changes are valid than to check absolute positions. Better yet, let the client just send the commands entered. Thumbrule: never thrust the client application!
@Vyper_uk: If player actions (including movement) are not sent over a TCP or TCP-like link (that guaranties that the packets will get there eventually), then the server and the client should check if they are still well sync to each other.
@Vyper_uk: If player actions (including movement) are not sent over a TCP or TCP-like link (that guaranties that the packets will get there eventually), then the server and the client should check if they are still well sync to each other.
Quote:
Original post by Vyper_uk
However consider what happens if a packet get dropped. As little as one dropped packet will result in the players being out of sync with each other, and this problem will become worse as the game progresses until it becomes unplayable
This can be solved by having the client acknowledge received packets. The server then sends changes to a particular client based on its last acknowledged update. The client should timestamp each acknowledgement, and the update packets should include the timestamp of the last known acknowledgement. That way, if an acknowldegement gets lost, or the server sends an update before the it has received the ack of the last update, the client can compare timestamps to know which state to base the update off of.
--- Official D Blog | Learning D | The One With D | D Bits
My current architecture trusts nothing to the client. All the client does is take input, and send the data using bitflags for buttons pressed to the server. My question is of how the server sends data to the client.
When Quake 3 sends a "difference" it means that it sends the parts of the player struct that have changed; it does not mean it sends (pos-lastpos).
So, if the player struct contains fields for pos, vel, health, ammo, and current weapon, then there would be five bits in the header, saying which of the fields are included in the packet. The baseline for comparision is the last acknowledged packet the client received. This is more described in the Forum FAQ.
So, if the player struct contains fields for pos, vel, health, ammo, and current weapon, then there would be five bits in the header, saying which of the fields are included in the packet. The baseline for comparision is the last acknowledged packet the client received. This is more described in the Forum FAQ.
enum Bool { True, False, FileNotFound };
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement