[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] SOC Proposal: Networking for Pygame



I think using a separate thread is the best approach. Are most Pygame API 
calls thread safe? Most importantly, is pygame.event.post(e) thread safe?

I also think it should be possible to use in headless servers. It would be a 
shame to have to use a separate network library on your game client and game 
server. Also, I think that some game servers will need to perform game 
operations, not just forward packets. You may want to push game processing to 
the server to make cheating more difficult, or at least have random checks to 
make sure the clients are processing correctly.

How this is done is another issue. The event queue could be emulated, which 
may be fairly easy since we already have to buffer events to avoid 
overflowing the SDL queue. Or there could be a callback interface. What other 
architectures are out there? I will try to look at enet, twisted and the 
Quake link, but I'm pretty busy with a couple of contracts right now.

With the architecture I outline in my proposal, you could inherit from a lower 
level protocol and override handler methods. I think emulating the event 
queue would also be useful though, especially for headless game servers doing 
game processing.

I think it would be great to have a Wiki node to discuss protocol needs for 
different games, and suggest the best implementation. We could start 
classifying games into types based on their needs for networking, and narrow 
it down to a handfull of basic types.

For example, my tron game sends direction change events, item pickup events, 
item used events, and collision events. These events could occur many seconds 
apart, so sending synchronization packets periodically may be helpful. All 
events except for synch events must be lossless. A UDP remote event protocol 
with support for lossless and lossy events would probably be best, but a TCP 
based protocol would probably also work, since the game isn't very demanding 
in terms of networking.

On Tuesday 09 May 2006 02:48, Rene Dudfield wrote: 
> * Does the select call run in a different thread?
>   - This is allows apps which use pygame.event.wait to work correctly.
>   - However, most games do not use pygame.event.wait
>   - It also allows better latency.  Eg, during a pygame.display.flip()
> data can be read.
>
> * Can the net lib can be used without the event loop?
>   - Being able to use the net lib without the event loop is useful for
> headless servers.
>   - Allow those that don't want to use the event queue to use it.
>
>
> I like your safe serialiser.  It's probably a good one to use.
>
> ps.  here is another useful link.  It describes the quake networking model.
> http://www.bookofhook.com/Article/GameDevelopment/TheQuake3NetworkingModel.
>html
>
> There's a couple of pygame using games with networking support now.
> Flamingo, and philhasseys latest LD48H entry is working on networking
> too.  Which is nice, since those can be used for example games to see
> if the networking module made is good.
>
> On 5/9/06, Simon Wittber <simonwittber@xxxxxxxxx> wrote:
> > To Summarize:
> >
> > It seems we agree that:
> >  * The event loop must be usable in a headless environment.
> >  * The net lib looks after buffering
> >  * The net lib looks after reconnection attempts
> >  * Low Level Network events can be posted to the event loop.
> >   - Incoming low level network events is good for people who hack
> > their own protocols
> >   - Perhaps the low level events are blocked by default?
> >  * USEREVENTs can be posted to the event loop
> >   - the events come from from incoming network data
> >
> > But we don't yet agree on, or haven't considered:
> >  * Does the select call run in a different thread?
> >   - This is allows apps which use pygame.event.wait to work correctly.
> >   - However, most games do not use pygame.event.wait
> >  * Can the net lib can be used without the event loop?
> >
> >
> >
> > For the record, I have implemented an event dispatch mechanism which
> > works over a TCP connection. I post pygame events into the same
> > dispatch mechanism, and use it for my main game loops. It works very
> > well. Unfortunately, it depends on twisted, doesn't provide UDP, and
> > requires an explicit poll call. It does however, show that this style
> > of networking can work in real applications. Howeverm one thing I have
> > found that I do need at times is some form of request / response
> > construct, which simple event passing doesn't automatically provide.
> >
> > It has a safe serializer, which is something this SoC proposal will
> > need to implement if USEREVENT's are going to be passed across a
> > network, and reconstructed into usable events.
> >
> > Network Event Dispatch:
> > http://trac.xerian.net/trac/xerian.net/browser/FibraNet/trunk/eventnet
> >
> > Safe Serializer:
> > http://trac.xerian.net/trac/xerian.net/browser/FibraNet/trunk/gherkin.py
> >
> >
> > -Sw.