ftp.nice.ch/pub/next/games/network/MazeWar.s.tar.gz

Makefile
 
Makefile.orig
 
MazeWar.iconheader
 
NeXT-Release-Notes
 
README
 
bitmaps/
 
display.c
[View display.c] 
init.c
[View init.c] 
mazefind.6
 
mazefind.c
[View mazefind.c] 
mazewar.6
 
mazewar.c
[View mazewar.c] 
mazewar.h
[View mazewar.h] 
winNeXT.h
[View winNeXT.h] 
winNeXT.m
[View winNeXT.m] 
winSunView.c
[View winSunView.c] 
winX10.c
[View winX10.c] 
winX11.c
[View winX11.c] 

README

This is Mazewar for UNIX. It is a direct descendant of the Mazewar
played at MIT and Xerox PARC, and boasts none of the embellishments found
in other such programs. It's basically just run, peek, and shoot; no robot
amenuenses, teleport traps, or other such fluff.

Basically, ASDF and space move you around, middle mouse shoots, left and
right mouse let you peek around corners. Type Q to quit. Lefties may use
the numeric pad instead of ASDF; on a DEC LK201 keyboard, the 456, row
serves for ASDF, and the right cursor arrow is equivalent to the space bar.
Q quits.

Games are normally begun by broadcasting to find members of a game; if
your system doesn't allow normal users to do broadcasts, you'll have to do
something like run it setuid root (or whomever) and change findDuke$init.c
to do a setuid(getuid()) after the broadcast. The code as distributed does a
broadcast to INADDR_BROADCAST (all 1s); your network might still be configured
to use INADDR_ANY (all 0s). The place to change this is in the declaration of
CFLAGS in the Makefile.

Also, the 4.3 setsockopt() call is pickier about its arguments when trying to
enable broadcasting.  Define BSD_43 in the Makefile to compile the appropriate
code for 4.3 and 4.3-derived systems.  The code that worked on 4.2 is still
available for systems that might not like the new arguments.

If you know you don't have broadcast ability and never will, define
NO_BROADCAST in the Makefile, and that code will be compiled out of init.c;
mazefind isn't touched, but it won't do anything useful. In this case, you must
specify a duke host (the name of any host currently in a game will do) or the
players won't be able to find each other. 

In each game there is one player who is designated the "duke" and manages
the joining and leaving of other players. When starting a game, if you
wish to join a specific game, especially one on a different net, you may
specify the name of the duke host, which will be contacted directly. This
has not been extensively tested. Games across long network delays might be
pretty strange...

If you enjoy this program and keep it, please send a picture post card to me:

Chris Kent
DEC Western Research Lab
100 Hamilton Avenue
Palo Alto, CA 94301

Include your ArpaNet or UUCP mailing address and I'll keep you informed 
of updates.

December, 1986

Bob Brown, Malcolm Slaney, and Mike Yang deserve a long round of applause for
having ported to new window systems.  We've tested it on a lot of
architectures, but byte- or bit-order bugs may still be lurking.  Note that
there is conditional code in the X11 driver to not use server-resident bitmaps
if your server doesn't do them right (this was designed for the QDSS).

Have fun,
chris

August, 1988

These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.