Media Share 9/MEDIASHARE_09.ISO/bbsdoor/ironox10.zip/SYSOP.DOC

Text File | 1994-02-10 | 29KB | 551 lines

                         IRON OX Version 1.00
                    (C)opyright 1994, Joel Downer

                               SUMMARY

Iron Ox is an interactive, multiuser strategy game for 3-8 players.  The
game concept is the development of an outer space colony world:  players
claim land, produce goods, buy, sell, and steal from one another, and
prospect for luxite, the precious mineral that allows interstellar travel.
The door supports up to 255 simultaneous games involving up to 255 active
players.

Iron Ox is self-maintaining (no nightly maintenance event), and includes
"sysop-friendly" features like detection and timeslicing for DESQview,
built-in multinode support and semaphoring (so several people can use the
door at one time), support for a wide variety of door drop files (including
DOOR.SYS, DORINFO?.DEF, EXITINFO.BBS, CHAIN.TXT, CALLINFO.BBS, PCBOARD.SYS,
and SFDOORS.DAT), and comprehensive high-score and record listing with
optional ANSI, ASCII, and WC-code bulletins.  The game includes lighthearted
humor -- for example, the colony sponsors "cultural contests" in which
players can write bad poetry or disgusting recipes -- but it also supports
complex strategy and intense competition.  The door requires that players
have ANSI terminals, but does not require a color monitor.

                          EVALUATION VERSION

Iron Ox is distributed in an evaluation version, intended for you to try
out for thirty days.  The evaluation version of Iron Ox is a complete
and (I hope) enjoyable game.  If you like Iron Ox and wish to continue
using it after thirty days, please see "LICENSING/REGISTRATION
INFORMATION," below, for details on how to register.  A registration key
for Iron Ox will enable additional features that will make the game even
more exciting for your users!

                           GETTING STARTED

Iron Ox is a game that requires multiple players, so you won't be able
to take a very thorough "test drive" without putting it up for play on
your BBS.  If you want to take a look at the door before installing it,
though, you can run the program just by typing IRONOX -LOCAL from the
directory where you have unpacked the archive.

                            REQUIREMENTS

Iron Ox requires approximately 390K of free RAM to run properly.  It
requires a minimum of 500K free disk space.  Depending on the number of
active games you have going on at a time, it can take up as much as
1,500K of disk space.  A hard drive is strongly recommended.

Iron Ox requires a FOSSIL driver to communicate with your modem.  If you
do not use a FOSSIL driver on your BBS, you can set up your Iron Ox batch
file to load a FOSSIL before running the game and unload it after exiting
the game.  X00 and BNU are both excellent drivers and have been tested
with this program.  If you have trouble finding them elsewhere, recent
versions of both of these drivers are available for download from The
Dreaming City (see "Support," below).

                         INSTALLING IRON OX

I've learned to be very suspicious when door documentation says "This
door is very easy to set up," so I won't say that.  I'll let you judge
for yourself.

Iron Ox is an extremely flexible and configurable program, so this
section may be longer than you're used to.  If all you want to do is get
the game running with a basic setup, though, you'll only need to read
the first few paragraphs and spend about five minutes. <g>  If you have
any trouble, see "COMMON INSTALLATION PROBLEMS," below.

Installing Iron Ox involves two steps:

1. Decompressing the Iron Ox archive into a door directory.  The
   examples in this file and the sample batch file assume that you have
   used the directory C:\DOOR\IRONOX\, but any directory will do.

2. Creating a batch file by which your BBS can start Iron Ox.  Most of
   the time, this batch file will include only one line:

   C:\DOOR\IRONOX\IRONOX.EXE

   (Note:  substitute the path where you have installed the game for
   C:\DOOR\IRONOX\ in the above example.)

If you're installing an evaluation copy of the game, and you don't care
about fine-tuning the configuration or setting up high score bulletins,
you're ready to add the game to your BBS door menu and get rolling.  Enjoy!

