Amiga Elysian Archive/AmigaElysianArchive.iso/comm/hs21.lha/HS.Docs

Text File | 1993-04-21 | 14KB | 340 lines

                              Hack & Slash 2.0

                      by Mark Montminy and Robert Hurst

Introduction:

    Hack & Slash is a popular Role Playing door that should
    run under most BBS packages available for the Amiga. This
    is the second major revision of the game, and includes
    many new features and bug fixes. As of version 2.0, Hack
    & Slash is now multi-line aware, making it an ideal game
    for multi-line BBS systems.

Copyright:

    Hack & Slash is Copyright 1992,1993 by Robert Hurst and
    Mark Montminy. Hack & Slash may be copied and distributed
    freely for any non-commercial purposes. Distributors of
    public domain software collections may redistribute Hack
    & Slash for media and handling costs only.

Registration:

    Hack & Slash is released under the Shareware concept.
    You are free to use the game in it's unregistered mode for
    as long as you wish, but will only be able to enjoy the
    game until your players reach a certain limit. At that
    point, they will no longer be allowed to enter the game
    until it is registered. There are 2 levels of registration
    available with Hack & Slash. Please consult the registra-
    tion form included for more information.

Installation:

    To install Hack & Slash, simply extract the archive into
    the directory you wish to run it from. It is recommended
    that you install it in the same location as your other
    doors for consistency, though it is not required. All
    files and directories will be created in the proper loca-
    tions.

Calling the door:

    Due to the fact that Hack & Slash is intended to be run
    from a variety of BBS packages, it is impossible to cover
    all the various ways of starting the door here. In it's
    simplest form, Hack & Slash should run like any other CLI
    based door on most systems. Some example start-up scripts
    have been included in the BBS-Startup directory for the
    more unusual cases.

    Hack & Slash is a bit different from most doors in that
    it requires 2 programs to run. The server program
    (HSserver) is to remain running at all times, and it is
    suggested that you start it as part of your BBS boot pro-
    cedure or from the WBStartup drawer on 2.0 systems. It's
    relatively small, and CPU friendly. The main program that
    will be run by your users is the client (HSclient).

    Both HSclient and HSserver have two ways of finding the
    needed data files. Upon startup, they will check for the
    existance of an ENV variable called HS2. This variable
    should contain the full path to the main game directory.
    Ie, if HS is located in DH0:doors/H&S, you would set HS2
    to be DH0:doors/H&S/. If they do not find HS2, they will
    extract the path from the command line they were run from.

    This is important to note for several reasons:

      -resident code will NOT be used if a path is specified

      -you cannot specify a path if you start HSserver via
       it's icon, HS2 _must_ be set.

    It is recommended that you use the HS2 ENV method. It's
    a much simpler means of starting the game, negates the
    need to type lengthy path names, speeds startup (when
    HSclient is resident), and avoids all confusion as to
    where the game looks for it's data files.

    HSserver can be started by either double-clicking it's
    icon, or dropping it in the WBStartup folder (under 2.0+).
    Note that when starting it via the icon, you must have the
    HS2 ENV variable set (see above). You can also start the
    server from the shell by typing:

    run >nil: <nil: dh0:doors/H&S/HSserver

    Obviously you'd substitute the proper path.

    To shut down HSserver, simply run it again. It will
    check to see if another server is running, and shut both
    down. A requester will appear to confirm your decision.
    Note that it IS possible to shut HSserver down with cli-
    ents still connected. This should ONLY be done is a client
    is hung for some reason. Yanking the server out from under
    active clients will more than likely result in a crash,
    and possible corruption of the game's data files. Don't
    be stupid.

    HSclient is pure, and can thus be made resident. In
    fact, if you are running a multi-line system, this is
    highly recommended to reduce memory overhead. Even on sin-
    gle line systems with enough memory to do so, you'll
    notice a significant performance increase when the game
    loads.

    The syntax for HSclient is:

      HSclient <options> userID

    userID may be the username, phone number, user number, or anything
    else that is unique to that user on your BBS.  It's used by the
    game simply as a means of distinguishing between users.

Options:

    The options available for the client are:

    -t n  This option should be followed by your BBS' con-
          trol code for the user's time remaining. If the
          user's time remaining on the BBS is less than
          their allowed time limit in the game, it will
          be used instead, minus 2 minutes to allow ade-
          quate time to log off properly.

    -x n  This option is only useful under Xenolink. When
          run as a XenolinkDoor, this option must be used
          followed by a ~20 to pass the XCB pointer. This
          is not needed if running as a CLIDoor (which
          does not work prior to Z4)

    -T    This option is only useful under TAG BBS. When
          run under TAG BBS this switch is needed to acti-
          vate the TAG BBS interface.

    -e    This option turns off character echoing on sys-
          tems that handle the echo internally.

    -c    This option prevents users from playing their
          allotted turns back to back. When used, players
          must wait until another person has played before
          they are allowed to play again.

    -h    This option disables hotkeys.  Some systems don't
          properly handle hotkeys.  If your's is one, use this
          option.

