
                           SYSOP Commentary
                           ~~~~~~~~~~~~~~~~


  When I first played TradeWars, I thought it was the greatest game I'd 
ever seen on a bulletin board system!  The concept developed by Chris 
Sherrick and the implementations of the game by John Morris stand high in 
my mind as true genius.

  TradeWars has spawned numerous "clones" and inspired other authors to 
develop other games (PowerStruggle is an excellent game and also an 
excellent example of this).  This game is a descendent of TradeWars ... re-
coded at first to solve "glitches" ... then recoded again for optimum speed 
and to minimize the constant disk thrashing of the original ... then 
modified to run under all versions of RBBS ... then coded from the top to 
the bottom in code to add new features, dramatically change the depth of 
the game and variety of strategies available to players, and to give the 
game a goal.  The code was again modified in mid-January to support either
RBBS or PCBoard ... and more cosmetic changes were performed.

  Between January and May, many more features have been added to the game 
and key parts of it speeded up a LOT.  The program now also supports more 
varieties of BBS software and 19200 baud modems.

  Almost any game has glitches and bugs -- Tradewars in any of its versions 
is no exception.  I hasten to add that M.O.T.U. may very well have bugs too 
-- but it was beta tested on 4 bulletin board systems in the Washington D.C.
area before being offered to anyone, even in the demo version.  Comments,
suggestions, and "bug reports" have been incorporated in this version you now
have.  If you have been running the demo version, see if this code doesn't
solve any problems your users may have reported.  All fixes and enhancements 
have been made to the full-release code, but not necessarily in the demo code
you may have run.

  Most RBBS door games are version-specific ... I got tired of not being 
able to run 14.x games in 15.x, got more frustrated when my 15.1a and 15.1b 
doors wouldn't run under 15.1c -- and trembled to think about keeping my 
doors "open" under 16.x and later.  Most door games refer to your RBBS-
PC.DEF file to pick up your name (SYSOP's first & last, the board's name, 
the comm port you're attached to, and where to find RBBS's MESSAGES file).  
From the messages file, the program can learn who the caller is, his speed, 
baud, etc.  If you're running a single node system (I am) then only the 
first 256 bytes of the messages file is significant.  If you are running 
almost ANY door out of a subdirectory, all you need to do is snatch the 
first 256 bytes, copy into a file named MESSAGES in the current 
subdirectory and you're in business.   The location of the needed info from 
the messages file hasn't changed (will not change?) between versions of 
RBBS.  The RBBS-PC.DEF file is a horse of another color.  SO -- this door 
game uses a file YOU create, called MOTU.DEF -- which contains ALL of the 
information normally needed from the RBBS-PC.DEF file.  Thus, this door 
should be backwards compatible with all versions of RBBS and also into the 
future.

  Running MOTU, you do NOT need to copy (all or part) of the messages file.
That option is only mentioned for those of you having problems with other
door programs -- or those of you concerned that giving any program access
to "real" files could injure your BBS.  Then just create the "snatched"
fragment of the messages file (as outlined above) and give the path\file-
name of the "fake."

If you run PCBoard, read on ... this door should work under your system
too -- just ignore the preceeding commentary about RBBS.

If you run WILDCAT! and are tired of having door programs that don't 
directly support your system -- forcing you to use messy utilities to 
"fake out" the game -- this door should now work fine as a "live program"
without the need for any of that bother.


Contents of this disk:
~~~~~~~~~~~~~~~~~~~~~

Filename
--------
MOTU.    DEF       example of .DEF file I use
MOTU.    DOC       on-line instructions for players
MOTU.    EXE       the main "driver" program
MOTUEDIT.EXE       the MOTU editor
MOTUINIT.EXE       the program that initializes the game
MOTUREDO.EXE       the program that re-cycles the game
OPENC.   DAT       the ANSI opening screen
OPENG.   DAT       the ASCII opening screen
README             this file


Installing MOTU for the First Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Choose a subdirectory from which to run the game.  Put all of the files 
on this disk (except for this file) into your subdirectory.  Log into that 
subdirectory.  Run MOTUINIT.EXE and answer the few questions it'll ask.

  Modify (or create) your MENU5 in RBBS (the doors menu) to add MOTU to 
