README 7.1 KB

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