| Up to higher level directory | |||
| Name | Date | Size | |
|---|---|---|---|
| hunt/ | 03-Jun-2023 | ||
| huntd/ | 03-Jun-2023 | ||
| include/ | 09-Nov-2022 | ||
| Makefile | 04-Oct-1997 | 102 | |
| Makefile.inc | 29-Mar-2014 | 3.3K | |
| README | 04-Oct-1997 | 7.1K | |
| README.protocol | 04-Jul-2009 | 8.3K | |
README
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 (a] cgl.ucsf.edu 169 Greg Couch 170 gregc (a] 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. 176
README.protocol
1 2 THE HUNT PROTOCOL 3 ================= 4 5 These are some notes on the traditional INET protocol between hunt(6) and 6 huntd(6) as divined from the source code. 7 8 (In the original hunt, AF_UNIX sockets were used, but they are not 9 considered here.) 10 11 The game of hunt is played with one server and several clients. The clients 12 act as dumb 'graphics' clients in that they mostly only ever relay the 13 user's keystrokes to the server, and the server usually only ever sends 14 screen-drawing commands to the client. ie, the server does all the work. 15 16 The game server (huntd) listens on three different network ports which 17 I'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 23 The protocol on each port is different and are described separately in 24 the following sections. 25 26 Lines starting with "C:" and "S:" will indicate messages sent from the 27 client (hunt) or server (huntd) respectively. 28 29 W - 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 92 S - 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 107 P - 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 270 David Leonard, 1999. 271 272 $OpenBSD: README.protocol,v 1.1 1999/12/12 14:51:03 d Exp $ 273
Indexes created Fri Sep 26 08:10:20 GMT 2025