your list of available doors.

  Create a MOTU.BAT file, along the following lines (assuming that RBBS is 
running in C:\BBS and MOTU will run out of C:\MOTU)

COPY CON MOTU.BAT
CD \MOTU
MOTU x           <== where x = RBBS node #
                     under other bbs software, this 
                     command line entry is not needed.
CD \BBS
           <at this point hit F6 key then <ENTER>

This MOTU.BAT file should be in the same subdirectory as RBBS

Other parameters are available for the command line too - see later
discussion.  I would guess that for 90% + of all sysops, the minimal batch
file illustrated above will be sufficient.


Answering the Initialization Questions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Only a few key questions will be asked you: How long may a user stay in the 
door? [recommend 30 minutes or less]; How long before hanging up on an idle 
user? [recommend 1 or 2 minutes]; Will you permit aliases in the game? [yes 
promotes more fun]; What is name of bulletin you'd like updated with the 
MOTU scoreboard? [here, if your RBBS bulletins are in C:\BBS and you've 
decided BULLET10 is the MOTU scoreboard, you'd enter C:\BBS\BULLET10]


Making Up Your MOTU.DEF File
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Refer to example included.

Line 1: your first name
Line 2: your last name
Line 3: path\filename for your RBBS MESSAGES file
                                                   *** for PCBoard *** 
                                                   enter path\pcboard.sys
                                                   *** for WILDCAT! ***
                                                   enter path\callinfo.bbs
Line 4: COM1 or COM2    <=== all caps, no ":" (COM0 also valid entry)
Line 5: your bbs' name


If (the rightmost 3 characters of) what you entered on line 3 ends with 
"SYS" then the program will attempt to read  "path\filename" as a PCBoard.SYS
file.  If what you entered on line 3 ends with "BBS" then the program will 
attempt to read "path\filename" as a WILDCAT! `live program' door user file
(CALLINFO.BBS, as documented 5/7/88 for version 1.12).  Otherwise 
"path\filename" is read as an RBBS MESSAGES file.


Files Initialization Program will Create
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

MOTUDATA.DAT        the main database of info about the universe.
                    MOTU will self-initialize with 12 planets in it.
MOTUNAME.DAT        this file will exist ONLY if you've chosen to
                    allow users the fun of using aliases in the game.
MOTUSMSG.DAT        this is a running SYSOP's log of what's going on in the
                    game ...  you may want to copy this periodically to 
                    somewhere users can view it.
MOTURMSG.DAT        used for radio communications between players.
MOTUPMSG.DAT        used for reports generated internally by program, to 
                    tell player what's happened to him since last on.
MOTU    .DAT        this contains control information for MOTU, based upon
                    your responses while in MOTUINIT ... this file does not
                    exist in the demo version (nor is it needed by DEMO).

You may periodically delete the MOTUSMSG.DAT file, or choose inside the 
MOTUEDIT program to disable this file's use.


IF YOU HAVE BEEN RUNNING AN EARLIER VERSION (FULL RELEASE) OF MOTU:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You already know how to set up the game -- just "drop in" the new *.exe
files on top of the older versions -- all changes are 100% backward
compatible.  The MOTU.DOC file has also been revised, so replace the older
version with this new one.

Features added since original release of MOTU:
 (1) combat between large fleets is tremendously speeded up.
 (2) a slightly better line noise filter has been installed.
 (3) a new class of player (arms dealer) has been added.
 (4) a flashy "credit line" has been added to the color caller's
     opening screen -- when someone has won the game.
 (5) MOTU now should run under a greater variety of BBS software
 (6) new (optional) command line parameters available - solves the
     19200 baud modem "problem"
 (7) if a player kills another, now he may also get some portion
     of the killed player's cash (if any)
 (8) the aliens will now swarm around more, but in smaller scouting
     groups.
 (9) numerous other cosmetic and minor changes - your users will
     find some surprises!
(10) the supporting programs (MOTUINIT.EXE, MOTUREDO.EXE, & MOTUEDIT.EXE)
     have all been revamped ... of course, if you have the game running
     already, you won't need to bother with the new MOTUINIT.EXE.


IF YOU HAVE BEEN RUNNING THE MOTUDEMO Program
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You should love the changes between the dem version and this one!
Carefully review this file and the on-line help file MOTU.DOC.

The demo versions did not allow aliases.  If you now choose to allow 
aliases, then the game will have to be recycled.  Run MOTUINIT and follow 
steps above for starting from scratch.  If you want to keep an existing 
game going, two choices:

(1) open the full version as a separate door (MUST then be in a separate
    subdirectory!! - otherwise both games will access same database!)
(2) the full version is backwards compatible with the demo version, but
    you'll have to:
    (a) NOT run MOTUINIT
    (b) make up your own MOTU.DAT file
        Contents of MOTU.DAT:
        ~~~~~~~~~~~~~~~~~~~~
      line 1: MOTUBULL  <=== you weren't given a choice about the name
                             of the scoreboard file in the demo version;
      line 2: 2         <=== you may now substitute some other value, this
                             is amount of idle time before logoff.
      line 3: 0         <=== zero ... must be zero!  If you enter ANY other
                             value, you will enable ALIASES -- this means 
                             that the next time any of your users play the
                             game, they will be treated as new players!!
                             You would wind up with 2 "players" with the
                             same name ... one is an alias, one is real. DO
                             NOT attempt backward compatibility without
                             setting this line to 0 !!!!
      line 4: 30        <=== or some other value -- this is total time user
                             is allowed in the door.  Was preset in demo.

The entries made in the file MOTUSMSG.DAT by the full release are clearer
and cover more events (bribes, etc) than in the demo version.  Suggest that
you may want to delete your old MOTUSMSG.DAT file ... and then periodically
copy this file into an area publically viewable.  sometimes sensitive info
was printed in this file by the demo version -- everything now should be
safe for public consumption.


BUG Report - in MOTUDEMO
~~~~~~~~~~~~~~~~~~~~~~~~

  Cash transfer didn't work right in the demo package ... this
problem won't happen in the full version.

  The opening ASCII screen (OPENG.DAT) ... would pause in mid-screen.  A
minor annoyance, now fixed.

  The sysop's log (MOTUSMSG.DAT) was too cluttered, contained some sensitive
info users shouldn't read, and left unreported some interesting events.  All
taken care of in this version.  Since it is now more legible and DOES contain
some interesting info -- I'd suggest to you that your callers may like to see
periodic copies of the last 24/48 hours worth of stuff.


What the Hell is MOTUREDO?
~~~~~~~~~~~~~~~~~~~~~~~~~
  This program is very much like MOTUINIT, it will recycle the game, it will set everybody back to zeroes, etc.  It will not require SYSOP input, nor will it reset any SYSOP-set conditions of the game.  It will remember everyone's alias (if that had been allowed), but will treat them as new users, once the game is recycled.  If some player becomes Master Of The Universe (MOTU) he is given the option each time he quits the game of recycling.  If he elects that option, this program does it.


What about the MOTUEDIT Program?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Well, I've tried to make the whole thing as self-explanatory as possible.  
A bit of advice ... if you don't understand what you may be changing ... 
DON'T change it!

  You can get a recap of all the players in the game, or choose to edit an
individual player.  You're then told what you can change.

  You can review a sector and change some aspects there ... you can add a 
mine, sweep out a mine, leave fighters defending the sector, etc.  Be 
careful as you do this!!  You can leave fighters (attributing them to some 
player) in a sector in which it is illegal for the player to leave 
fighters.  Similarly, you can drop mines (attributing it to some player) 
but if the player to whom you give credit for the mine could not possibly 
have bought one, you'll be accused of manipulating the game.  You can also 
REMOVE mines from a sector, probably then nobody will catch you.

  You can rename or delete planets ... usually, unless the name chosen by 
someone is gross, why bother?

  You can move the aliens around ... but you can NOT override bribes ... so 
do it if it feels good, otherwise leave `em alone.

  You can get a report of where all the space mines have been dropped ... 
if it displeases you, then you'll have to enter the sector editor to clear 
` em out.

  A final function of the EDIT program may be to give you a review of 
what's going on ... without you intending to change anything at all ... 
that's probably best of all ... the game can very well attend to itself.


What to Do if You're SURE Something is Wrong
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Write, or call my board (703)590-1441 [not PC Pursuitable].  Make a screen-
dump showing the problem.  Tell me the circumstances that led to the 
problem. (Get your users to help).

If you can identify a problem and define it well enough that I can 
reproduce it, then I'll fix the problem and try to make arrangements with 
you to get corrected code to you.


Recap of Sector Restrictions:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  No fighters may be left (by players) in sectors 1-25, 201-210, 401-410
..Since you're GOD-like in YOUR powers, you can use the editor to drop
  fighters anywhere ... but players will sense this divine intervention.

  Merchants are stuck in sectors 1-100
  Traders are stuck in sectors   1-300
  Warlords can go anywhere.
  Arms Dealers can go anywhere.

  Player's category is re-evaluated after each hold acquisition (purchase,
won through combat, won in the lottery) and every time a player buys a
planet.  If you were "horsing around" and used the editor to take away
a Warlord's holds, then when he is next evaluated (and perhaps is then
a lesser status) -- he would not be able to move!! (if he was in restricted
space)  Most likely, all surrounding sectors would be forbidden to him!
You'll have a VERY frustrated and angry player.  Fair warning (AGAIN)
that you can achieve illogical results from your tampering with the
editor.


A Word about How BRIBES Work
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Three groups of aliens (groups 6,7 &8) will accept bribes.  The player is
NOT told at the time of making the bribe offer which group is accepting the
bribe.  Offers of less than 4950 credits make the aliens mad!  Offers are
not accepted by a group unless at least 10% more than the last bribe they've
accepted that day [in strict compliance with the "alien code of honor"].

An example -- the day starts off with all 3 groups unbribed (they carried out
their "contracts" during the maintenance run.  Let's say a player offers a
bribe of 5,000 credits ... group 6 will accept the bribe.

now suppose player number 2 offers a bribe of 6,000 credits.  Since that is
more than 10% above the current bribe, group 6 will snap up that bribe too!
(leaving player number 1 out in the cold).

now player number 3 offers a bribe of 5000 credits.  Group 6 will pass, but
group 7 will take it.

now player number 4 offers a bribe of 5000 credits.  Group 6 will pass, 
group 7 will pass, but group 8 will take it.

player 5 offers bribe of 5500 credits -- Group 6 passes, group 7 takes new
bribe.


all this activity will show up later when you let the users read the
MOTUSMSG.DAT file.

WARLORDS, because of their huge capacity to raise cash are always bidding
for the services of group 8 only.  To permit them to bid for the other 
2 groups would effectively take them out of the reach of lesser players.

Bribed groups begin moving from wherever they may have last come to rest.
(If depleted, they are regenerated).  They move along the shortest path 
toward the sector in which their victim waits.  They will attack any player's
fighters they encounter along the way that are defending a sector.  Unable
to restrain their blood-thirst, they will also mount at least a small attack
against at least one player in any sector they pass through (if a player is
unlucky enough to lie in their path, regardless of whether that player has
all of his fighters nestled safely inside his mothership).  Once they reach
their goal, if the victim still is alive, they throw all forces against
that player.

SYSOPs note -- the alien's forces grow stronger as they move to higher and
higher levels!!  Warlords, in order to escape their frenzied activity in
the high reaches of the universe, may want to "rest" after each day's turn
in the lower levels ... but then they can be found (and attacked) by the
little players!

Alien group 9 is a special attack group that ALWAYS goes after the top
player.  If that player has been killed by the other groups then this group
may or may not attack anybody.  Same increased strength factor as for other
groups in higher sectors.

Alien groups 1 and 2 roam through sectors 25 - 100.  Groups 3,4,& 5 usually
go after "bigger fish" in sectors 101 - 500.


Running MOTU Under Different BBS Software:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  MOTU was designed and tested running under RBBS 15.x and 16.x.  MOTU also
has been tested to work under PCBoard 12.x.  Based upon preliminary specs
for PCBoard 14.x -- MOTU should work under that version too -- see later 
comment about command line parameters.

  MOTU should also work under WILDCAT! -- without the need for any utilities
to create a pcboard.sys file or rbbs messages file, etc.  If you have a 
MOTU.EXE file with a compilation date of May 14, 1988 or later.  See earlier
discussion about creating the MOTU.DEF file.


Additional Command Line Parameters:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  The minimal command line in your door batch file is:

                   MOTU                   (no parameters)

  If you are running RBBS and you are not running the door from node 1, then
you must specify the node number as the FIRST parameter (e.g.  MOTU 2)

  Other parameters -- which are ALL OPTIONAL -- include:

                   /P=14     (e.g.  MOTU /P=14)  if running under PCBoard 14

                   /E        (e.g.  MOTU /E) if you allow aliases and if
                             you want the alias file reset whenever a
                             player becomes MOTU -- default is to preserve
                             the alias name file.

                   /C        to force the com port open at some speed other
                             than the caller's baud rate (for example, the
                             USRobotics HST modems can always "talk" to the
                             caller at his speed, while the board always
                             talks to it at 19200.) If you have a setup like
                             that, then use this parameter.  A plain "/C"
                             will open the com port at 19200.  You may also
                             specify a speed (e.g. /C=19200).  MOST SYSOPS
                             DO NOT NEED THIS PARAMETER!

  Parameters may be specified in any order (except RBBS Sysops must specify
node # first (if not node 1), for example:

                  MOTU /E /C  (forces comm. port to 19200 and resets aliases
                              after somebody wins the game)


Map of the Universe:
~~~~~~~~~~~~~~~~~~~~

  Sigh ... everyone thinks they need a map of the universe -- ok, here is a 
representation (generally) of what's going on.  Remember that the rules 
forbid access to certain areas to players of certain levels!  So, if you go 
"moving" sectors around, the results may seem illogical to the players.  
Don't do it!

  there are two patterns:
    (1) 19 repetitions of pattern 1 (each is 25 sectors);
    (2) 1 occurance of pattern 2.

  each layer has multiple sectors that are tied into sectors in other 
layers, with no general rule applying, other than that "corners" frequently 
tie into other corners, centers to other centers.

pattern 1 (illustrated for sectors 1-25), repeated for all 25-sector 
layers, except for sectors 76-100:


                21 -- 22 -- 23 -- 24 -- 25
                 :           :           :
                 :           :           :
                20 --  7 --  8 --  9 -- 10
                 :           :           :
                 :           :           :
                19 --  6 --  1 --  2 -- 11
                 :           :           :
                 :           :           :
                18 --  5 --  4 --  3 -- 12
                 :           :           :
                 :           :           :
                17 -- 16 -- 15 -- 14 -- 13


(you may notice that numbers are assigned in a spiral fashion, clockwise
out from sector 1 -- although they're not connected that way.) Same pattern
is found in sectors 201-225 (for example), but all numbers are higher.


pattern 2 (sectors 76 - 100):

                           85--
                           :   \
                           :    84
                           :   /
                           83--
                           :
                           :
                           82
                           :
                           :
                           81
                           :
                           :
   76 -- 77 -- 78 -- 79 -- 80 -- 86 -- 87 -- 88 -- 89
                           :
                           :
                           90
                         /    \
                         :    :
                        91 -- 96
                         :    :
                         :    :
                        92 -- 97
                         :    :
                         :    :
                        93 -- 98
                         :    :
                         :    :
                        94 -- 99
                         :    :
                         :    :
                        95 -- 100


If you think this sector cluster's layout looks like a "stick-man" you have 
a very vivid imagination! (Since I'm a lousy artist, this is the best 
rendition I can give you of what the MOTU might look like.  It may not be 
funny, but it IS a mild attempt at humor.  Something all sysops need to get 
through the day.)

Opening graphic screens by Bob Snyder, who can be reached at the 
DGS Alpha BBS (703) 323-6423 [Northern VA, PC Pursuitable.  Bob specializes
in the custom design of ANSI screens and issues amusing and interesting 
screens each month for SYSOP's use.  These screens are available for 
downloading about the first of each month from the DGS Alpha BBS.  Bob also 
takes on individual, special orders -- if you'd like him to design a special 
"logo" effect for your board, leave him a message.



Phil DeWitt                     the RE/BBS
P.O. Box 2994                   (703)590-1441  3/12/2400 baud
Manassas,VA 22110               (NOT a "Pursuitable" #)
