1: What *is* hunt? 2: 3: Hunt is a multi-player search-and-destroy game that takes place 4: in a maze. The game may either be slow and strategic or fast 5: and tactical, depending on how familiar the players are with the 6: keyboard commands. 7: 8: Distribution Policy: 9: 10: Hunt is part of the user-contributed software distributed by 11: Berkeley in 4BSD. The sources are copyrighted by the authors 12: and the University of California. You may redistribute freely 13: as long as the copyright notices are retained. 14: 15: Words of Warning: 16: 17: hunt uses the socket mechanism of 4BSD Unix, so if you are on 18: System V (my sympathies), you're on your own. 19: If your machine does not permit non-setuid-root processes to 20: broadcast UDP packets, then hunt uses a *very* inefficient 21: method for locating the hunt server: it sends a packet 22: to every host on your network. If your machine falls 23: into this category, we strongly recommend that you use 24: either standalone or inetd mode *and* start hunt by 25: specifying the hunt server host. 26: hunt can be configured to use Unix-domain sockets, but that 27: code has not been tested in recent memory. Also, since 28: 4.2BSD Unix-domain sockets are buggy, running hunt on 29: 4.2BSD with Unix-domain sockets will probably crash 30: your system. If you want to experiment, feel free to 31: do so. However, don't say I didn't warn you :-). 32: hunt uses a fair amount of CPU time, both in user time (for 33: computing interactions) and system time (for processing 34: terminal interrupts). We found that a VAX 750 can 35: support about three users before the system is 36: noticeably impacted. The number goes up to about 8 or 37: 10 for a VAX 8650. On a network of Sun 3/50's with the 38: server running on a 3/280, things work much more 39: smoothly as the computing load is distributed across 40: many machines. 41: hunt may be dangerous to your health. "Arthritic pain" and 42: "lack of circulation" in fingers have been reported by 43: hunt abusers. Hunt may also be addictive, and the 44: withdrawal symptoms are not pretty :-) 45: 46: Installation: 47: 48: 1. Edit file "Makefile" and make sure the options selected are 49: reasonable. There are four "make" variables that you 50: should check: GAME_PARAM, SYSCFLAGS, SYSLDFLAGS, and DEFS. 51: GAME_PARAM controls what features of the game will be 52: compiled in (e.g. reflecting walls). The optional features 53: are listed in comments above where GAME_PARAM is defined. 54: If you want to try them, just add the ones you want to the 55: GAME_PARAM definition. 56: 57: DEFS is where most system configuration is described. 58: If your system is 4.3BSD, Sun, Ultrix, Convex, HPUX 59: v6.0.1, or SGI, you're in luck. We provide the 60: appropriate definitions for these systems and you just 61: need to select one of them (e.g. if you have an Ultrix 62: system, just change the line 63: DEFS= $(GAME_PARAM) $(DEFS_43) 64: to 65: DEFS= $(GAME_PARAM) $(DEFS_ULTRIX) 66: ). If your system is *not* listed above, then you may 67: need to do some experiments. All of the options are 68: documented in the Makefile, be brave. 69: 70: SYSCFLAGS and SYSLDFLAGS are used for "unusual" systems 71: and you probably won't need to deal with it. An 72: example of an unusual system is the Silicon Graphics 73: IRIS, which keeps the network socket code in a BSD 74: emulation library that is in -lbsd. Edit these only if 75: you *know* your system is "different." 76: 77: 2. Edit file "Makefile" and look at the "install:" target. By 78: default, files are installed in /usr/games, 79: /usr/games/lib, and /usr/man/man6, which are "standard" 80: locations for games. If your system has a local games 81: directory, you'll need to change these. 82: 3. Edit file "pathname.c" and make sure the file names and port 83: numbers are reasonable. You can ignore the first set 84: of variables as they are used only for debugging 85: purposes. The second set is used in the installed 86: version of hunt. The important variables are "Driver" 87: (where the server is kept), "Test_port" (the Internet 88: UDP port number that new players should use to contact 89: the server), and "Stat_file" (where scoring statistics 90: and body counts are written). The only tricky variable 91: here is "Test_port". The default value is chosen so 92: that it is unlikely to conflict with other service port 93: numbers, but you can change it if you want to. 94: 4. Type "make install", which will compile and install the 95: programs and manual pages. Now you're almost ready to 96: go (see next section). There may be some warnings during 97: compilation. Ignore them. 98: 99: Setting up the network: 100: 101: Hunt may be set up in one of three modes: standalone, inetd, or 102: nothing. In "standalone" mode, there is always a hunt server 103: running on a server machine. All players who enter the game 104: will be talking to this server. This is the mode we use at 105: UCSF. The cost is one entry in the process table on the server 106: machine. In "inetd" mode, the server is started via inetd. 107: Again, only one machine should be set up to answer game 108: requests. The cost is having to edit a few system files. In 109: "nothing" mode, no server is running when there is no one 110: playing. The first person to enter hunt will automatically 111: start up a server on his machine. This, of course, gives him 112: an unfair advantage. Also, there may be race conditions such 113: that players end up in different games. The choice of which 114: mode to use depends on site configuration and politics. We 115: recommend using "standalone" mode because it is simple to set 116: up and starts up rapidly. 117: 118: ----- 119: 120: FOR STANDALONE MODE, put these lines in /etc/rc.local on the 121: server machine. THERE SHOULD ONLY BE ONE SERVER MACHINE! 122: 123: # start up the hunt daemon if present 124: if [ -f /usr/games/lib/huntd ]; then 125: /usr/games/lib/huntd -s & (echo -n ' huntd') >/dev/console 126: fi 127: 128: Also, you should start one up (on the off chance that you will 129: want to test this mess :-) by typing "/usr/games/lib/hunt -s". 130: 131: ----- 132: 133: FOR INETD MODE, then things get more complicated. You need to 134: edit both /etc/services and /etc/inetd.conf. In /etc/services, 135: add the line 136: 137: hunt 26740/udp 138: 139: 26740 corresponds to the default "Test_port". If you changed 140: that variable, then you should put whatever value you used here 141: as well. In /etc/inetd.conf, add the line 142: 143: hunt dgram udp wait nobody /usr/games/lib/huntd huntd 144: 145: This works for 4.3BSD. I don't remember the configuration file 146: format for 4.2BSD inetd. 147: 148: See the huntd.6 manual page for more details. 149: 150: ----- 151: 152: FOR NOTHING MODE, do nothing. 153: 154: Testing: 155: Now you are ready to test the code. Type "/usr/games/hunt" or 156: whatever you call the hunt executable. You should be prompted 157: for your name and team. Then you should get the display of a 158: maze. At this point, you should read the manual page :-). 159: 160: ====== 161: 162: Hunt is not officially supported by anyone anywhere (that I know of); 163: however, bug reports will be read and bug fixes/enhancements may be 164: sent out at irregular intervals. Send no flames, just money. Happy 165: hunting. 166: 167: Conrad Huang 168: conrad@cgl.ucsf.edu 169: Greg Couch 170: gregc@cgl.ucsf.edu 171: October 17, 1988 172: 173: P.S. The authors of the game want to emphasize that this version of hunt 174: was started over eight years ago, and the programming style exhibited here 175: in no way reflects the current programming practices of the authors.