|
|
1.1 root 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: [email protected]
169: Greg Couch
170: [email protected]
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.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.