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

Re: [pygame] SOC Proposal: Networking for Pygame





On 5/8/06, 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.
 
Bingo.  This is what I was thinking, as a motive for using the SDL event queue.
 
A related motive is that games sometimes have multiple modes, in terms of networking and
non-networking sessions.  One session may be against a networked player and another against an
artificial intelligence module.   Using an event queue not specific to networking allows more orthogonal
game design.  Whether the opponent move comes from an AI thread or a networked opponent, it comes
through the same event queue and can be handled with the same code.
 
Would it be reasonable to include a pygame event number allocator in a future release of Pygame?  It would
be nice for a pygame-dependant library to be able to just request a unique event number in its initialization code, rather
than arbitrarily choosing a number, and expecting the user programmer to detect and avoid collisions.
 
David
 
On 5/8/06, Peter Shinners <pete@xxxxxxxxxxxx> 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.
>
>
>



--
dkeeney@xxxxxxxxxxxxxxxx
Pitcher's Duel -> pitchersduel.python-hosting.com