RE: [pygame] Re: [OLPC-Games] PyQNet project on Launchpad

["Noah Kantrowitz" <noah@xxxxxxxxxxxxxx>]

> -----Original Message-----
> From: owner-pygame-users@xxxxxxxx [mailto:owner-pygame-users@xxxxxxxx]
> On Behalf Of Casey Duncan
> Sent: Monday, July 28, 2008 5:13 PM
> To: pygame-users@xxxxxxxx
> Subject: Re: [pygame] Re: [OLPC-Games] PyQNet project on Launchpad
> 
> 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.

Yes, this is an excellent use of UDP for game networking. My point is just
that designing your game to allow this cleanly is very difficult, and
slapping retransmission on top of UDP actually gets you worse off than
simply using TCP. I get antsy seeing UDP mentioned around games because I
think 1) people discard TCP as unusable far too fast and 2) people don't
understand how hard _good_ networking is.

--Noah