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
