@database "OpElim.guide" @master "OpElim.doc" @node main "Operation: Elimination 1.0 Copyright © 1995 by Jean-Guy Speton" Operation: Elimination 1.6 Copyright © 1995 Jean-Guy Speton. All rights reserved. @{" Introduction " link introduction} A brief overview of the game. @{" Legalities " link legalities} Copyright and distribution information. @{" Registration " link registration} Why and how to register. @{" Installation " link installation} How to set up the game. @{" Programs " link programs} The three programs and what they do. @{" Operation " link operation} How the game works. @{" Configuration " link config} Configuring the game. @{" Help Files " link help} What they are and how to change them. @{" Map Design " link map} How to go about designing your own map. @{" Computer Players " link computer} Setting names, number, and location. @{" History " link history} The story so far, such as it is. @{" Future " link future} What futures versions have in store. @{" Author " link author} How to get in touch with me. @{" Credits " link credits} Who's responsible for this. @endnode @remark =================================================================== @node introduction "Operation: Elimination Introduction" INTRODUCTION Operation: Elimination is a STDIO door for your single- or multi-line BBS. It requires AmigaOS 2.04 (v37) or higher to run. Operation: Elimination is fast action game of kill or be killed. Each player is given a cyborg to control, collecting weapons and equipment, forming teams and alliances, and staking out territory in the complex. Interaction between players is an important part of the game, as trust and betrayal play intricate parts in survival. As players advance in score and skill, they are capable of increasing feats which will help in their gameplay. The freely distributable unregistered version may be used on a trial basis for 30 days following the date of initial reception of the unregistered archive. The registered version has some features which the unregistered version lacks, but the unregistered version is still completely playable. See also: @{" Legalities " link legalities} @{" Registration " link registration} @{" Installation " link installation} @endnode @remark =================================================================== @node legalities "Operation: Elimination Legalities" COPYRIGHT Operation: Elimination exists in two incarnations: the unregistered and registered versions. All files included in the distribution archive of both versions are Copyright © 1995 by Jean-Guy Speton. All rights reserved. DISTRIBUTION The unregistered version of Operation: Elimination (hereafter referred to as UOE) is freely distributed in its original, unmodified form providing that the distribution contains all files in the original distribution archive. No charge in excess of the cost of media may be charged for the distribution of UOE. The registered version of Operation: Elimination (hereafter referred to as ROE) may not under any circumstances be distributed without the express written consent of the author. DISCLAIMER This product is sold "AS IS" without representation or warranty of any kind, either expressed or implied. The user assumes all risks and responsibilities related to its use. I hereby reject any liability or responsibility for any consequences from the use of UOE and/or ROE. This includes, but is not limited to, damage to your equipment, to your data, personal injuries, financial loss or any other kinds of side effects. @endnode @remark =================================================================== @node registration "Operation: Elimination Registration" REGISTRATION Why would you want to register your copy of Operation: Elimination? Aside from alleviating the guilt plaguing your conscience, the registered version of Operation: Elimination includes the following features: · Allows unlimited players in the game at once, whereas the unregistered version does not allow more than 3 players at a time. · Create or modify your own map, instead of using the map provided with the unregistered version. · Players can increase their stats past level 10. · Players can construct and use bombs to create new rooms in the complex. To register, send $20 in US funds to the address below. Acceptable forms of payment are US cash, personal check drawn from a US bank, or a bank or postal money order in US funds. I cannot accept foreign currency, Eurochecks, etc. If you decide to send cash, please be sure to properly conceal the money in the envelope from unscrupulous postal workers. This includes padding the envelope with paper, etc. Send your payment, including your name, mailing address, BBS name and number, and E-mail address to: Jean-Guy Speton 155 NW Kings Blvd. #C-1 Corvallis, OR 97330 USA As soon as I receive your payment I will mail to you your registered version, which will include a keyfile with your BBS name and registration number encoded in it. This keyfile will allow you to simply download the unregistered version of future releases and the registered features will be enabled automatically. Registered owners of Operation: Elimination may at any time request a free update. Simply send a blank disk and self-addressed stamped envelope to the address above and I will copy the latest version to the disk and return it to you in the supplied envelope. If you already have the latest version, I will hold the disk and envelope until a new version is ready. (You may also send $2 US in lieu of a disk and stamped envelope, in which case I will supply the disk and envelope.) See also: @{" Author " link author} @{" Credits " link credits} @endnode @remark =================================================================== @node installation "Operation: Elimination Installation" INSTALLATION Installation of Operation: Elimination is very simple. Some shell knowledge is required, but if you can set up a BBS you most likely know enough to set up the game. Create a directory where you wish Operation: Elimination to reside. Copy all files from the distribution archive to that directory, and add an assign in your user-startup to that directory called OPELIM:. Now you must set-up your BBS software to execute Operation: Elimination. Operation: Elimination uses STDIO input/output (also known as a shell or DOS door). The game should be executed with the command line: OPELIM:Elimination where is a unique identifier for the user wishing to play. This could be the player's real name, phone number, etc. Remember that if it contains spaces to enclose the argument in quotes. That's it! Operation: Elimination is now ready to play. If you wish to test it before installing it on your BBS, Operation: Elimination may be played from the shell. Simply enter the commandline above from a shell prompt and the game will start if everything has been installed correctly. See also: @{" Programs " link programs} @{" Configuration " link config} @endnode @remark =================================================================== @node programs "Elimination: Operation Programs" PROGRAMS Three executables form the basis of Operation: Elimination. ELIMINATION Elimination is the client program. One copy is run for each player in the game. Elimination is pure, which means it may safely be made resident with the AmigaDOS 'resident' command. If you expect more than one person to play Operation: Elimination at a time, it is highly recommended that you take this step, as it will greatly reduce the amount of RAM used. MASTER Master is the server program. Only one copy will be running at any one time. You should NEVER execute Master yourself. Elimination will look for and execute Master automatically if it is found. Once run, Master will remain in memory until your Amiga is shut off or until the Shutdown program is run. When there are no players in the game, Master will go to sleep, using no CPU cycles. As soon as a player enters the game again Master will waken and resume normal operation. SHUTDOWN Shutdown, as mentioned above, will cause Master to remove itself from memory. The next time Elimination is run Master will again be loaded and run from disk. Shutdown cannot be run if there are players currently in the game; it will complain and exit. See also: @{" Installation " link installation} @{" Operation " link operation} @endnode @remark =================================================================== @node operation "Elimination: Operation Operation" OPERATION The game stores its data in the file "OpElim.data". When you first install the game you will notice that this file is absent from the distribution. What the game does the first time it is run is build this data from the files "Data.default", which specifies the @{"map" link map}, and "Computer.players", which specifies the names, location and number of @{"computer controlled" link computer} players. Loading the data from the original specifications could take a while; the more rooms you have, the longer it takes. Fortunately, this step is required only once (or when you reset the game), and subsequent start-ups using "OpElim.data" are much faster. The file "OpElim.data" stores the current room layout, including new rooms which have been bombed since the original map was loaded, the information for all teams, and the high scores. This file is automatically saved by Master every 15 minutes (when not in 'sleep' mode) and whenever the Shutdown program is run. Deleting this file will cause the map to be reset, as well as all teams and high scores. Note that the players will NOT be reset by deleting this file. To reset the players, you must delete all files from the Players directory. See also: @{" Installation " link installation} @{" Programs " link programs} @endnode @remark =================================================================== @node config "Operation: Elimination Configuration" BULLETIN TEXT Operation: Elimination will try to read a text file called "Bulletin.txt" in the OPELIM: directory each time a client is run. In this file you can place anything you want, be it an announcement of map changes, the current state of affairs in the complex with regards to teams, major goings on, etc. Of course, it is not necessary to have this file; the choice is entirely up to you. Other configuration options are modified with the OEConfig program. This program modifies the file "OpElim.config", which stores your configuration options. Currently, the following options for configuration are available. SYSADMIN PASSWORD This string should contain a single word of not more than 30 characters which will be the password to access the special administration commands available in the game (see the "admin" help file for a list of these commands). To activate the commands, simply type this word, prefaced by a @ character, while playing the game. For example, suppose the file contains the word "operation". To gain access to the administration commands simply type in "@operation". Every unregistered copy will have the same password (obviously, since everyone gets the same copy) and it is ESSENTIAL that you change this before installing the game or otherwise you'll have a game full of max-stat, plasma rifle-toting armoured tanks. DROP ITEMS ON DEATH/EXIT Checking this option will cause items carried by players who die or exit the game to drop to the floor of the room which they are in. If this option is unchecked, the items carried by such players will simply disappear. Note that with this option checked the number of items in the maze will vastly increase. The author recommends that you leave this option unchecked. See also: @{" Installation " link installation} @{" Programs " link programs} @endnode @remark =================================================================== @node help "Operation: Elimination Help Files" HELP FILES The on-line help files for Operation: Elimination are in the directory OPELIM:Help. They include basic gameplay descriptions and a list of all commands and available weapons in the game. The help system is triggered when a player types "help" in the game or selects the [H]elp option from the menu. The first file the player sees is the "help" text file, which should always list the other help files available. You are free to edit these files, even create new ones, to your liking. Note that the "admin" help file, which lists the commands available to players with administration access, is not listed in "help" but is still visible to any player who types it in: you may wish to rename it or even remove it from the directory. See also: @{" Configuration " link config} @endnode @remark =================================================================== @node map "Operation: Elimination Map Design" MAP DESIGN The setting of Operation: Elimination is a three-dimensional layout of rooms, all of equal size. Each room receives an X, Y and Z coordinate, which determines the other rooms in the game that connect to it. Movement along the positive X axis is east, and the negative X axis is west. Movement along the positive Y axis is north, and south the reverse. Up and down work respectively for the Z axis. The room layout of Operation: Elimination is completely configurable, as is the description of each room. The layout is specified in the file "Data.default" using a combination of description and room placement definitions. There is only one restriction on the ordering of rooms and descriptions in the file: the description number for a room MUST correspond to a description which precedes the room definition in the file. Other than this you are free to intersperse rooms and descriptions as you please. NOTE: The unregistered version of Operation: Elimination does not support user-defined maps. Please @{"register" link registration} if you wish to take advantage of this feature. Please refer to the "Data.default" file supplied with the game for an example. The file formatting looks like this: # Lines preceded by a #-sign are comments and are ignored by the # interpreter, as are blank lines. Room descriptions are denoted by the four letters DESC at the start of a line. These letters are followed by whitespace and a unique description number, which is used to reference this description in the room specifications (see below). This number may not exceed 65535 (16 bits unsigned). The remainder of the line is the title of the room. This should be brief but describe the purpose of the room. The next lines comprise the detailed description of the room. This should not be long; usually 1-5 lines is best. The description specification ends with the 7 letters ENDDESC which reside on a line by itself. Example: DESC 10 Torture Chamber All manner of racks and devices of torment clutter this room. Particularly menacing is the iron maiden which hangs against the east wall. Listening intently, you almost believe you can hear the cries of the damned which once occupied this horrid place. ENDDESC The room specification is a single line, beginning with the four letters ROOM. Following this is the room's number. Note that rooms do not necessarily have to follow the natural ordering of their numbers, and not every number needs to be presented. It is entirely possible, for example, to have a room 6 and a room 8, but not a room 7. However, new rooms are created starting with one number higher than the highest numbered room specified in the file. Following the room's number is its X, Y and Z coordinates, either positive or negative. Values lower than -32768 and values higher than 32767 (16 bits signed) are not allowed. After these three numbers is the description number of the description which this room will inherit. It is highly recommended that rooms share descriptions, both to simplify your task and to reduce memory usage. The remainer of the line contains none, all or any number of special options, defined below: D? This will place a door between this room and the room which lies to the north, east, south, west, above or below this room (put a N, E, S, etc. in place of the ? after the D, appropriately). It is not necessary to put a corresponding door in the other room: the game will place one automatically. However, no harm is done if you do. W? This works identically to D?, but will place a wall instead. OPEN Marks this room as an open area. If two rooms are both OPEN and share the same description number, a person in one will unconditionally be able to see a person in the other. This allows for large open areas of any size, not just hallways. Note that the description is the key to which OPEN rooms can see other OPEN rooms. NOFLOOR This word specifies that the current room has no floor. Items dropped will fall down to the room below, as will players. It is recommended that rooms with NOFLOOR actually have a room below them. LADDER Places a ladder in the current room, which will allow players to use the up exit, if one exists, without the use of a jetpack. DARK This word marks the room as having no light source. A flare or light-amplification goggles will be needed to see in such a room. MEDICAL Specifies that this room contains medical facilities where players may heal and advance their abilities. Your map should always have at least one room with medical facilities. SLEEP Places sleeping modules in the current room. Players who do not quit the game in a room with sleeping modules roam the game mindlessly under computer control. As with MEDICAL, your map should have at least one such room. STORE Allows players to buy various staple items in this room. RECYCLE With this option, players can recycle unwanted items for credits. The ordering of these flags on the line is unimportant, but they must follow the five numeric values which follow the ROOM keyword. Example: ROOM 14 4 -10 2 5 DN WE WW MEDICAL DS WARNING: Currently tabs are not supported by the interpreter. Use spaces when necessary. Exits which have either a door or wall inherit a special property: if adjacent to such an exit, one cannot see more than one room away in that direction. This means that, for example, if in a room with only one exit, which has a door, and if the door is open, only the people in the immediate room outside the door will be seen. Any people further away will not be seen until the current room is exited. This property holds even if the door or wall is completely blown away. In addition, only such exits may have new doors or walls constructed on them. This is to prevent the construction of walls in the middle of a main hallway, for example. Any exits for which a room does not exist on the other side automatically inherit this property. For this reason, the placement of doors and walls should not be haphazard, unless desired. When new rooms are created by bombs, they will always inherit the description numbered 1. For this reason, your map specification must contain a description numbered 1. See also: @{" Computer Players" link computer} @endnode @remark =================================================================== @node computer "Operation: Elimination Computer Players" COMPUTER PLAYERS The players controlled by the computer are specified in the file "Computer.players". Unlike the map, the computer players are reloaded from this file each time Master is run, and they are not saved in the file "OpElim.data". The format of this file is very simple: # Lines preceded by a #-sign are comments and are ignored by the # interpreter, as are blank lines. The first non-blank, non-commented line must contain a single integer value. This value is the number of the room where the computer players will initially reside. If this room number does not exist, the computer players will be dumped in the first room specified in the file "Data.default". Example: 58 All remaining non-blank, non-commented lines are the names of the computer players, one to each line. In addition, the first such line is the name of the computer leader, the rest are his followers. The leader is simply a tougher, smarter version of the other computer players. There is no limit to the number of the computer players which may be specified, other than memory and CPU constraints. The more computer players there are, the more CPU time it will take to manage them. Trial and error is a good way to manage the number of computer players. Example: Agent Anderson See also: @{" Map Design " link map} @endnode @remark =================================================================== @node history "Operation: Elimination History" HISTORY Version pre-1.0 · Internal beta releases. Version 1.0 (Apr-01-95) · Initial release. Version 1.1 (Apr-20-95) · Fixed recycle bug whereby recycling a readied weapon would cause Bad Things to happen. · Various other small bugs squashed. · Computer players will now reload their weapons occasionally instead of always dropping them. · Computer players in the same room as the player they are hunting will now occasionally drop live grenades. · The computer leader will now drop live grenades if he finds himself in a room with no exits (usually resulting from players building walls around him). Version 1.2 (May-11-95) · High-level players can now build energy shields. · The computer leader will now change location every so often. Version 1.3 (Jun-09-95) · Another bug squashed. · Added keyfile support for registered owners. · Removed 3 node restriction from unregistered version. · Players are now given 10 seconds to find shelter after death. · Added OEConfig program to archive. · New configuration option: drop items on death or exit. Version 1.4 (Jun-16-95) · More bugs fixed. · Added @admin command. Version 1.5 (Jul-07-95) · Minor bug fixes. · Added @goto admin command. · Added reactors, radios, and teleporters. · Explosives can now be bought at stores. · Players with admin access can now enter rooms claimed by other players/teams. Version 1.6 (Jul-15-95) · Added frequency to teleporter and receiver listings, to aid in matching pairs. · Reworked @{" ability requirements " link ability_requirements} for most of the constructable items to more reasonable levels. @endnode @remark =================================================================== @node ability_requirements "Construction Skill Requirements" CONSTRUCTION SKILL REQUIREMENTS Item Construction Skill Heavy Weapons Skill ~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~ Wall 1 0 Door 1 0 Ladder 2 0 Rocket 6 6 Rocket Launcher 8 8 Teleporter/Receiver 11 0 Bomb 12 12 Energy Shield 14 10 Reactor 15 15 Sleep 16 0 Medical 18 0 @endnode @remark =================================================================== @node future "Operation: Elimination Future" FUTURE Future versions of Operation: Elimination will contain the following: · The ability for players to build and arm armoured sentries, which can be programmed to guard rooms, hunt down players, etc. · Increased computer AI. · More special player abilities, such as being able to scry the location of other players. If you have any suggestions, I'd be more than willing to hear them. If I like them, they will most certainly be implemented. See also: @{" Author " link author} @endnode @remark =================================================================== @node author "Operation: Elimination Author" CONTACTING THE AUTHOR I can be reached via the Internet at: speton@cs.orst.edu (preferred) or jspeton@quest.blaze.bc.ca And via post mail at my current address: Jean-Guy Speton 155 NW Kings Blvd. #C-1 Corvallis, OR 97330 USA or my permanent address: Jean-Guy Speton RR 2, Box 21A Lexington, VA 24450 USA If you have bug reports, suggestions, comments or any questions please don't hesitate to contact me. See also: @{" Registration " link registration} @endnode @remark =================================================================== @node credits "Operation: Elimination Credits" All code is the original work of Jean-Guy Speton. A big thank-you to my beta tester: Kyle Chow of Quest Communications BBS. Without his suggestions and bug reports this game would not have been possible! Also thanks to Dean Husby for his constant supply of suggestions and comments. @endnode