NOTE:  If you like, you can include the location of your door interface
file (e.g., "C:\WC30\WCWORK\NODE3\") as an argument on the command line.
The only time you should have to include the location of your door
interface file on the command line is when your BBS software begins door
execution in some directory *other* than the one where it creates your
dropfile.  (I know of only one BBS package, Maximus, that you can even
*force* to do this. <g>)  If this situation applies to you, your batch
file should look something like this:

C:\DOOR\IRONOX\IRONOX.EXE E:\NODE1\

if you're not sure whether this situation applies to you, *ASSUME THAT
IT DOESN'T* and use a batch file like the one in step 2 rather than the
one just above!

                         MULTINODE SETUP

Iron Ox was written and tested from the ground up to run multinode.
In general, multinode setup is *identical* to single-node setup:  all
nodes can use the same configuration file, and (for the most part) they
can use the same batch file, too.  Because the program uses a FOSSIL
driver, issues like non-standard IRQ's are handled *completely
automatically* -- no need to treat individual nodes specially.

Multiple players can use this door at the same time; Iron Ox handles all
file locking internally.  The only requirement for running the game
multinode is that you must be running DOS SHARE or some equivalent (like
the built-in file-sharing in the OS/2 DOS box or the file-sharing
facilities on LANs).  If you're running multinode *without* such a
utility, of course, now would be a good time to start...

To set up the game for multinode play, create batch files for each node
along the lines in the single-node instructions, above.  The only time
different nodes will need *different* batch files is when the game is
run across a LAN on which the drive letter for the game directory is
different for different nodes.  If you don't know what I'm talking
about, don't worry:  chances are it doesn't apply.

One more thing:  because of a bug with either Borland's run-time
libraries or with Quarterdeck's products (who's to blame for the bug
depends on whether you ask Borland or Quarterdeck <g>), you may find
that you need to flag your IRONOX.EXE executable file read-only to avoid
sharing violations when running multinode under DESQview or QEMM.  To
do this, just use the command ATTRIB IRONOX.EXE +R after unpacking the
game into your door directory.  If you ever need to uninstall Iron Ox
(I hope not!), you can use the command ATTRIB IRONOX.EXE -R to "unflag"
the file.

That's all it takes!  Iron Ox uses lock files to control simultaneous
use of files, so resources may remain locked if the system crashes while
someone is in the door.  However, each node will clear all of its locks
every time it enters or exits the door normally, so "lingering locks"
will be cleared automatically shortly after they arise.  If you have a
system that crashes frequently, adding a line like "DEL C:\DOOR\IRONOX\*.L*"
to your AUTOEXEC.BAT file will clear all locks immediately when the
computer reboots.

                  COMMON INSTALLATION PROBLEMS

The most common mistake sysops make installing this program is trying
to get too fancy.  Don't copy your door information file to the game
directory.  Don't specify the dropfile path on the command line for
the game.  Don't add a line to your batch file that changes to the game
directory before execution.  Don't add the game to your path.  Just create
a batch file that looks like the one in "INSTALLING IRON OX," above.
Keep it simple.

Here are some installation problems that might come up:

1. The game says it can't find my door dropfile!

   This game assumes that you are running it from the directory where
   your BBS dropfile is located.  Every BBS package I know of normally
   launches door execution from the directory where the dropfile is
   located, but if yours doesn't, you will need to specify the dropfile
   location on the command line.  This is the *only* circumstance in
   which you need to specify the dropfile path.

2. The game works fine locally, but doesn't work over a modem!

   This door does require a FOSSIL driver.  Please verify that you have
   a FOSSIL driver set up for the communications port over which you're
   running the game.  If you don't wish to run a FOSSIL driver all the
   time, you can load one right before executing Iron Ox and unload it
   when the game is done.  Both BNU and X00, the two most popular FOSSIL
   drivers, support this option.

