Re: [pygame] Split screen question (newbie)

[Casey Duncan]

On Nov 21, 2007, at 5:57 PM, Kris Schnee wrote:

[..]
With subsurfaces, eh? I was thinking more like:

w,h = SCREEN_SIZE ## eg. (800,600)
top_screen = pygame.surface.Surface((w,h/2))
bot_screen = pygame.surface.Surface((w,h/2))

def Draw():
DrawPlayerOneScreen(top_screen) ## Draw game stuff onto these  
surfaces

DrawPlayerTwoScreen(bot_screen)
screen.blit(top_screen,(0,0))
screen.blit(top_screen,(0,h/2))
pygame.display.update()


What's the purpose of using subsurfaces? I don't understand those.


If you use subsurfaces, you don't need these lines at all:


screen.blit(top_screen,(0,0))
screen.blit(top_screen,(0,h/2))


Because when you blit to the subsurfaces, you are also blitting to  
the screen (because subsurfaces share pixel data with their parent).  
It means the system does less work and you use less memory, but the  
effect is the same.


-Casey

Re: [pygame] Split screen question (newbie)

[Kris Schnee]

On Nov 21, 2007, at 11:19 AM, Miguel Sicart wrote:
Now, the problem is that I am to game programming what military music 
is to music, so I don't want to go into tiling or scrolling 
backgrounds (but hey, I'd love to learn more about tiling at some 
moment!).


Ask when you'd like to hear about it!


Casey Duncan wrote:

screen = pygame.display.set_mode()
and then a background:
background = pygame.Surface(screen.get_size())


Then do something like:

top_rect = screen.get_rect()
top_rect.height = top_rect.height / 2
top_screen = screen.subsurface(top_rect)
bot_rect = top_rect.move(0, top_rect.height)
bot_screen = screen.subsurface(bot_rect)

Now use top_screen to draw into the top and bot_screen to draw into the 
bottom. You flip the main screen surface as usual to see the result 
since drawing to top_screen and bot_screen actual just draws into 
different positions of screen.


for example, try:

top_screen.fill((255,0,0))
bot_screen.fill((0,0,255))
pygame.display.flip()


With subsurfaces, eh? I was thinking more like:

w,h = SCREEN_SIZE ## eg. (800,600)
top_screen = pygame.surface.Surface((w,h/2))
bot_screen = pygame.surface.Surface((w,h/2))

def Draw():
DrawPlayerOneScreen(top_screen) ## Draw game stuff onto these surfaces
DrawPlayerTwoScreen(bot_screen)
screen.blit(top_screen,(0,0))
screen.blit(top_screen,(0,h/2))
pygame.display.update()


What's the purpose of using subsurfaces? I don't understand those.

Re: [pygame] Networking?

[Richard Jones]

On Thu, 22 Nov 2007, David wrote:
> On 11/20/07, Richard Jones <[EMAIL PROTECTED]> wrote:
> > > 2) Use the Twisted reactor *as* your main loop, and implement all game
> > > logic as call-backs from there. This is the approach that the Twisted
> > > people will recommend.
> >
> > This is also useless for highly interactive games.
>
> I consider my game highly interactive, though the network traffic intensity
> is not very high.  Can you elaborate
> on why the Twisted reactor is useless?

The minimum time you can pass to iterate() is quite high -- 0.01 seconds IIRC. 
This means a significant amount of processing time is lost.

A possible solution is to only run the reactor.iterate() once every few 
frames.


> >  3) Run the Twisted reactor in its own thread
> >
> > This is probably the only reasonable approach for games.
>
> My only experience with threads was in writing an image slideshow program.
> The graphic blends
> and transitions were very jerky with threads.  Changing to a
> generator-coroutine approach worked more
> smoothly.   I do not recall any capability in the thread modules for
> adjusting 'niceness' or state-change frequency.

True - this is a problem I ran into. The only solution I could find was to 
have the thread periodically artificially block using a semaphore.


 Richard

Re: [pygame] Break outside the loop

[Ian Mallett]

True.  It's just not strictly necessary.  "StopIteration" is specific.

Re: [pygame] Split screen question (newbie)

[Casey Duncan]

On Nov 21, 2007, at 11:19 AM, Miguel Sicart wrote:


Hi all,

