holomaze.c is a reimplementation in GLX, as a rudimentary platformer,
of a maze I built years ago on a mud.

It has not been tested extensively, and almost not at all on systems
other than my own; it likely has issues.  I'll be happy to discuss it
and offer help, to the extent I can, to people having trouble with it,
either building or running.

To build it, compile six .c files (2darith.c, 3darith.c, findvis.c,
holomaze.c, mathutils.c, and rectregion.c) with -I. and whatever
options are necessary to find your X and GLX include files.  Then link
them together with whatever options are necessary to find your X, GLX,
and math libraries; the Makefile can give you some idea what options I
use.  The Makefile is unlikely to work out of the box for you, since it
is a BSD Makefile and uses an include template - <local-prog> - which
isn't part of this repo.  If you are on Linux, check out the linux
branch to get a Makefile which is, at least in my tests,
GNU-make-compatible; it might work for you.  (If you're reading my
Makefile, do not be misled into thinking you want -DDC_CTLR; unless you
have a Dreamcast on your network running my controller export software,
that is of no direct use to you.  If you want to look into that for
some reason, clone my Mouse/dreamcast repo and look at rem.s and
ctlrwatch.c.)

Somewhere in the maze there is a big yellow disc on the floor.  Find
that and touch it and you've won - to the extent that winning is a
concept that makes sense, at least.  It is more complicated than just
threading a maze; there are moving parts, if naught else, and you
cannot reach the goal without using the moving parts (or using cheats;
see below).

The game grabs (in the X sense) your keyboard.  Unless the game has
wedged so badly it isn't listening to keystrokes at all, shift-Q will
always exit.  To move around, W and S move forward and back and A and D
strafe left and right; U and I rotate the camera left and right.  Shift
makes you move faster; Control, slower.  If something goes wrong, such
as you find yourself outside the maze hanging in black space, shift-T
will write a file called "holomaze.trail" (in the directory you started
the game in) containing a bunch of information that should help me
debug the issue.  This file will be big - a little under 20 megs - but
it should compress well; in a test I just did, bzip2 compressed one
example to a little over 100K.

There are numerous other commands you can type, but they are designed
for developer support and most of them would normally be considered
cheats (for example, there is one which teleports you to right next to
the yellow goal disc), so I'm not documenting them.  Those who want can
dig them out of the source code, of course.

There is a "secret room".  Finding it is in no way harmful and might be
marginally helpful; I added it as a developer support feature and
decided to leave it in.  You'll know when you've found it because it's
the only room with non-square corners.  (It's distinctive in other
ways, too, but that's the only way that comes to mind that's not even
the least bit spoilerish.)

There are three command-line options:

	-seed N
		The game uses random numbers in a few minor ways; this
		option controls the RNG's seed.  Setting a seed of 0
		gets the default behaviour, which is to seed it with
		the current time.  It is unlikely you will be able to
		see much difference based on the seed; the RNG is not
		used for much.

	-nograb
		Suppresses the keyboard grab.  This is useful mostly
		for doing development under the same server as testing,
		when working on code that can lead the game to wedge
		without listening to the keyboard.

	-kbv
		Turns on verbosity in the keyboard input code.  This is
		a debugging option, not expected to be useful for other
		purposes.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse@rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B