[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] Pygame-Fenix - Using generators as game objects
On Monday 01 December 2008 17:05:58 Fiona Burrows wrote:
> Thank you! I knew there would be a term for it. :)
> Those libraries seem interesting - especially Dramatis. But neither of
> them seem as well suited for games as mine as I have lots of
> game-specific things like collision detection going on.
Also Kamaelia does these things btw.
Kamaelia is actor-like, but not actor model. The difference is primarily that
in Kamaelia when you send you send to an outbox, not to someone else's
inbox. Something higher up then resolves outbox-inboxes for you. (This is made
performance friendly by some internal optimisations, meaning that delivery to
an outbox immediately delivers to the correct inbox).
This leads to stuff like:
Pipeline(
MyGamesEventsComponent(up="p", down="l", left="a", right="s"),
BasicSprite("cat.png", name = "cat", border=40),
).activate()
Since you can join the output from one thing to the input from the other.
(Other shapes other than pipeline are available)
More detail on differences:
http://yeoldeclue.com/cgi-bin/blog/blog.cgi?rm=viewpost&nodeid=1226893221
http://lambda-the-ultimate.org/node/3108#comment-45328
Fundamentally though, kamaelia's model is more like hardware or unix pipes,
the actor model is a bit like UDP.
See also the first major example here:
http://www.slideshare.net/kamaelian/practical-concurrent-systems-made-simple-using-kamaelia-presentation
(Ok, there's a preamble - skip forward to about slide 55)
Incidentally, Kamaelia defaults to using generators (though you can use
threads and processes), and what you've written here:
> process guy(x, y)
> begin
> graph = load_png("test.png");
> loop
> frame;
> end
> end
> end
Essentially matches what we do. For a comparison of the difference between a
normal bit of pygame code and a pygame component, you can follow the sequence
of changes here:
http://code.google.com/p/kamaelia/source/browse/trunk/Sketches/MPS/WebCam.py
Lines 18 - 48 are a normal usage of pygame / pygame camera module code.
Lines 51 - 81 are the minimal transformation to a threaded based component
(but one that doesn't play nicely with others)
Lines 83 - 104 splits out just the capture to a component and
Lines 109 - 127 is a surface displayer. This is a minimal change version
really from 51-81 so it doesn't play nicely with others.
That's then changed to something that does in lines 132-167. You'll note its
main method looks like this: (couple of minor cleanups actually - that is
scratch/sketch code :-)
def main(self):
yield Axon.Ipc.WaitComplete(self.getDisplay())
while 1:
for snapshort in self.Inbox("inbox"):
self.display.blit(snapshot, (0,0))
self.pygame_display_flip()
while not self.anyReady():
self.pause()
yield 1
yield 1
Which aside form a few oddities probably doesn't look *too* strange really.
There's more evolution further on through the file, but you should be able to
see the logic really - get the thing working normally, then replace calls
regarding getting a surface with something else, and replace the pygame
display flip call with something else (if the surface is dirty).
There's a bunch of pygame specific components, played with the (hopefully soon
to be released since it's cool) pygame video support, and some stuff aimed at
simple games for kids. Most of our pygame stuff has actually revolved around
playing interfaces. (eg there's a physics model based topology visualiser for
example :) )
For example, this is an example chat server with pygame based clients:
http://yeoldeclue.com/cgi-bin/blog/blog.cgi?rm=viewpost&nodeid=1226574014
Oh, the pygame components can also sit happily on Open GL surfaces in case
that's of interest :)
Michael.
--
http://yeoldeclue.com/blog
http://twitter.com/kamaelian
http://www.kamaelia.org/GetKamaelia
http://www.kamaelia.org/Cookbook