Thanks a lot for the help!
Ok, so what I am interested in doing is sort of artsy-fartsy little  
videogames (think Rob Humble's The Marriage), and this is one of  
them: top of the screen, player one will be doing one thing  
(collecting items, destroying items); bottom of the screen, player  
two will be doing other things (putting items together). And that  
is it, more or less :)
Now, the problem is that I am to game programming what military  
music is to music, so I don't want to go into tiling or scrolling  
backgrounds (but hey, I'd love to learn more about tiling at some  
moment!).
My intuition was very much towards Casey and Ian's comments - two  
subsurfaces where I can draw. Question is, I have no idea how to  
practically do that.

I do the screen the classic way, I think
screen = pygame.display.set_mode()
and then a background:
background = pygame.Surface(screen.get_size())


Then do something like:

top_rect = screen.get_rect()
top_rect.height = top_rect.height / 2
top_screen = screen.subsurface(top_rect)
bot_rect = top_rect.move(0, top_rect.height)
bot_screen = screen.subsurface(bot_rect)

Now use top_screen to draw into the top and bot_screen to draw into  
the bottom. You flip the main screen surface as usual to see the  
result since drawing to top_screen and bot_screen actual just draws  
into different positions of screen.


for example, try:

top_screen.fill((255,0,0))
bot_screen.fill((0,0,255))
pygame.display.flip()

-Casey

Re: [pygame] Split screen question (newbie)

[Miguel Sicart]

Hi all,
Thanks a lot for the help!
Ok, so what I am interested in doing is sort of artsy-fartsy little
videogames (think Rob Humble's The Marriage), and this is one of them: top
of the screen, player one will be doing one thing (collecting items,
destroying items); bottom of the screen, player two will be doing other
things (putting items together). And that is it, more or less :)
Now, the problem is that I am to game programming what military music is to
music, so I don't want to go into tiling or scrolling backgrounds (but hey,
I'd love to learn more about tiling at some moment!).
My intuition was very much towards Casey and Ian's comments - two
subsurfaces where I can draw. Question is, I have no idea how to practically
do that.
I do the screen the classic way, I think
screen = pygame.display.set_mode()
and then a background:
background = pygame.Surface(screen.get_size())

Blitting and flipping follow :)

So how could I do this?

Thanks a bunch! (uff, and sorry for the longish email :)

Naranjito

On 11/21/07, Ian Mallett <[EMAIL PROTECTED]> wrote:
>
> Same in OpenGL.  You just choose which part of the window you're drawing
> into.
>

Re: [pygame] Break outside the loop

[Sami Hangaslammi]

On Nov 21, 2007 8:27 PM, Ian Mallett <[EMAIL PROTECTED]> wrote:
> while 1:
> grid.update()
> try:
> explorer.next()
> except StopIteration:
> break
>
> By the way, "except StopIteration" can be replaced by just: "except",
> because there are no futher conditional "except"s.

Absolutely not. That would silently mask all errors that could happen
inside "next" leading to potentially hard to debug bugs. Empty
catch-all except-blocks should only be used in very rare cases where
you want to process all errors in the same way (e.g. some logging code
that the program root level).

-- 
Sami Hangaslammi

Re: [pygame] Break outside the loop

[Ian Mallett]

For one thing, I think that he meant for this:

while 1:
grid.update()
try:
explorer.next()
except StopIteration:
break

...to be this:

while 1:
grid.update()
try:
explorer.next()
except StopIteration:
break

By the way, "except StopIteration" can be replaced by just: "except",
because there are no futher conditional "except"s.

Ian

Re: [pygame] Break outside the loop

[Luke Paireepinart]

Joseph king wrote:

I keep getting a ***'break' outside the loop error on this code can anyone help


 for y in range(8):
 for x in range(8):
   c = Canvas()
   c.grid(column=x, row=y)
# make a grid
   grid = Grid(c, cellsize_x=8, cellsize_y=8, gridsize_x=10, gridsize_y=10)
# get the maze generator
   explorer = MazeBuilder(grid)

while 1:
  grid.update()
try:
  explorer.next()

except StopIteration:
break
  

I'm not really too clear on what's happening here.
You can use break to get out of for loops, can't you?
Shouldn't this just be a logical error, and just get hung in the while 
loop (since it has no exit condition)?
Or is the problem that the 'while 1' is tabbed over slightly less than 
the inner 'for x in range(8)' which is somehow causing

it to be outside of the outer for loop, or something?
I'd appreciate it if someone could explain that.
-Luke

Re: [pygame] Split screen question (newbie)

