Re: Guile Game Library

[Panicz Maciej Godek]

2013/5/29 David Thompson <address@hidden>

Hello all,

In my free time I like to tinker with game development, and I also like to tinker with Guile.
I come from a Python background where I used such libraries as Pyglet and Pygame.
These libraries were easy to use and had all the conveniences for making 2D games (Pyglet sports a full GL binding for doing more advanced stuff as well).
I haven't found a similar library for Guile. Is there one that I haven't discovered?

Actually, I've been trying to develop a game in guile, and on my way I coined the SLAYER environment, which can be obtained via mercurial:

$ hg clone https://bitbucket.org/panicz/slayer

$ cd slayer

Provided that you have all the packages listed in the DEPENDENCIES file, it should get built using

$ make

However, you may wish to switch to "autotools" branch, which contains some more recent changes and more informative demos:

$ hg up autotools

$ ./configure

and

$ make

(I wouldn't recommend to 'make install' yet though, as there are still some issues that need to be resolved)

If you manage to go through this somewhat cumbersome build process, you can try out the demos, by entering the demos directory and typing

$ ./slayer -e3d -islayer.scm

and

$ ./slayer -ipong.scm

There's also a possibility to build a library that wraps the Open Dynamics Engine, and there's a corresponding demo which shows its capabilities (like everything in SLAYER, this isn't just a simple wrapper on the C functions, but rather an interface which simplifies the development)

If there isn't, one should be made. Pygame is a fun treat for new Python programmers, and I think a similar library for Guile would be even more fun. :)
In the past I've tried to wrap the Allegro 5 library using the Guile C API, and also with the FFI. My experience doing so lead me to the conclusion that a game library developed completely in Guile, not just a mere wrapper, would ultimately be much more satisfying.

My vision of SLAYER is to make a self-contained development environment, so that it could have its own editors (for code, but also for 3d mesh, sound waves, rigs or video streams) -- so I believe that it could evolve towards something like emacs, but focused on multimedia

Now, how would this be achieved? I looked briefly at the source code of Pygame and Pyglet and learned the following:
Pygame uses the Python C API to wrap up a bunch of SDL calls. Since Pygame uses SDL, the graphics functions use a software renderer which isn't optimal.
Pyglet doesn't seem to use any C code and instead uses the FFI. Pyglet sports OpenGL, X11, and FreeType bindings to name a few. I personally prefer this development model over Pygame's.

I have no experience with any of those, so I cannot compare. SLAYER is based entirely on SDL and OpenGL (which is optional). It also wraps SDL_image, SDL_mixer for audio and SDL_ttf for FreeType fonts. Rendering can be done using either plain SDL or via OpenGL (which currently must be enabled using the "-e3d" command line option), and in the latter case no SDL routines are used for rendering.

What Guile libraries already exist that can provide needed functionality? (Windows, Graphics, Sound, Keyboard/mouse/joystick input, Fonts, Physics, etc.) 

What libraries would best suit this purpose? Figl (wingo's GL binding) is an obvious choice, as well as a Freetype binding (that I'm not sure exists). But what about the other important pieces such as sound and input?

Except SLAYER, guile-SDL provides support for all of the features you mentioned (except Physics). Its advantage is a much better documentation (SLAYER currently offers none), easier build process and a larger set of demos.

Also, SLAYER has no joystick support (it could be added easily, but I wouldn't have any option to test it).

However, the advantage of SLAYER is that it's something more than just a wrapper: it is an abstraction layer, which could be implemented in many other environments. It offers an event-driven input model, so the programmer doesn't have to write his own input loop. Furthermore, it provides a GOOPS-based framework for widgets.

I recommend you to look at the source of the demos to see how it works, and if you have any questions, I'm eager to help. Maybe the overall process could help come up with some documentation.

Best regards,

M.