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