[Ian Mallett]

Same in OpenGL.  You just choose which part of the window you're drawing into.

Re: [pygame] Split screen question (newbie)

[Casey Duncan]

On Nov 21, 2007, at 8:28 AM, Dan Krol wrote:


Maybe this is what Kris already said, but I think that you should use
two surfaces, sized at half the height of the screen. That way they
work essentially as two independent screens, clipping is handled for
you, etc. Then when it comes to drawing the surfaces, put one surface
at the top and one at the bottom (I don't know the exact call or
parameters, you'd have to look that up).


You might try creating two subsurfaces of your display surface, then  
draw the views into each. That way you get two separate surfaces but  
when you draw on them it draws through to the underlying screen in  
the proper place, without doing any extra work.


-Casey

Re: [pygame] Split screen question (newbie)

[Dan Krol]

Maybe this is what Kris already said, but I think that you should use
two surfaces, sized at half the height of the screen. That way they
work essentially as two independent screens, clipping is handled for
you, etc. Then when it comes to drawing the surfaces, put one surface
at the top and one at the bottom (I don't know the exact call or
parameters, you'd have to look that up).

Re: [pygame] Split screen question (newbie)

[kschnee]

On Wed, 21 Nov 2007 16:33:39 +0100, Mundial 82 <[EMAIL PROTECTED]> wrote:
> Hi all,
> 
> ok, so I am a bit of a newbie and I am trying to make a split screen
> game. The idea is very simple: screen divided in halves, top and
> bottom spaces are wrapped, and not connected at all (think two
> different spaces). It would be great if the two sides could have
> different backgrounds.
> I have no clue how to due this,  so any help is very welcome. I guess
> my level is pretty low: I can make asteroids and spacewar kind of games.

Hi there!

There isn't really a split-screen mode built into Pygame; you can draw
whatever you want, wherever you want. The question is what you're drawing.

Say that you've got a scrolling tile engine, where two characters are
moving around independently, and you want each half of the screen to follow
one of them. In the drawing part of your game's main loop you might say
something like:

top, bottom, left, right = FigureOutRangeOfTilesToDraw(P1.location) ##
Based on what part of the game world P1 is in
DrawTiles((top,bottom,left,right),(0,0)) ## Draw stuff to the top half of
the screen
top, bottom, left, right = FigureOutRangeOfTilesToDraw(P2.location) ##
Based on what part of the game world P2 is in
DrawTiles((top,bottom,left,right),(0,half_of_screen_height)) ## Draw stuff
to the bottom half of the screen


The point is that you just draw the game world twice per frame, with the
area depicted being centered around each character and the area you draw
_to_ being restricted to half of the screen. There's no special command for
it.

It might be helpful if you'd sketch and post what you want the split to
look like. Would this be for a game with characters in a scrolling world,
or what? It wouldn't make sense to do a split screen for the sort of
static-screen games some people make.

Kris

Re: [pygame] This showed up in pygame-users@seul.org

[Casey Duncan]

gmane perhaps?

http://search.gmane.org/? 
query=twisted&author=&group=gmane.comp.python.pygame&sort=relevance&DEFA 
ULTOP=and&query=


-Casey

On Nov 21, 2007, at 7:48 AM, Laura Creighton wrote:



Anybody want to come explain twisted to somebody who just wants
to network his game?  Alas pygame-users is not a mailman mailing
list, and Activestate seems to have stopped archiving it in August,
so there is no way I know of to read the whole thread.


Laura

--- Forwarded Message

Return-Path: [EMAIL PROTECTED]
Delivery-Date: Wed Nov 21 14:37:43 2007
Return-Path: <[EMAIL PROTECTED]>
To: pygame-users@seul.org
Subject: Re: [pygame] Networking?
In-Reply-To:  
<[EMAIL PROTECTED]>

MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_Part_9402_16396364.1195651869700"


hey, please forgive me for any stupid observations.it's just
that I've been avoiding testing Twisted because people seem
to be of the opinion that it takes over the main loop. And they
like having control over that.

Can the main reactor be manipulated in such a way that it is
not the main loop?



--- End of Forwarded Message

Re: [pygame] This showed up in pygame-users@seul.org

[Marius Gedminas]

On Wed, Nov 21, 2007 at 04:48:20PM +0100, Laura Creighton wrote:
> Anybody want to come explain twisted to somebody who just wants
> to network his game?  Alas pygame-users is not a mailman mailing
> list, and Activestate seems to have stopped archiving it in August,
> so there is no way I know of to read the whole thread.

I've seen a couple of blog posts about integrating PyGame with twisted's
main loop.  Here's one:

  http://bob.pythonmac.org/archives/2005/04/17/twisted-and-foreign-event-loops/

And here's some source code for a VNC viewer that's built with twisted
and pygame: http://homepage.hispeed.ch/py430/python/

Marius Gedminas
-- 
A real friend isn't someone you use once and then throw away.
A real friend is someone you can use over and over again.


signature.asc
Description: Digital signature

[pygame] This showed up in pygame-users@seul.org

[Laura Creighton]

Anybody want to come explain twisted to somebody who just wants
to network his game?  Alas pygame-users is not a mailman mailing
list, and Activestate seems to have stopped archiving it in August,
so there is no way I know of to read the whole thread.


Laura

--- Forwarded Message

Return-Path: [EMAIL PROTECTED]
Delivery-Date: Wed Nov 21 14:37:43 2007
Return-Path: <[EMAIL PROTECTED]>
To: pygame-users@seul.org
Subject: Re: [pygame] Networking?
In-Reply-To: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
boundary="=_Part_9402_16396364.1195651869700"


hey, please forgive me for any stupid observations.it's just
that I've been avoiding testing Twisted because people seem
to be of the opinion that it takes over the main loop. And they
like having control over that.

Can the main reactor be manipulated in such a way that it is
not the main loop?



--- End of Forwarded Message

[pygame] Split screen question (newbie)

[Mundial 82]

Hi all,

ok, so I am a bit of a newbie and I am trying to make a split screen  
game. The idea is very simple: screen divided in halves, top and  
bottom spaces are wrapped, and not connected at all (think two  
different spaces). It would be great if the two sides could have  
different backgrounds.
I have no clue how to due this,  so any help is very welcome. I guess  
my level is pretty low: I can make asteroids and spacewar kind of games.


Thanks a lot in advance!

Naranjito

Re: [pygame] Networking?

[David]

On 11/21/07, Chris Ashurst <[EMAIL PROTECTED]> wrote:
> I hope you mean that the sockets library is not the place to start, simply
> because it's not immediately easy (unlike Twisted) to get right into? I
> believe every programmer who wants to use a higher-level library should at
> least have a stab at the low-level stuff, just to give a better idea of
> what's going on behind the automagical scenese of things like Twisted

What I meant is that to accomplish something usefull using the sockets
library, you have to build higher level systems, and you end up
reinventing asyncore or Twisted.   Reinventing sucks.

> Rather than haul in Twisted, a little research on the Python select module
> could be the very thing people are looking for - all without having any
> extra dependencies/includes other than the core Python library and Pygame.

To each their own, but I consider additional pure-python dependencies
to be a non-issue.  If including an extra 100K of library code saves
me a couple hours of work, I am all for it.   Non-pure-python
dependencies are an issue, because they may not build on the users
machine.

> http://www.amk.ca/python/howto/sockets/
>  - the Non-blocking Sockets
> section is particularly enlightening

This is actually the document I would refer people to, to scare them
away from socket programming. ;)

Quotes:

 # This is a 10,000 foot overview of sockets. It's not really a
tutorial - you'll still have
 # work to do in getting things operational. It doesn't cover the fine
points (and there
 # are a lot of them), but I hope ...

 # There's no question that the fastest sockets code uses non-blocking sockets
 #  and select to multiplex them. ... The trouble is that an  app
written this way
 #  can't do much of anything else - it needs to be ready to shuffle
bytes around at
 # all times.

That document was written in the mid 1990's, and the state of
networking in Python has advanced since then.

As a matter of context, this is a Pygame mailing list, and presumably
list-members are interested in getting their game complete and robust.
 A networking library is just a tool to getting the cool game-state
from this server to that client (and client events back to the
server), not a contributer to game-state coolness.  No disrespect to
socket-twiddlers, and I get the impression the original poster may be
one himself, but many on the list are interested in easy toolkits to
just "get 'er done".

David

-- 
[EMAIL PROTECTED]
Pitcher's Duel -> pitchersduel.python-hosting.com

RE: [pygame] Networking?

[Chris Ashurst]

I hope you mean that the sockets library is not the place to start, simply
because it's not immediately easy (unlike Twisted) to get right into? I
believe every programmer who wants to use a higher-level library should at
least have a stab at the low-level stuff, just to give a better idea of
what's going on behind the automagical scenese of things like Twisted
 
Rather than haul in Twisted, a little research on the Python select module
could be the very thing people are looking for - all without having any
extra dependencies/includes other than the core Python library and Pygame.
 
http://www.amk.ca/python/howto/sockets/
 - the Non-blocking Sockets
section is particularly enlightening
 
If potential socketeers out there are worried about things like byte-order
and so on, remember that the IRC protocol is 100% ASCII-based, and whilst it
may have its problems here and there, for the most part it's one of the
oldest, reliable protocols available (and great to learn from).
 
---
 
The python sockets library is probably *not* the place to start.  It is very
primitive,
and most references you will read will recommend using a  higher level
library such as
asyncore or (higher yet) asynchat.  Unfortunately, these higher level
libraries share the 
same weakness as Twisted, in that that they expect to own the main loop.
 
---
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of David
Sent: Tuesday, November 20, 2007 09:44
To: pygame-users@seul.org
Subject: Re: [pygame] Networking?


 
The python sockets library is probably *not* the place to start.  It is very
primitive,
and most references you will read will recommend using a  higher level
library such as
asyncore or (higher yet) asynchat.  Unfortunately, these higher level
libraries share the 
same weakness as Twisted, in that that they expect to own the main loop.
 
I have identified five general approaches to integrating networking with a 
pygame application.  I have not fully implemented a game with any of them,
.. but soon.
 
1)  Use Twisted with reactor.iterate .  This is the easiest approach, and
the one that 
Mr Wittber's library uses.  Use of reactor.iterate is unfortunately
deprecated by the Twisted 
developers, and will, presumably, be removed from Twisted in some future
release.
 
2) Use the Twisted reactor *as* your main loop, and implement all game logic
as call-backs from 
there.  This is the approach that the Twisted people will recommend.   This
approach
is quite burdensome, in that structuring your game into a series of
callbacks can be difficult.  Using
generators as coroutines provides some relief, in that you can pass the
generators 'next' method 
as a callback to Twisted, and maintain game state within the generator.
Using subroutines or 
nested generators involve their own awkwardnesses.
 
