README
1What *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
8Distribution 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
15Words 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
46Installation:
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
99Setting 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
154Testing:
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
162Hunt is not officially supported by anyone anywhere (that I know of);
163however, bug reports will be read and bug fixes/enhancements may be
164sent out at irregular intervals. Send no flames, just money. Happy
165hunting.
166
167 Conrad Huang
168 conrad@cgl.ucsf.edu
169 Greg Couch
170 gregc@cgl.ucsf.edu
171 October 17, 1988
172
173P.S. The authors of the game want to emphasize that this version of hunt
174was started over eight years ago, and the programming style exhibited here
175in no way reflects the current programming practices of the authors.
176
README.protocol
1
2THE HUNT PROTOCOL
3=================
4
5These are some notes on the traditional INET protocol between hunt(6) and
6huntd(6) as divined from the source code.
7
8(In the original hunt, AF_UNIX sockets were used, but they are not
9considered here.)
10
11The game of hunt is played with one server and several clients. The clients
12act as dumb 'graphics' clients in that they mostly only ever relay the
13user's keystrokes to the server, and the server usually only ever sends
14screen-drawing commands to the client. ie, the server does all the work.
15
16The game server (huntd) listens on three different network ports which
17I'll refer to as W, S and P, described as follows:
18
19 W well known UDP port (26740, or 'udp/hunt' in netdb)
20 S statistics TCP port
21 P game play TCP port
22
23The protocol on each port is different and are described separately in
24the following sections.
25
26Lines starting with "C:" and "S:" will indicate messages sent from the
27client (hunt) or server (huntd) respectively.
28
29W - well known port
30-------------------
31 This server port is used only to query simple information about the
32 game such as the port numbers of the other two ports (S and P),
33 and to find out how many players are still in the game.
34
35 All datagrams sent to (and possibly from) this UDP port consist of
36 a single unsigned 16-bit integer, encoded in network byte order.
37
38 Server response datagrams should be sent to the source address
39 of the client request datagrams.
40
41 It is not useful to run multiple hunt servers on the one host
42 interface, each of which perhaps listen to the well known port and
43 respond appropriately. This is because clients will not be able to
44 disambiguate which game is which.
45
46 It is reasonable (and expected) to have servers listen to a
47 broadcast or multicast network address and respond, since the
48 clients can extract a particular server's network address from
49 the reply packet's source field.
50
51 Player port request
52
53 A client requests the game play port P with the C_PLAYER message.
54 This is useful for clients broadcasting for any available games. eg:
55
56 C: {uint16: 0 (C_PLAYER)}
57 S: {uint16: P (TCP port number for the game play port)}
58
59 The TCP address of the game play port should be formed from the
60 transmitted port number and the source address as received by
61 the client.
62
63 Monitor port request
64
65 A client can request the game play port P with the C_MONITOR message.
66 However, the server will NOT reply if there are no players in
67 the game. This is useful for broadcasting for 'active' games. eg:
68
69 C: {uint16: 1 (C_MONITOR)}
70 S: {uint16: P (TCP port number for the game play port)}
71
72 Message port request
73
74 If the server receives the C_MESSAGE message it will
75 respond with the number of players currently in its game, unless
76 there are 0 players, in which case it remains silent. This
77 is used when a player wishes to send a text message to all other
78 players, but doesn't want to connect if the game is over. eg:
79
80 C: {uint16: 2 (C_MESSAGE)}
81 S: {uint16: n (positive number of players)}
82
83 Statistics port request
84
85 The server's statistics port is queried with the C_SCORES message.
86 eg:
87
88 C: {uint16: 3 (C_SCORES)}
89 S: {uint16: S (TCP port number for the statistics port)}
90
91
92S - statistics port
93-------------------
94 The statistics port accepts a TCP connection, and keeps
95 it alive for long enough to send a text stream to the client.
96 This text consists of the game statistics. Lines in the
97 text message are terminated with the \n (LF) character.
98
99 C: <connect>
100 S: <accept>
101 S: {char[]: lines of text, each terminated with <LF>}
102 S: <close>
103
104 The client is not to send any data to the server with this
105 connection.
106
107P - game play port
108------------------
109 This port provides the TCP channel for the main game play between
110 the client and the server.
111
112 All integers are unsigned, 32-bit and in network byte order.
113 All fixed sized octet strings are ASCII encoded, NUL terminated.
114
115 Initial connection
116
117 The initial setup protocol between the client and server is as follows.
118 The client sends some of its own details, and then the server replies
119 with the version number of the server (currently (uint32)-1).
120
121 C: <connect>
122 S: <accept>
123 C: {uint32: uid}
124 C: {char[20]: name}
125 C: {char[1]: team}
126 C: {uint32: 'enter status'}
127 C: {char[20]: ttyname}
128 C: {uint32: 'connect mode'}
129 S: {uint32: server version (-1)}
130
131 If the 'connect mode' is C_MESSAGE (2) then the server will wait
132 for a single packet (no longer than 1024 bytes) containing
133 a text message to be displayed to all players. (The message is not
134 nul-terminated.)
135
136 C: {char[]: client's witty message of abuse}
137 S: <close>
138
139 The only other valid 'connect mode's are C_MONITOR and C_PLAYER.
140 The server will attempt to allocate a slot for the client.
141 If allocation fails, the server will reply immediately with
142 "Too many monitors\n" or "Too many players\n', e.g.:
143
144 S: Too many players<LF>
145 S: <close>
146
147 The 'enter status' integer is one of the following:
148
149 1 (Q_CLOAK) the player wishes to enter cloaked
150 2 (Q_FLY) the player wishes to enter flying
151 3 (Q_SCAN) the player wishes to enter scanning
152
153 Any other value indicates that the player wishes to enter in
154 'normal' mode.
155
156 A team value of 32 (space character) means no team, otherwise
157 it is the ASCII value of a team's symbol.
158
159 On successful allocation, the server will immediately enter the
160 following phase of the protocol.
161
162 Game play protocol
163
164 The client provides a thin 'graphical' client to the server, and
165 only ever relays keystrokes typed by the user:
166
167 C: {char[]: user keystrokes}
168
169 Each character must be sent by the client as soon as it is typed.
170
171
172 The server only ever sends screen drawing commands to the client.
173 The server assumes the initial state of the client is a clear
174 80x24 screen with the cursor at the top left (position y=0, x=0)
175
176 Literal character 225 (ADDCH)
177
178 S: {uint8: 225} {uint8: c}
179
180 The client must draw the character with ASCII value c
181 at the cursor position, then advance the cursor to the right.
182 If the cursor goes past the rightmost column of the screen,
183 it wraps, moving to the first column of the next line down.
184 The cursor should never be advanced past the bottom row.
185
186 (ADDCH is provided as an escape prefix.)
187
188 Cursor motion 237 (MOVE)
189
190 S: {uint8: 237} {uint8: y} {uint8: x}
191
192 The client must move its cursor to the absolute screen
193 location y, x, where y=0 is the top of the screen and
194 x=0 is the left of the screen.
195
196 Refresh screen 242 (REFRESH)
197
198 S: {uint8: 242}
199
200 This indicates to the client that a burst of screen
201 drawing has ended. Typically the client will flush its
202 own drawing output so that the user can see the results.
203
204 Refreshing is the only time that the client must
205 ensure that the user can see the current screen. (This
206 is intended for use with curses' refresh() function.)
207
208 Clear to end of line 227 (CLRTOEOL)
209
210 S: {uint8: 227}
211
212 The client must replace all columns underneath and
213 to the right of the cursor (on the one row) with
214 space characters. The cursor must not move.
215
216 End game 229 (ENDWIN)
217
218 S: {uint8: 229} {uint8: 32}
219 S,C: <close>
220
221 S: {uint8: 229} {uint8: 236}
222 S,C: <close>
223
224 The client and server must immediately close the connection.
225 The client should also refresh the screen.
226 If the second octet is 236 (LAST_PLAYER), then
227 the client should give the user an opportunity to quickly
228 re-enter the game. Otherwise the client should quit.
229
230 Clear screen 195 (CLEAR)
231
232 S: {uint8: 195}
233
234 The client must erase all characters from the screen
235 and move the cursor to the top left (x=0, y=0).
236
237 Redraw screen 210 (REDRAW)
238
239 S: {uint8: 210}
240
241 The client should attempt to re-draw its screen.
242
243 Audible bell 226 (BELL)
244
245 S: {uint8: 226}
246
247 The client should generate a short audible tone for
248 the user.
249
250 Server ready 231 (READY)
251
252 S: {uint8: 231} {uint8: n}
253
254 The client must refresh its screen.
255
256 The server indicates to the client that it has
257 processed n of its characters in order, and is ready
258 for more commands. This permits the client to
259 synchronise user actions with server responses if need be.
260
261 Characters other than the above.
262
263 S: {uint8: c}
264
265 The client must draw the character with ASCII value c
266 in the same way as if it were preceded with ADDCH
267 (see above).
268
269
270David Leonard, 1999.
271
272$OpenBSD: README.protocol,v 1.1 1999/12/12 14:51:03 d Exp $
273