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: 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 markm@zerbin.dev.cdx.mot.com. Updates: The latest version is always available for file request or download from The Bloom Beacon BBS, (401)334-0467. 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.