3) Run the Twisted reactor in its own thread, and use ThreadedSelectReactor
to move 
data to the pygame event queue.  Bob Ippolito has blogged on how to use this
with Pygame (GIYF).
Unfortunately, ThreadedSelectReactor is unmaintained and deprecated.
 
4)  Run the Twisted reactor in its own thread, and use thread-safe queues to
move data 
to and from the main thread.  Alternatively, if you wish to use the
perspective-broker 
features or use Twisted code beyond mere message passing, there are tools in
Twisted for
safely invoking methods in other threads.  Hmm. maybe these were deprecated
with the TSR?
 
5)  Run the Twisted reactor in its own process, and use pipes or sockets to
pass data between
it and the main loop/process.  This has the merit of using the OS's CPU
allocation management 
rather than that of Python's thread manager.
 
Most of these approaches could use asyncore/asynchat as an alternative to
Twisted.
 
My own efforts lately have been along approaches 2 and 5.   My engine
'Spyre' will run under 
Twisted's reactor now, but the getting the whole multi-engine game logic
sequence working in 
the 'inside-out' callback style is an imposing prospect.  
 
Philip Hassey has recently released a networked pygame-based game.  Has he
mentioned what 
networking approach he used?
 
David
 
On 11/19/07, Jason Ward < [EMAIL PROTECTED]  >
wrote: 

