Re: SLAYER announcement and help request for preparing a GNU package

[John Darrington]

It sounds like an interesting project.

The subject line of your post says it is a "GNU Package", but I don't see 
slayer in
the official list.  Perhaps you mean it is one that you want to submit to
GNU in the hope that they will adopt it as a package? Or did you mean something
else? Obviously how to it should be laid out will depend on that a lot.

Like you say, lack of documentation is will be a big factor in getting users.
How will people know how to use it, and perhaps more importantly WHY the should
use it?

Autotools can indeed be tricky - and a time consuming part of maintaining a
package - but they do make it a hell of a lot easier for the general public
to build, especially on wierd systems.

Lack of features is a concern - but if you have a dedicated user base, even a 
small
one, you will get requests for them.  However, if you don't have decent 
documentation,
and a reliable and portable build system, then you won't have any users ....


J'


On Sat, May 04, 2013 at 11:54:44PM +0200, Panicz Maciej Godek wrote:
     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:
     
     hg clone https://bitbucket.org/panicz/slayer
     
     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.

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://keys.gnupg.net or any PGP keyserver for public key.

signature.asc
Description: Digital signature