3. I have a high-speed modem.  When low-speed callers go into the game,
   all they see is garbage on the screen!

   If you are using a FOSSIL, try locking the baud rate at which your
   computer talks to your modem (the docs for your FOSSIL driver will
   explain how to do this).  High-speed modems generally perform better
   when used with a locked port, and for some reason, the combination of
   high-speed modem, low-speed connect, and unlocked FOSSIL driver can
   cause problems with this and some other doors.

4. The game runs fine single-node, but if two people try to go in at
   once, I get a sharing violation!

   As I say in the section on multinode setup, either my compiler or
   Quarterdeck's products have a bug that causes sharing violations when
   you try to run an overlaid program multinode.  The work-around for
   this problem is to flag your IRONOX.EXE file read-only using the
   command ATTRIB IRONOX.EXE +R.  Even if you aren't using a Quarterdeck
   product like DESQview or QEMM, give this solution a try:  odds are
   good it'll correct the problem completely.

5. The game is getting confused about what node it's running on!

   Iron Ox is designed to figure out the node ID on which it's running
   from the BBS drop file.  On some systems, however (e.g., RA when
   dropfiles are placed in the same directories instead of unique ones),
   determining the node ID from the drop file is not possible.  If Iron
   Ox isn't getting the node on which it's running right, set a TASK
   environment variable to help it along ("SET TASK=1").

                          CONFIGURING IRON OX

The easiest way to fine-tune the configuration for your Iron Ox game is
to run the utility called OXCONFIG.EXE, included in your IRONOX
distribution archive.  OXCONFIG will let you adjust all options,
explaining the function, default, and recommended value for each option.

OXCONFIG produces a file called IRONOX.CFG, which resides in the same
directory as IRONOX.EXE.  In case you prefer using an ASCII text editor
to fiddling with configuration programs, the following section documents
the variables that appear in IRONOX.CFG and outlines how to modify them
to change your configuration manually.

Keyword     Default           Function

SysopName    No One     This keyword determines the name that will be
                        used when the game describes who it belongs to.
                        If you decide to register this game, you will
                        need to enter your name here exactly as it
                        appears in your registration letter.  This
                        keyword is ignored in unregistered games.

BBSName   Unregistered  This keyword determines the system name that
                        will be used when the game describes the BBS to
                        which it is registered.  See "SysopName," above.

RegCode      (blank)    This is where you would insert the key code,
                        available from the author, that will activate the
                        "registered-only" features of the game.  See
                        "LICENSING/REGISTRATION INFORMATION," below.

Timeout       360       This keyword determines the amount of time, in
                        seconds, that the game will wait between keystrokes
                        before it decides that a user is "sleeping at the
                        keyboard" and boots him/her out.  This game can
                        require thought, so substantially reducing this
                        number is not recommended.  Note:  Timeout is
                        automatically disabled when the game is run in
                        local mode.

MaxGames       3        This keyword determines the maximum number of
                        games a player can participate in at one time.
                        Allowing players to participate in multiple
                        games will increase interest, but setting this
                        value too high would give high-speed callers a
                        big advantage in the monthly standings.  Note:
                        this keyword is ignored (hardcoded to 3) in the
                        evaluation version of the game.

StartGames    TRUE      This keyword determines whether players are
                        allowed to begin new games.  The only time you
                        would be likely to set this value to FALSE would
                        be if you were winding down a tournament with a
                        fixed duration.

Secure        FALSE     If you (the sysop) are playing in games, you
                        might not want to watch as other people play
                        their turns in the games in which you're
                        involved -- you could see something that would
                        give you an unfair advantage.  Setting Secure to
                        TRUE will cause the game to blank the local screen
                        when a remote player is playing in a game in
                        which zero-baud (local) players are involved.

NoLog         FALSE     This option allows you to disable the game's
                        automatic logging feature, which records basic
                        game events and errors in one or more files
                        called IRONOX?.LOG (where the question mark is
                        replaced by the node number).  Turning off
                        logging can save some disk space, but it can
                        also make problem-solving more difficult.
                        Recommended setting is FALSE (does not disable
                        the log).

