3 ms·

For a realtime game, player position would be kind of essential, no? "move here unreliably" "shoot at x reliably" Mixing reliable and unreliable updates for ga

by zurn 13y ago

For a realtime game, player position would be kind of essential, no? "move here unreliably" "shoot at x reliably" Mixing reliable and unreliable updates for game logic would seem to result in a lot of complexity as things can be out of sync in a variety of ways now.

forgottenpass 13y ago
For a realtime game, player position would be kind of essential, no? Yes, but UDP is choosing unreliable transport, not throwing away data entirely. No matter the transport, once you start dropping a large enough number of packets it will degrade (or break) the experience. The use case being discussed is when getting the next packet fast is more important than the overhead of TCP. You can build retries or various other forms of reliability into your UDP protocol when outdated information is still useful. Mixing reliable and unreliable updates for game logic would seem to result in a lot of complexity Yes and no. It's complex because game state is complex to begin with, but less daunting than you may think because you can compartmentalize to different components of the game. You're not likely to using multiple transports for the same information. See the parent's chat vs player position example.
Borogove 13y ago
Obsolete player position data is worse than no player position data.
fulafel 13y ago
The Quake 3 writeup cites exactly this problem as the reason Carmack abandoned the reliable+unreliable combination: "His next iteration involved using UDP with both reliable and unreliable data, pretty much what many would consider a standard networking architecture. However standard mixed reliabled/unreliable implementations tend to generate very hard to find bugs, e.g. sequencing errors where guaranteed messages referenced entities altered through unreliable messages." (from http://fabiensanglard.net/quake3/The%20Quake3%20Networking%20Mode.html http://fabiensanglard.net/quake3/The%20Quake3%20Networking%2... )

by zurn 13y ago

forgottenpass 13y ago

For a realtime game, player position would be kind of essential, no? Yes, but UDP is choosing unreliable transport, not throwing away data entirely. No matter the transport, once you start dropping a large enough number of packets it will degrade (or break) the experience. The use case being discussed is when getting the next packet fast is more important than the overhead of TCP. You can build retries or various other forms of reliability into your UDP protocol when outdated information is still useful. Mixing reliable and unreliable updates for game logic would seem to result in a lot of complexity Yes and no. It's complex because game state is complex to begin with, but less daunting than you may think because you can compartmentalize to different components of the game. You're not likely to using multiple transports for the same information. See the parent's chat vs player position example.

Borogove 13y ago

Obsolete player position data is worse than no player position data.

fulafel 13y ago

The Quake 3 writeup cites exactly this problem as the reason Carmack abandoned the reliable+unreliable combination: "His next iteration involved using UDP with both reliable and unreliable data, pretty much what many would consider a standard networking architecture. However standard mixed reliabled/unreliable implementations tend to generate very hard to find bugs, e.g. sequencing errors where guaranteed messages referenced entities altered through unreliable messages." (from http://fabiensanglard.net/quake3/The%20Quake3%20Networking%20Mode.html http://fabiensanglard.net/quake3/The%20Quake3%20Networking%2... )