Hi, here's some more stuff to consider...
http://wiki.secondlife.com/wiki/Eventlet http://pypi.python.org/pypi/greenlet There is a python wrapper for enet too (in the version control, part of enet). libevent api: http://www.monkey.org/~provos/libevent/ http://code.google.com/p/pyevent/ cheers, On Tue, Jul 29, 2008 at 11:06 AM, René Dudfield <[EMAIL PROTECTED]> wrote: > 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 <[EMAIL PROTECTED]> wrote: >>> -----Original Message----- >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>> On Behalf Of Casey Duncan >>> Sent: Monday, July 28, 2008 4:46 PM >>> To: pygame-users@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 >> >> >