ANSI_Score    (blank)   This keyword determines the name and path of the
                        ANSI Score bulletin the game will create.  Leaving
                        the space after the keyword blank, as it is in the
                        sample configuration file, indicates that you
                        want the game to create *NO* ANSI score bulletin.

ASCII_Score   (blank)   Name and path of the ASCII high score bulletin.

WC_Score      (blank)   Name and path of score bulletin using Wildcat!-
                        style @ codes.

ANSI_Records  (blank)   Name and path of the ANSI all-time-records bulletin.

ASCII_Records (blank)   Name and path of the ASCII records bulletin.

WC_Records    (blank)   Name and path of the WC-style records bulletin.

DailyPrize       0      You may configure the game to award a daily, weekly,
                        and/or monthly time prize to the current leader in
                        the standings.  A value of 0 disables time prizes.
                        Time prizes are disabled in the unregistered version
                        of Iron Ox.

                        Here are some guidelines on prizes:  the prizes
                        should go from very small (daily) to fairly generous
                        (monthly).  A value of five minutes for daily, ten
                        for weekly, and thirty for monthly might be
                        reasonable.

                        Note:  time prizes only work on systems that reread
                        their door dropfiles on return from a door to
                        determine remaining time, like Wildcat! 3.x,
                        RemoteAccess, and so forth.

WeeklyPrize      0      See DailyPrize, above.

MonthlyPrize     0      See DailyPrize, above.

Note:  if you leave the name of any particular bulletin blank, or do not
include the keyword for it in the configuration file, that bulletin will
not be created.

                              ERRORLEVELS

In case your BBS software reads and uses errorlevels on door exit, here
are the errorlevels Iron Ox returns:

     0   -   Critical Error has occurred!
     1   -   The user has dropped carrier.
     2   -   The sysop has terminated the call; user off-line.
     3   -   User time has expired; still on-line.
     4   -   Keyboard inactivity timeout; user off-line.
     10  -   Normal exit; user on-line.
    255  -   Program integrity problem; please check log and contact me!

                    LICENSE/REGISTRATION INFORMATION

This program is copyrighted shareware.  You are licensed to try this
program for up to thirty days.  After 30 days, if you elect to continue
using Iron Ox, you must register.  The game costs only $20 (see
REGISTER.FRM for information on shipping and delivery options).

Note:  if your registration for Iron Ox is postmarked *BEFORE SEPTEMBER 1,
1994*, you will receive a five-dollar discount on your registration!

The registered version of Iron Ox includes the following enhanced features:

1. OX FACTORY:  Your colonies will no longer have to rely on the supply
   of oxen provided at the beginning of the game.  The game will use
   ore from the store to make more.

2. EXTRA RACES:  In registered versions of the game, three extra,
   specialized races are available to players:  the Photovore, a
   photosynthetic (sunlight-eating) alien who specializes in plants and
   energy-making, the Rubblemuncher, an amazing ore-miner who's
   allergic to luxite, and the Metamorph, a creature who can actually
   *change shape* and assume the abilities of different races during the
   course of the game!

3. MORE GAMES PER PLAYER:  In the evaluation, players are allowed to
   play in three games at a time.  In the registered version, you may
   set this value as low or as high as you like!

4. TIME PRIZES:  If you own the registered version and use BBS software
   that "reads back messages" from doors, you can set (totally optional)
   daily, weekly, and/or monthly time prizes for the leaders in the
   standings!  This feature works on Wildcat!, RemoteAccess, Apex,
   QuickBBS, and many other systems.

Please see REGISTER.FRM to find out how to register your copy of Iron Ox.
Iron Ox is the product of over a thousand hours of work.  I am committed
to supporting and improving Iron Ox (see "Future Plans" for some
indication of what I have in mind), but I need your help to continue
developing enhancements and new features.

                       ADDITIONAL LICENSE INFO

