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

Mon Jul 28 21:06:15 EDT 2008

hello,

below are a collection of notes for game networking...

For the pygame 1.9+ release we would really like to get networking
library routines in :)  Something that's simple, and has been used
successfully in at least 2 games( 1 by the author, and 1 by someone
else) would be nice.  Getting your library ready for ludumdare.com
(august 8-10), and pyweek.org (sept 31st) would allow other people to
try it out by making games.

Channels in UDP are cool.  They allow you to separate data which cares
about order or sequence.  Here's a description from a game UDP
networking library...  note enet is used by the cube engine.
http://enet.bespin.org/Features.html

For udp please consider being tcp friendly...
http://www.psc.edu/networking/projects/tcpfriendly/

Seeing network events in the pygame event queue would simplify things
for people. So networking then becomes like any other event.

#pygame.network.send(data, channel, lossy)
pygame.network.send("hello network.", CHANNEL_CHAT, 0)

for e in pygame.event.get():
   if e.type == NETWORK:
       if e.what == NETWORK_DATA_IN:
           print e.channel
           print e.data
           print e.sequenceid
           print e.peer
           if e.channel == CHANNEL_CHAT:
               # we write the incomming text to our chat window.
               chatwindow.write_text(e.peer, e.data)

OSC is an important consideration too. OSC is the new midi.  It's a
pretty good UDP based protocol for real time use. It's widely used in
the music world as a networked replacement for midi, and a little bit
in the game world.

http://en.wikipedia.org/wiki/OpenSound_Control

It does things quite well for real time use. Things like bundling
messages together. So if you send a bunch of messages they can be
played back in time. This is obviously very useful for music, but also
for games... where timing is important for many games.

This idea from OSC(bundling timed events) can be used to replay events
with the same time that they appeared in one machine on another
machine.  However OSC can be implemented separately if needed(and has
already been made
http://www.ixi-audio.net/content/body_backyard_python.html ).

Another thing to consider is sending video data.  Video data can be
quite large :)  Especially when you get into the 10gbit area.

Here's a discussion on quake 3 networking...
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking

Noah code:
https://coderanger.net/svn/school/2007/fall/egd/magnoball/pygamenet.py

Simon Wittabers twisted implementation of simple networking.
http://code.google.com/p/pygnet/

Notes from 2006 pre-gsoc about simple networking for pygame.
http://wiki.python.org/moin/SummerOfCode/PythonLibraries/SimpleNetworkingForPygame

Concurrent programming using an actor component based model.  (note
the website is ancient... but there is actually an active community
there with 5 or gsoc students)
http://kamaelia.sourceforge.net/Home
http://yeoldeclue.com/cgi-bin/blog/blog.cgi  (this blog by the author
has more current info on it)

sjbrowns networking tutorial using twisted:
http://sjbrown.ezide.com/games/writing-games.html

raknet is one of the top game networking libraries... written in C++
Good to look at for features, and ways they do things.
http://www.jenkinssoftware.com/

http://www.pygame.org/tags/network
http://www.pygame.org/tags/multiplayer

Tunneling over http, and using serial ports is something else to
consider :)  As is communication via camera(in) and video(out) screen
;)

anyway... just some notes for reading.

cu,

On Tue, Jul 29, 2008 at 9:55 AM, Noah Kantrowitz <noah at coderanger.net> wrote:
>> -----Original Message-----
>> From: owner-pygame-users at seul.org [mailto:owner-pygame-users at seul.org]
>> On Behalf Of Casey Duncan
>> Sent: Monday, July 28, 2008 4:46 PM
>> To: pygame-users at seul.org
>> Cc: 'Games for the OLPC'
>> Subject: Re: [pygame] Re: [OLPC-Games] PyQNet project on Launchpad
>>
>> On Jul 28, 2008, at 4:49 PM, Noah Kantrowitz wrote:
>> >>> [..]
>> >> https://coderanger.net/svn/school/2007/fall/egd/magnoball/
>> >> pygamenet.py
>> >>> . Also a WiP.
>> >> PyQNet is split over 8 modules, but the actual number of code-lines
>> >> in
>> >> the library (excluding the tests) is pretty small (640 incl.
>> comments
>> >> and docstrings), pygamenet is around 591 when you take out the
>> >> comments.  Though PyQNet is likely to grow substantially once I get
>> >> all
>> >> the features I want implemented.
>> >>
>> >> The difference in size currently is likely because PyQNet is
>> >> implemented
>> >> as UDP with ordering and retry controlled by the Python code
>> >> instead of
>> >> using TCP-level operations.  The UDP operations should allow us to
>> >> code
>> >> adaptations into the library to optimize for low-latency game-y
>> >> operation.
>> >
>> > This is a common misconception. The reason to use UDP is not for low-
>> > latency
>> > (just set TCP_NODELAY), but to accommodate lossy links. Generally
>> > this means
>> > dealing with either bad connections or high congestion. And when I
>> > say "deal
>> > with" I mean "detect and die", not just reimplementing
>> > retransmission on top
>> > of UDP. As it stands there is no real reason to use UDP for games
>> > anymore
>> > unless you really think the vast majority of your users will be on
>> bad
>> > connections. I don't think this is the case, even for OLPC (sat
>> > links are
>> > slow, but generally not lossy).
>>
>> 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.
>
>> 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.
>
> --Noah
>
>