On Jul 28, 2008, at 5:55 PM, Noah Kantrowitz wrote:
TCP has many semantics that can be undesirable for some games, in
particular "guaranteed delivery" regardless of effective time of
transmission. In many real-time applications (FPS games come to
mind),
state data becomes out of date very quickly, thus if the transmission
cannot be completed in a particular time window, it is better not to
receive the data at all. In these games the state updates can become
roughly like a stream.
In any game network protocol I have ever seen, this is simply not
true. For
example, position is generally not sent as an absolute, but as
difference.
Aside from periodic resyncs, the moment-to-moment updates generally
all do
need to be received.
Quake 3 famously issues updates solely via udp as a delta between the
last known state of the receiver and the sender bi-directionally. This
has been widely copied in games of that genre in the following years
and was considered at the time to be a huge advance over the mixture
of reliable and unreliable transmission modes used before.
UDP has a lower overhead than TCP, making it advantageous for sending
streaming data where intermittent loss is preferable to indeterminate
data lag.
The overheard will be lower than implementing a similar system
yourself in
UDP. Also dynamic window sizing means that the overhead is generally
too
small to speak of.
The lower overhead is more of a bonus, not the main benefit. The main
benefit is direct control over the delivery and retransmission
semantics. At the expense, of course, of having to implement these
things yourself.
I'm not trying to argue that UDP is better, but it certainly has its
advantages for specific applications.
-Casey