I want to make my game playable over the network and if possible the
internet.
For the network it must support more than 2 computers and be realtime
Would the sockets library in python solve all my needs?




-- 
[EMAIL PROTECTED]  
Pitcher's Duel -> pitchersduel.python-hosting.com
  





CONFIDENTIAL NOTICE: This email including any attachments, contains 
confidential information belonging to the sender. It may also be 
privileged or otherwise protected by work product immunity or other 
legal rules. This information is intended only for the use of the 
individual or entity named above.  If you are not the intended 
recipient, you are hereby noti

Re: [pygame] Networking?

[AlgoMantra]

hey, please forgive me for any stupid observations.it's just
that I've been avoiding testing Twisted because people seem
to be of the opinion that it takes over the main loop. And they
like having control over that.

Can the main reactor be manipulated in such a way that it is
not the main loop?

Re: [pygame] Networking?

[David]

On 11/20/07, Richard Jones <[EMAIL PROTECTED]> wrote:
>
> > 2) Use the Twisted reactor *as* your main loop, and implement all game
> > logic as call-backs from there. This is the approach that the Twisted
> > people will recommend.
>
> This is also useless for highly interactive games.


I consider my game highly interactive, though the network traffic intensity
is not very high.  Can you elaborate
on why the Twisted reactor is useless?