You are allowed (and encouraged) to distribute unmodified copies of
Iron Ox so long as you distribute the complete archive with all files
intact.  You may include unmodified, complete archive versions of the
shareware edition of Iron Ox in software collections (e.g., CD-ROMs)
so long as the documentation for the collection clearly indicates that
it contains shareware products and that the purchase of the collection
does not constitute a license for the use of said products.

Registration of this product entitles you to a unique registration code
keyed to your name and the name of your BBS.  This key will allow you
and your system's users to access the registered-only features of the
program, and will deactivate all messages to the effect that the program
is an "Unregistered Evaluation Copy."  Your registration is good for all
future releases of Iron Ox:  if I should ever need to change the key
system, you as a registered user will be entitled to receive a working
new key via U.S. Mail or electronic mail.

                              SUPPORT

I am anxious for your feedback and ideas.  If you have problems getting
Iron Ox to run, please feel free to contact me.

I can be reached via crashmail or routed netmail at Fidonet address
1:202/704, DoorNet address 75:7619/7, and NeverNet address 42:100/107.

The support BBS for Iron Ox, and for all games by Joel Downer and
Meerkat Software Concepts, is The Dreaming City.  The Dreaming City
has two lines:

Node 1:  USR Dual HST 14.4/ v.32 9600    [phone]
Node 2:  ZyXEL 16.8 v.32bis              [phone]

I monitor the Fidonet DOORWARE and DOORGAMES conferences, and will
attempt to reply promptly to echo messages, netmail messages, and
messages in the IRONOX support conference on my BBS.  I am currently
working on establishing a support echo for my games that may appear
on DoorNet, NeverNet, and eventually on the Fidonet backbone.

Currently, the only way to reach me via the Internet is through my
(seldom-visited) account [e-mail] or through the
@fidonet.org route.  By the time of the next minor release, I should
be able to provide a fast and easy way to reach me using an Internet
address at The Dreaming City itself.

                     IRON OX DISTRIBUTION SITES

The following bulletin board systems are official distribution sites
for Iron Ox and any necessary companion programs.  Note:  this
information was compiled in February, 1994; some of these telephone
numbers will change over time.  If you find that the numbers listed for
systems in your area are no longer accurate, you may be able to find
up-to-date information in a current FidoNet nodelist.

BBS System         Fido Addr   Telephone     Modem        Where

The Dreaming City  1:202/704   619-462-8406  USR Dual     La Mesa, CA
TDC 2              1:202/705   619-462-7146  16.8 V.32bis La Mesa, CA
Alien Biker Kat    1:202/1010  619-277-4140  V.32bis      San Diego, CA
Faust's Dungeon    1:202/124   619-697-0892  V.32         Spring Valley, CA
The Gateway BBS    1:2240/320  810-742-9414  V.32         Burton, MI
The Harry Beast    1:343/102   206-859-6157  16.8 V.32bis Kent, WA
Holston River Vlly 1:3615/42   615-932-1490  16.8 Dual    Knoxville, TN
Holston 2          1:3615/43   615-932-1492  16.8 Dual    Knoxville, TN
Mayberry BBS       1:3663/302  910-789-8183  V.32bis      Mt. Airy, NC
SHC Editor's       1:202/1819  619-563-1598  16.8 Dual    San Diego, CA
Test Pattern BBS   1:259/524   905-890-2531  USR Dual     Ontario, Canada

The following files will be available for download, and for FREQ using
the magic names listed, from all of the distribution sites.  The sites
will carry the latest version of Iron Ox and any support programs by
Joel Downer.  Versions of support programs by other authors will be
recent but are not guaranteed to be the latest.

Magic Name       Description

IRONOX           The Iron Ox doorgame.  (Surprised? <g>)
X00              A recent version of the X00 FOSSIL driver.
BNU              A recent version of the BNU FOSSIL driver.
SIO              A recent version of Ray Gwinn's FOSSIL for OS/2.
OXECHO           Information on picking up the Iron Ox support echo.

                            FUTURE PLANS

