[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.