home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 8 / FreshFishVol8-CD1.bin / new / game / role / amigamud / client / doc / intro.txt < prev    next >
Text File  |  1994-06-04  |  22KB  |  441 lines
  1. AmigaMUD, Copyright 1994 by Chris Gray
  2.  
  3.  
  4.         Introduction to the AmigaMUD System
  5.  
  6. The AmigaMUD system is a software system for the Commodore Amiga line
  7. of computers which implements a MUD (Multi-User-Dungeon). MUDs have
  8. existed on various computers for about 20 years, usually run at
  9. universities on networked computers. In a typical MUD, several people
  10. connect to the system at the same time and interact by typing in
  11. messages and commands to the MUD. MUDs are usually set up somewhat
  12. like text adventures, in that they contain a small world in which the
  13. players can explore, solve puzzles, etc. MUDs add to the adventure the
  14. possibility of interaction, within the world, of the various players.
  15. Players can talk to others in the same location; they can cooperate in
  16. solving puzzles; they can compete in improving their characters or
  17. personnas; they can engage in combat, etc.
  18.  
  19. The world in which the MUD is set is chosen and built by one or more
  20. people who are the implementors or "wizards" or "gods" of the MUD. MUD
  21. worlds have been set in various fictional as well as real situations,
  22. such as Star Trek, Xanth, the Discworld, etc. Other MUDs specialize in
  23. role playing, where the players pick a persona and do their best to
  24. stay within it. For example, "furries" on FurryMUD all pick a furred
  25. animal as their character.
  26.  
  27. Many MUDs exist on the 'internet', the international network of
  28. computer systems, mostly supported by various governments. Amiga
  29. computers are not often on this network, so they will usually get
  30. their multiple players through serial ports and modems. Amiga-based
  31. BBS systems often have multiple lines, and these can be used for
  32. connections to AmigaMUD.
  33.  
  34. Today, most MUDs are strictly text based. That is, users do all
  35. operations in the MUD by typing commands, and all output is via text
  36. messages. In the last couple of years, colour graphics have become
  37. quite common on home computers and workstations. MUDs are beginning to
  38. take advantage of that capability by introducing simple graphics
  39. output. Sound output is also possible.
  40.  
  41. AmigaMUD provides graphics and sound output as a standard element. It
  42. also allows the use of the mouse and numeric keypad as input. The
  43. system still provides the full text input and output interfaces,
  44. however, and can be used in a text-only mode. The standard
  45. availability of graphics output and mouse input can change the nature
  46. of a MUD, and make it available to those who aren't terribly good at
  47. typing, or who are uncomfortable with computers.
  48.  
  49.  
  50. Basic Capabilities
  51.  
  52. The main function of the AmigaMUD system is to allow the playing of a
  53. MUD, which is a multi-player text adventure game. As such, several
  54. people can be playing the same game at the same time. There is no
  55. inherent limit on the number of simultaneous players, but the CPU time
  56. needed to handle the server and the serial port activity will likely
  57. limit a top-end Amiga to under 50 active players.
  58.  
  59. The AmigaMUD system does word wrapping on output. This means that long
  60. lines are automatically broken up on word boundaries. The designers of
  61. the scenarios and the builders of new rooms and objects, etc. do not
  62. have to worry about properly formatting things. The formatting is done
  63. with respect to the actual output width of the MUD text window, which
  64. varies depending on the amount of overscan the user has setup.
  65.  
  66. Graphics output is to a 320 pixel wide by 100 pixel high by 32 colour
  67. graphics window at the top of the visible display (unless the user has
  68. chosen to hide it). Primitives exist in the system to draw and fill
  69. lines, circles, polygons, etc. A scenario can also scroll regions of
  70. the graphics window, and can dump IFF ILBM graphics images (from the
  71. machine on which the MUD client program is running) to the window.
  72.  
  73. The scenario can add "mouse buttons" to the graphics window. These are
  74. small rectangular areas containing text that the user can click on
  75. with the mouse. Doing so triggers an action in the scenario, such as
  76. moving in a specific direction. The scenario can also set up regions
  77. of the display which are sensitive to mouse clicks. Clicking within
  78. such a region sends to the server a message indicating the position
  79. within the region which was selected. This capability is used by the
  80. icon editor in the standard scenario.
  81.  
  82. The MUD client program can use the Amiga's speech synthesizer software
  83. (libs:translator.library and devs:narrator.device) to generate speech
  84. output. This capability requires that libs:translator.library exist on
  85. the server machine, and that devs:narrator.device exist on the client
  86. machine. Note that these items are not currently shipped with version
  87. 3.0 of the Amiga OS software package.
  88.  
  89. Scenarios can request that sound samples (IFF 8SVX files) be played on
  90. client systems. Since the Amiga has four hardware sound channels, up
  91. to four samples can be played simultaneously. These samples are loaded
  92. from the AmigaMUD:Sounds directory on the client Amiga.
  93.  
  94. The MUD program supports the concept of icons. These are small (up to
  95. 16 x 16 pixels) one-bit-per-pixel images that are overlayed on top of
  96. the main graphics imagery. They are used to indicate the presence, in
  97. the same "room" as the player, of other players and NPCs.
  98.  
  99. The MUD program can "cache" local copies of descriptions of graphics
  100. imagery, commands to play sounds, icons, etc. This caching can greatly
  101. reduce the amount of data that must be continually retransmitted over
  102. the serial connection, thus speeding up gameplay.
  103.  
  104. The MUD program includes a builtin full-screen text editor, which can
  105. be used to edit room descriptions, object descriptions, etc. It can
  106. also be used, when in wizard mode, to edit AmigaMUD functions, and is
  107. integrated with the AmigaMUD programming language parser to show the
  108. location of errors. MUD can also call out to an external editor for
  109. these purposes.
  110.  
  111. The text adventure aspect of AmigaMUD includes a set of fairly
  112. powerful routines to assist in writing code that "understands" pseudo-
  113. English commands. For example, when the scenario is parsing a user
  114. input line like:
  115.  
  116.   Put the apple, the pear and the black sword into the brown paper bag.
  117.  
  118. the code that understands how to put things into other things will be
  119. automatically called three times, one for each object to be put into
  120. the bag. Also provided are routines to aid in identifying the objects
  121. being referenced.
  122.  
  123. The AmigaMUD system includes a fairly efficient interpreted
  124. programming language which is used to build the scenarios or worlds
  125. that run under the system. Note, however, that with the current
  126. scenario, building of rooms, objects, etc. can be done entirely
  127. without using any of this programming language. The language is a
  128. strongly typed, structured language that should be usable by anyone
  129. with a bit of programming experience. The entire scenario is built
  130. using this language - rooms and objects are created dynamically by
  131. executing code in the language. The standard scenario includes a large
  132. set of utility routines designed to simplify the building of rooms,
  133. etc. Here is an example AmigaMUD programming language routine, which
  134. is a part of the standard scenario. It is used to draw the random
  135. coloured rectangles which are the graphics imagery for the "SysAdmin's
  136. Study" room:
  137.  
  138.     define tp_mall proc drawStudy()void:
  139.     int i, x, y;
  140.  
  141.     for i from 1 upto Random(20) + 10 do
  142.         GSetPen(nil, Random(32));
  143.         x := Random(159);
  144.         y := Random(99);
  145.         GAMove(nil, x, y);
  146.         GRectangle(nil, Random(160 - x), Random(100 - x), true);
  147.     od;
  148.     /* force a re-draw on look */
  149.     Me()@p_MapGroup := UNKNOWN_MAP_GROUP;
  150.     corp;
  151.  
  152. The standard scenario provided with AmigaMUD includes "builder
  153. commands", which allow non-wizards to build new rooms and objects into
  154. the scenario, while it is running. If the player is using the full MUD
  155. client program, this building can be done using mouse-buttons and a
  156. full-screen editor.
  157.  
  158. The standard scenario also provides some functions which can draw a
  159. simple overhead view of a room based on the obvious exits from that
  160. room. Several styles are available, including pathways, tunnels, and
  161. interior rooms. These simple graphics can be attached to rooms using
  162. mouse-buttons. The colours used can be changed for variety.
  163.