I am committed to supporting this program.  When and if I receive
reports of bugs, I will do my best to fix them and release updates
in a timely fashion.

I also am planning to add new features and enhancements to the game --
which and how many depending on the feedback and level of enthusiasm
I encounter in the BBS community.  Here are some examples of additions
that I am *considering* for versions 1.10 and beyond:

1. A full-featured game editor, with an editor for messages and contest
   entries, and an automatic (optional) scanner for "bad words."

2. Internal comm support.  (This is a feature I will only implement if I
   hear from a *lot* of people who want to see it, because FOSSIL
   drivers are an excellent solution for high-performance, reliable
   serial communications.)

3. An option to "Bribe the Land Assessor," by which you could steal
   other players' land.

4. The option to steal from the Bank or the General Store.

5. Sysop-editable, variable messages for common game events (Received
   from the Colony Physician:  "If you need to spew, spew into this!").

6. A "depletion" feature by which players can exhaust the ore and/or
   luxite in mining squares.

7. Full RIP graphics support, including a graphics-mode map with icons
   and mousable game menus.

8. The ability to run under OS/2 native mode (32-bit text mode).

9. Support for multi-BBS "tournament mode."

Your feedback will help to determine which and how many of these
features (and which features that *aren't* listed here) appear in future
versions of Iron Ox.  Needless to say, your support will also make it
possible for me to continue work on this program.

                             DISCLAIMER

Joel Downer and Meerkat Software Concepts make no warranty of any kind
regarding the usefulness, reliability, merchantability, or fitness of
this software and documentation for any purpose whatsoever.  While I
have tested this program thoroughly, I cannot and will not make any
promises that the program will run well or safely on your hardware or
with your particular software configuration.  This software is
guaranteed only to take up disk space, and I make no absolute guarantee
that it will even do a reliable job of that. <g>

Your use of Iron Ox and/or any companion material constitutes your
acceptance of these terms.

                          ACKNOWLEDGEMENTS

As Iron Ox has been my first doorgame programming effort, I owe thanks to
many people for helping me through the process.  Special thanks go to
Dan Roseen and Albin Gersich, two key beta sysops who also have
provided OpenDoors code patches and other programming suggestions that
have made this work much easier.  Thanks to all of the beta sysops, who,
in addition to Dan and Albin, included:  Marty Bogle, Jim Chapman, Randy
Culler, Brenda Donovan, Dave Foy, Paul Fusco, Dan Harvey, Bud Jamison,
and Christian Jones.  Many of the things that *do* work right in the game
are to the credit of these testers and their excellent feedback.  Naturally,
any blame for anything that *doesn't* work is mine. <g>

I've especially appreciated the feedback and encouragement of my key
testers on The Dreaming City, including Greg Allen, Andrew Crispen,
Lynn Kastleman, Bob Nelson, Sue Redding, Jeff Hobbs, and Bud Jamison.
(Yeah, Bud, you get to show up twice.)  The enthusiasm I met on the
"home front" really made a difference.  I appreciate the help of
everyone who was involved in the beta process and beta echo; several
participants in the IRONOX_BETA echo from other beta sites, including
Rich Paul, Chuck Eaves, and Mark Riel, deserve special mention.  If
you were involved and I haven't mentioned you, please forgive me:
it's because I'm an addle-brained programmer, not because I didn't
appreciate your contribution. <g>

Thanks to Gerard Droege for many stimulating conversations about
doorgames and game design, and to Evvie Vincow for putting up with me
and making countless glasses of iced tea.

This door uses the OpenDoors C development system by Brian Pirie.  That
system has saved me countless worries about the details of talking to
the modem, reading dropfiles, etc., and I'd highly recommend it to
any C programmer writing a door.  Thanks also to the original authors
of the Commodore 64 game, M.U.L.E. -- part of the basic design of Iron
Ox was inspired by that excellent game.

Finally, thanks to Gary Martin, Mehul Patel, and Joel Bergen.  If I
weren't such a junkie for their games, I never would have started this
project.