Hi everyone,
I've developed a piece of software that I named SLAYER, by combining the letter 's' with the word "layer", or replacing the 'p' letter with 's' in the word 'player'.
Either way, slayer can be thought of as a simpler alternative for wrapper libraries such as guile-sdl and guile-opengl, or as a programming environment that is in a way competetive to Adobe Flash (with standalone player). But obviously, it is something completely different.
I made this program as a base for research in GUI design, but it also contains a stub of a 3d game engine that I'm planning to implement -- which explains native support for OpenGL. I recently thought that it also could be a great platform for teaching kids to program games, because -- once compiled and linked -- it could be distributed as a standalone package, that requires no additional tools.
The program is available through mercurial on bitbucket:
The repository contains README file, which lists packages that are needed to build. Except a little mess, there are two demos that show the possibilities of the system. The first one with the command:
$ ./slayer -e3d
The -e3d option is needed to enable the "3d" extension, which is required by the demo. It allows to move around in a 3d space using mouse and WSAD keys. There's also a draggable icon and a simple text-console, which accepts s-expressions (evaluated using f1 key). It is activated with a click, but for some reason the cursor isn't always displayed. The source file is slayer.scm.
The second demo is the classical arcade PONG game (for two players). It's written in the raw guile+slayer, so it's pretty lengthy (~160 lines), but it should be easily understandable. PONG can be run using
$ ./slayer -i pong.scm
Both demos use sound, which can be disabled by passing the --nosound option in the command line. PONG can also receive the -e3d option, which would force it to use opengl for display.
Other command line options are undocumented, but they can be easily found in slayer.c. I admit that the lack of any documentation can now be the most seriously discouraging factor, but I promise to respond to every question eagerly.
The second most seriously discouraging factor would be the build process, which could require manual editing of the Makefile, among others. It would be lovely to use the GNU autotools, but they seem so complicated, and I thought that since you might have more experience with those, you could help me to prepare a decent release, and perhaps to reorganize the structure of the source code.
Perhaps the third most seriously discouraging factor (except some random crashes that still happen) would be the lack of certain features: I'm trying to apply the 'lazy implementation' strategy and add SDL/OpenGL features only as I need them, and also my priority is to keep interfaces simple, even at the cost of programmer's freedom (so for instance, there's no option for choosing color index mode in OpenGL, or some other SDL video mode than the default).
Despite those factors, I'd be happy to hear some feedback from you.
Best regards,
M.