Maintenance:

    Hack & Slash is fairly self maintaining. It is important
    to note that player #1 is expected to be the "sysop" of
    the game. This player has access to the internal sysop
    menu via the @ key. While other players can be given access
    to this menu by assigning the proper access level, one
    must initially have access to do so.

    When the game is first started, the automatic re-roll
    date is set to 1 day after the game is started. You must
    go into the sysop menu and edit the re-roll date. This is
    done by using the user editor. Instead of entering the
    number of a user to edit, enter *. You will be given a
    list of settings that can be edited. This is also where
    you will unlock the registered version.



                       ** WARNING **

    Do not tamper with the License fields unless you are
    attempting to register your version of the game. Placing
    incorrect values in these fields will force an automatic
    re-roll of the game!

    Choose an appropriate date to re-roll the game on. Re-
    rolling resets all players to a non-class state, forcing
    them to re-select their class, and start at level 1. This
    also strips any special classes such as Hero, Titan and
    God. Re-rolling times will vary depending on the abilities
    of your players. It's good to re-roll the game when you
    have too many high classed players as it makes it very
    difficult for beginners to get started.

    There is no need to purge unused players from the game.
    There is an auto-purge mechanism in place that will handle
    this for you. If a new player tries to join the game, and
    there are no free slots, the game will search for a player
    that hasn't played in a long time and remove him to make
    room for the new player.

    From the sysop menu, you can opt to bless and curse spe-
    cific, or random users. Blessing adds 10 points to the
    users attributes, while cursing removes 10 points. Bless-
    ing remains with a user, until they are killed by another
    user, who in turn inherits the blessing, or they are
    killed by a monster, in which case the blessing will be
    randomly re-assigned to another user. Cursing remains with
    the user until they kill another user. The curse will then
    be transferred to that user. Sorry, you can't curse a mon-
    ster by killing it. The only way to remove a curse, is to
    give it to another. What fun though when someone tries to
    kill you and loses! It is recommended that you start the
    game off by blessing and cursing a number of users.

    You can print a list of you users from the sysop menu.
    Output can be directed to a file, or the printer for hard-
    copy.

    You can review the sysop log from the sysop menu. This
    log reports various activities in the game, and will also
    be used for debugging purposes if needed.

Menus and Monsters:

    All of the menus in Hack & Slash are simple text files
    that may be edited to look the way you'd like. There are
    no special codes used, no fancy tricks. They are shown as
    they are. Files ending in .TXT should be straight ASCII
    text, while files ending in .ANS should support color and
    or IBM graphics.

    Monster pics are placed in various directories based on
    the type of monster, as well as player pics. Monsters may
    be added by simply creating a file with the same name as
    the monster. Be sure to include the proper spaces in the
    names. You're a sysop, you should be able to figure this
    out without much difficulty.

    The various help files are also simple text files. The
    help system works by looking for a file called Help.x
    where x is the corresponding letter/number in the Help
    menu. Feel free to add your own help files for your users.
    Note that O and Q are not allowed.

The Messaging System:

    New to Hack & Slash 2.0 is a messaging system similar,
    but much simpler than that on the BBS. You can configure
    various message areas for users to converse in. Conversa-
    tion can be coerced by defining a post/call ratio in the
    special user slot in the sysop editor (see above). Users
    who don't meet the post/call ratio will be taxed on every
    turn until they do. To turn this option off, simply spec-
    ify a post/call ratio of 0. Note that you can specify a
    post/call ratios using decimal numbers such as .10, so a
    user would only be required to post once every ten calls.
    There is no need to purge messages, the game does so on
    it's own. Again, this is a very simple messaging system,
    but it suffices.

Player Interaction:

    At this time, it is not possible for several players on
    a multi-line system to interact in real time. Trying to
    attack a player while he/she is online will report that
    that player is out adventuring. This is planned for a
    future version.

Configuration:

    It was hoped to have the GUI config util done prior to
    this release. Unfortunatley this was not possible.
    Included is the old ugly cli based config util. I'm not
    going to go into documenting it's use, since the GUI will
    be self documenting.

Registration Limits:

    In it's unregistered state, Hack & Slash allows full
    play of the game, with no crippled features. Instead,
    players are limited as to the level they can obtain. Once
    they reach a predetermined level, they will no longer be
    allowed access to the game until it is registered, at
    which point they can continue where they left off.

    The HSserver is also limited in it's unregistered form
    to only allowing 1 client at a time to connect. Register-
    ing the server removes this limit and allows a max of 16
    clients at any time.

Support:

    Hack & Slash is in a constant state of change. We will
    continue to improve and expand the game as long as there
    is interest. We have ALOT of future plans for this game.

Bug reports:

    Bug reporting should be done via one of the following:

      The Hack & Slash sysop echo (HACK_SLASH). Address
      your problem to either Mark Montminy, or Robert
      Hurst.

      Netmail to Mark Montminy @ 1:323/119. Netmail mes-
      sages do not always get a reply, but they do get
      read.

      Internet Email to [e-mail].

Updates:

    The latest version is always available for file request
    or download from The Bloom Beacon BBS, [phone].

    Magic names for request are:

      H&S    - for the latest complete archive

      H&SUPD - for the files needed to update from the pre-
               vious release.

    I also try to keep a recent version on the Aminet FTP
    backbone in games/role.

Credits:

    Many thanks go to Robert Hurst for making this game,
    and allowing me to take part in it's development. Also for
    his help in bailing me out all the time when I screwed up
    the code :)

    Thanks go to Alan Bland for his ongoing help and friend-
    ship. If we ever meet, I promise better than a Bud Dry :)
    Maybe by then we can exchange homebrew secrets :)

    Thanks to the beta testers for hammerin out the nasties.

    Thanks to Mike Steele for being the only CNet sysop to
    take the time to help us figure out why it wouldn't work
    under CNet.

    Thanks to my wife for putting up with my countless hours
    spent in front of the CRT coding away.

    And above all, thanks to all the users who've supported
    us by registering. Had it not been for the overwhelming
    support we've received, we would have never carried this
    project this far. For those in doubt, Shareware does work.