[OLPC-Games] [pygame] Re: PyQNet project on Launchpad
renesd at gmail.com
Mon Jul 28 22:27:12 EDT 2008
here's some more stuff to consider...
There is a python wrapper for enet too (in the version control, part of enet).
On Tue, Jul 29, 2008 at 11:06 AM, René Dudfield <renesd at gmail.com> wrote:
> 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.
> For udp please consider being tcp friendly...
> 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.
> 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...
> Noah code:
> Simon Wittabers twisted implementation of simple networking.
> Notes from 2006 pre-gsoc about simple networking for pygame.
> 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://yeoldeclue.com/cgi-bin/blog/blog.cgi (this blog by the author
> has more current info on it)
> sjbrowns networking tutorial using twisted:
> raknet is one of the top game networking libraries... written in C++
> Good to look at for features, and ways they do things.
> 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.
> 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.
>>> >> 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
>>> > 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.
More information about the Games