Re: [pygame] SOC Proposal: Networking for Pygame

["Rene Dudfield" <renesd@xxxxxxxxx>]

+1 on needing a few complete games as examples, and to 'prove' the api.

The games could be simple 48hour style ones.  Or could take some
existing games and add networking.

That reliability stuff is very similar to what is in Enet.  Which is a
good thing.  Enet gets around the priority stuff by using channels.



On 5/8/06, Phil Hassey <philhassey@xxxxxxxxx> wrote:
> This framework has been recommended for C++ games -- some of the ideas used
> in it could be useful for inspiration to a pygame project.  (I think it uses
> UDP for its protocol.)
>
>  http://www.rakkarsoft.com/
>
>  In particular, there are 5 reliability types:
> http://www.rakkarsoft.com/raknet/manual/reliabilitytypes.html
>  UNRELIABLE,
>  UNRELIABLE_SEQUENCED,
>  RELIABLE,
>  RELIABLE_ORDERED,
>  RELIABLE_SEQUENCED
>
>  Having each of these built in could be quite useful.  And being able to
> pick and choose on a per packet basis would be useful.
>
>  I'm just learning some UDP game networking stuff right now, so I don't have
> any real clear ideas on how these should be implemented, or API etc.  But I
> do know it would be very handy if pygame had them (then I wouldn't be trying
> to implement really hackish versions of them right now ;)
>
>  I definitely think that a SOC project should include several complete games
> (probably minimal in the graphics / sound department) that demonstrate the
> ease of use of the API as well as its flexibility.
>
>  Phil
>
>
> Rene Dudfield <renesd@xxxxxxxxx> wrote:
>
>  If the networking is threaded or async, then using the pygame event
> queue is quite possible. A blocking api is not useful for games.
>
> The reason for using the SDL event queue is to keep event management
> in one place. If people already understand the pygame event model,
> then they should be able to reuse that knowledge for the network
> events.
>
>
> On 5/8/06, Peter Shinners wrote:
> > On Sun, 2006-05-07 at 20:27 -0700, Brian Fisher wrote:
> > > Also, having to integrate the packet handling into your main loop
> > > wouldn't necessarily help you have good design - for some network
> > > models, it makes a lot more sense to encapsulate the communication
> >
> > I'd lean towards this design as well. Just make the "pump" style
> > function also return all the updates since the previous call.
> >
> > If the API is going to be threaded then using the Pygame/SDL event queue
> > makes a bit more sense. Make each connection take an event id number to
> > use. This is still easy enough to use, but avoids id collisions.
> >
> >
> >
>
>
>
>
>  ________________________________
> New Yahoo! Messenger with Voice. Call regular phones from your PC and save
> big.