>  3) Run the Twisted reactor in its own thread
>
> This is probably the only reasonable approach for games.


My only experience with threads was in writing an image slideshow program.
The graphic blends
and transitions were very jerky with threads.  Changing to a
generator-coroutine approach worked more
smoothly.   I do not recall any capability in the thread modules for
adjusting 'niceness' or state-change frequency.



> > 5)  Run the Twisted reactor in its own process, and use pipes or sockets
> to
> > pass data between
> > it and the main loop/process.  This has the merit of using the OS's CPU
> > allocation management
> > rather than that of Python's thread manager.
>
> Quite difficult to manage on Windows.


Windows is my development platform.  I'll let you know how it works out. ;)

Richard
>
Thanks for the input.


-- 
[EMAIL PROTECTED]
Pitcher's Duel -> pitchersduel.python-hosting.com

Re: [pygame] Networking?

[Michael Sparks]

On Wednesday 21 November 2007 06:51:38 Jason Ward wrote:
> Thanks for the options guys. I'll look into them when I find the time. But I
> don't mind low-level stuff if that's what sockets library requires, just as
> long as it can work.

Sure of course it'll work. The code is pretty much the same as you'd find for 
C based code. We're just trying to save you hassle :-)  If you enjoy it 
though, go for it :-)

> I looked into twisted but it's documentation is rather difficult and I hate 
> libraries that want the main loop, I prefer the control.

FWIW, Kamaelia differs from twisted in that, aside from network systems not
being its sole focus, in that it recognises that systems like games, network
servers and most interactive systems tend to need multiple threads of control
and focusses on making that simpler & clearer to work with as well as
composable. (networking was the first use case, but was never intended to
be the sole focus)

As a result _you_ create a component for each logical thread of control.
Performance wise this can be pretty similar to hardcoding it yourself (the
difference is around 5% last time I measured), but the benefit you get is
more explicit control over the main loop for each thing, with a built in way
of allowing communication between the main loops.

You can use threads to do this:

class ConsoleReader(Axon.ThreadedComponent.threadedcomponent):
   def main(self):
      while 1:
          X = raw_input(">>> ")
          self.send(X, "outbox")

class ConsoleEchoer(Axon.ThreadedComponent.threadedcomponent):
   def main(self):
      while 1:
          while self.dataReady("inbox"):
               X = self.recv("inbox")
               print X

And then join the dots between them:

Pipeline(
    ConsoleReader(),
    ConsoleEchoer(),
).run()

Or make the components run in the same thread as all the others by changing to 
a generator:

class ConsoleEchoer(Axon.Component.component):
   def main(self):
      while 1:
          while self.dataReady("inbox"):
               X = self.recv("inbox")
               print X
          yield 1

But either way, it allows you to have as many main loops *you* want in a piece 
of code that make sense in a relatively natural & scalable way. (Generator 
components are pretty much equivalent to state machines intermediate buffers, 
just somewhat more direct)

You don't have to use Kamaelia's networking or pygame components for it to
be useful, but if you're thinking "I need to do more than one thing at once,
maybe I should use threads", take a look. Kamaelia can't magically solve your 
problems of course, so this just a suggestion.

Unlike some systems, the core of Kamaelia isn't really the components
(which are IMO the useful bit), but really just a core concurrency framework -
Axon - which builds the support that enables the above. We've got a simple
tutorial that's targetted to explain the approach here where you build your
own core:
   http://kamaelia.sourceforge.net/MiniAxon/

And you can happily build systems using such a beast. Indeed, the first pygame 
components we had came from someone's mini-axon system.

I love pygame, but these days I'd never use it by itself :-)
(Even if Kamaelia isn't really quite the same model as pygame :-)

If you do go down the route of coding your own networking though, I'm sure 
others would find your ideas/approach interesting :-)

The networked pong example was a 20-30 minute hack BTW from start
to finish. I'm now MASSIVELY off topic though, so I'll stop there :-)


Michael.