Re: [pygame] Pygame-Fenix - Using generators as game objects

["Dan Krol" <orblivion@xxxxxxxxx>]

This is something I've thought of as well, but slightly differently.
It started with me working on a game framework where your "guy" would
have an __init__ for loading the images, and a FrameAction that gets
called by the game loop. The game loop of the framework would handle
all of the callbacks.

The purpose of the framework, largely, is to simplify things for
people that want to be "game scriptors" but aren't comfortable enough
with programming to make a whole game. So it occurred to me, one way
to possibly make it easier is to use generators. One arrangement would
be the loop that you described, but not necessarily have just one
loop. A simple example is when a non-player object would have a looped
sequence of events, each taking a certain amount of frames. The "old"
way of doing it would be:

 def begin(self):
   state = 0
   statecounter = 0
    while True:
        if state == 0:
            #state 0 stuff
            if statecounter == 5:
                state = 1
                statecounter = -1

        elif state == 1:
            #state 1 stuff
            if statecounter == 3:
                state = 2
                statecounter = -1

        elif state == 2:
            #state 2 stuff
            if statecounter == 7:
                state = 0
                statecounter = -1

        statecounter += 1
        yield

The way I would do it is this:

 def begin(self):
    while True:
        for x in range(0,5):
           #state 0 stuff
           yield
        for x in range(0,3):
           #state 1 stuff
           yield
        for x in range(0,7):
           #state 2 stuff
           yield


You could also have conditionals that take input that direct it in
different control paths. The point here being, instead of worrying
about using state variables, you could use your location in the loop
as your state. It can make you think of it a lot more as one script,
instead of having to think about it in terms of frames and states.

Just thought I'd share that; it doesn't look like it would require any
changes to Pygame-Fenix, just a new way of using it.

Dan

On Mon, Dec 1, 2008 at 9:54 AM, Fiona Burrows <fiona@xxxxxxxxxxxxxxxxxxx> wrote:
> Hi all,
> years ago I used to use a tool to make games called DIV Games Studio, when
> it eventually died I started using it's successor called Fenix. The language
> that you used to make games was/is an odd mix of C and Pascal. However they
> had a novel way of creating and handling game objects.
>
> Basically everything in the game is a "Process", processes are basically
> objects that run from start to finish, have screen coordinaties, z-depth, a
> size, an angle, and a graphic among other things.
>
> You could define a process like this:
>
> process guy(x, y)
>   begin
>     graph = load_png("test.png");
>     loop
>       frame;
>     end
>   end
> end
>
> Everytime your program calls a guy, like you would a function, a new object
> is created in world independent of everything else.
>
> The code for the guy starts at begin, and then gets destroyed when it hits
> the end. loop creates an infinite loop. The interesting part of how it all
> works is the frame; statement.
> When it hits frame, it jumps out of the loop and stops executing till the
> next frame.
>
> There's also routines for distance checking and collision detection between
> objects. In addition to the aformentioned settings that each process can
> have it was all very easy to do simple to moderately complex games.
>
> Basically DIV/Fenix made me retarded when it came to making games. In other
> languages it just seemed I had to do so much to achieve what Fenix gave me
> for free. When I started writing Python I found I loved it, and hated
> Fenix's syntax and it's constant bugs.
>
> So I decided to emulate Fenix in Python/Pygame.
>
> The result (thus far) is fenix-pygame:
> http://code.google.com/p/pygame-fenix/
> I found that I can emulate the way the frame; statement works completely by
> using generators instead.
> The example code on the front page shows a program that displays an object
> which has a graphic assigned to it and moves around the screen with the
> arrow keys. When the code hits yield it jumps out of the function till the
> next frame. There are a few other simple examples showing process
> interaction in the repo.
>
> I'm not sure if anyone else has used generators for game objects, but it's
> always seemed so natural to me and I certainly can't stop thinking in
> "processes" when I write games.
>
> The library is certainly not perfect, there's next to no optimisation done
> especially in display routines so don't expect anything fast. But the
> concept is there.
> I'm going to continue improving it for my own endeavours and will be using
> it for Ludum Dare this weekend.
>
> Hope someone finds it interesting or useful.
>
> Thanks,
> Fiona
> --
> Sputnik Internet ¤
> Web & Graphic Design, Marketing & Illustration
> 30 King Street
> Manchester
> M2 6AZ
>
> Tel 0870 742 5959
> E-mail: fiona@xxxxxxxxxxxxxxxxxxx
> Web: http://www.sputnikinternet.com
>
>