
                   WIZARD'S ARENA -- RELEASE 1.37
             (C) Copyright 1991,1992 by Douglas Summers

                            CONFIGURATION



THE CONFIGURATION FILE

Beginning in version 1.22, WIZARD'S ARENA will get its parameters
from a text file rather than from the command line.  This file is
named "CONFIG.WA".

Running the upgrade program will generate an initial CONFIG.WA, which
you may then edit using any simple-ASCII text editor.  If none was
made, then you should begin with a nice, blank one.

CONFIG.WA is a simple text file, made up of individual lines.  Each
line is of the format "aaaa=bbbb" where "aaaa" is the name of some
parameter and "bbbb" is the value to be assigned to it.  For example,
the line

				BBSNAME = The Truly Massive BBS

is used to set the name of the BBS to be "The Truly Massive BBS". The
equals-sign may be preceded or followed by any number of spaces.  The
line, as well, can have spaces before the parameter-name and after
the last character of the value.  Such spaces will be ignored. The
values are case-insensitive:  BUT THE EXCEPTION IS THE BBS NAME,
which IS case-sensitive.

You'll note that a lot of the configuration options are related to
error-correction.  This doesn't mean that the game is particularly
flimsy;  they're mostly stuff I found useful in developing/debugging
and saw some real-world use for.



GENERALLY-AVAILABLE OPTIONS


	BBSNAME
	
	This sets the name of the BBS.  You MUST have this one, and,
	unlike all the others, is case-sensitive.  Please, please note
	that the name, once you've registered, must remain fixed.
	Changing it will invalidate your registration, and you'll have
	to contact me give you a new registration sequence.


	DEBUG
	
	This forces extensive debugging information to be collected.
	DON'T USE THIS UNLESS YOU REALLY NEED IT.  There is no built-in
	method to clean up the huge ERRORS.OUT file that will be
	generated.  Turn this on with "DEBUG = Y" -- anything else means
	debugging is off.


	REMOTECOLOR
	
	This is used to set the color the user's screen is set to
	when the program terminates. There are 16 possible settings:
	BLACK, BLUE, GREEN, CYAN, RED, MAGENTA, BROWN, DINGY
	(lo-intensity white), GRAY (hi-intensity black), HIBLUE,
	HIGREEN, HICYAN, HIRED, HIMAGENTA, YELLOW and WHITE.


	LOCALCOLOR
	
	Like REMOTECOLOR, but applies to the local terminal.


	PARANOID
	
	Used to disable the "backdoor" functions.  These functions are
	debugging aids that the author thought might be handy to leave
	in, because they can be used to perform a certain amount of in-
	situ diagnosis.
	They are available as unlisted commands.  To see them, type "&"
	for your action; nothing will happen; then enter one of the
	following:

		"M" shows memory available
		"E" dumps out the error log
		"S" prints out certain game statistics
		"K" echoes back key-codes
 
	There aren't any others.  Unless you're REALLY, REALLY afraid
	that this information seriously compromises your BBS, you might
	want to leave them available in the event a problem DOES occur.
	Turn this on with "PARANOID = Y" -- anything else means that
	paranoia is off (the functions are available).


	PORT
	
	If you have nonstandard comm port or are using a fossil driver,
	you can tell the game about it with the PORT parameter.  The
	format for this parameter is: "PORT = aaa:i", where "aaaa" is
	the base address and "i" is the interrupt.  For example,
	"PORT = 02F8:3" sets the system to use a com-port whose base
	address is 02F8 and which uses IRQ 3.
	For fossil drivers, use "PORT = F:n"  where "n" is the number
	of the com-port to use the fossil driver on.


	DOORFILE
	
	Gives the full path-and-filename of the BBS's door-information
	file.  This parameter can be overridden by the command-line, but
	if no parameter is given there, then this is the file used.


	SEMAPHORE
	
	WIZARD and WA-UTIL make a special semaphoring file to prevent
	either program from running while the other is active.  If the
	various nodes of a LAN BBS have their real-time clocks seriously
	out-of-sync, the technique employed becomes useless.  If that
	is the case, set semaphoring off via a "SEMAPHORE = NO" line,
	and handle such protection in your batch file.

  

OPTIONS AVAILABLE ONLY TO REGISTERED SYSOPS

After you've played the game and been vastly impressed by the
sheer genius of it, you can send me money.  I'd like that.
(The SYSOP.TXT file gives details on how much and where; for now,
I'll take it as read that you've done that.)

What you'll get back for your hard-earned cash is an eight-digit
registration code.  You should put it in your CONFIG.WA file,
where the game can find it and reward you for your generosity.

You will, at that point, have access to a number of other parameters
which will allow you a fair amount of customization.


	APDIV, APMULT
	
	Every creature in the game -- monsters and players alike -- 
	receive a certain number of Action Points (APs) every day.
	These determine how much a creature can do; every action
	(with only 1 or 2 exceptions) costs APs, and when a creature
	uses up its APs, it has to stop for the day.
	These two parameters help determine how many APs everyone gets.
	The process is:

		If a creature has an Agility of less than (or equal to)
		15, it gets a number of APs equal to its Agility rating.

		If its Agility is 16 or more, it gets 15 AP, plus a certain
		number determined by this formula:

				 ((Agility - 15) * APMULT) / APDIV

	For example, let's say you've set up "APMULT = 2" and "APDIV = 3".
	A creature with an agility of 5 gets 5 AP (and is pretty much a
	sitting duck).  Another creature, with an Agility of 47, will get

					((47 - 15) * 2) / 3 = 21 AP.

	Why would you want to do this?  If we simply let the number of AP
	equal the Agility rating, a player could quickly get to a rating
	of 50 or more -- which would allow him a great many attacks, if
	he didn't have to move far to get to his target.  If his target
	is a monster, that's not so bad -- but if its a player, it isn't
	really fair.  The other player could be taken completely unawares
	and be destroyed by someone he didn't even know was there.  In a
	sense, these values set the "dangerousness" of the game: the degree
	to which a player must take precautions against unexpected attacks.


	MONSTERSPEED
	
	If you want the players to be mobile, but not the monsters, then
	simply setting APMULT high won't really accomplish what you want.
	The monsters will also be fast -- and if one happens to "pop in"
	adjacent to a player, he could get in a great many whacks before
	the player has a chance to do anything about it.
	The MONSTERSPEED parameter determines the rate at which the
	monsters expend AP to do things.  For example, if the MONSTERSPEED
	is 0, it costs them 5 times as many AP to do anything as it does
	the players -- which means that they're slow and don't attack
	often.  Setting it to 9 makes them about twice as mobile as the
	players -- and very dangerous.  (It can be set all the way to 20).
	If you want the players to focus on each other, set MONSTERSPEED
	low; if you want them to become monster-obsessed, set it high.

 
	ABSENCES
	
	The game only allows 64 players.  If players try the game once,
	and never come back, then their player-records would sit around
	forever.  The game, to get around this, counts the number of
	"absences" a player has (the number of days since he last played).
	If that number exceeds the ABSENCES value, his character suffers
	a heart attack and leaves a corpse on the map, and his player-
	record is made available for the use of other people.  Setting
	this value low is probably unfair;  setting it too high might cause
	the clogging earlier mentioned.  The default value of 14 seems
	reasonable, but your circumstances might dictate something else.

 
	TRAINCOST, TRAINSLOPE
	
	Players gain experience by killing monsters (or other players).
	They trade experience points (via the "Train" command) for 
	higher characteristic values, or for spell proficiency.  This
	has the net effect of making them more powerful.
	By default, it always costs 100 XP to train.  These two parameters
	allow you to change that.
	TRAINCOST determines the number of XP necessary to train the first
	time.  Each successive training costs the same amount, multiplied
	by 1% of the TRAINSLOPE value. an example will make that clearer.
	Lets say you've set "TRAINCOST = 50" and a "TRAINSLOPE = 250".
	A player will need

						  50 XP to train the 1st time,
			 50 * 2.50 = 125 XP to train the 2nd time,
			125 * 2.50 = 312 XP to train the 3rd time,
			312 * 2.50 = 780 XP to train the 4th time,

	and so on.  The net effect is to make it harder and harder to
	train, so that players do not too quickly become massively
	powerful.  This particular TRAINSLOPE value, though is much too
	steep.  It was chosen as an example only.  I more reasonable
	value might be "TRAINCOST = 50" and" TRAINSLOPE = 110":

							 50 XP to train the 1st time,
			50 * 1.10 =  55 XP to train the 2nd time,
			55 * 1.10 =  60 XP to train the 3rd time,
			60 * 1.10 =  66 XP to train the 4th time, and so on.

	It will never cost more than 20000 XP to train.  Players begin
	with an XP allotment of eight times the TRAINCOST value.

 
	MONSTERPROB, OBJECTPROB
	
	The daily maintenance routines put out monsters and random objects
	like swords and shields.  Each space on the map is examined,
	and may have a monster or object put into it if it is already
	empty (and if the type of the terrain permits).  The probability
	each space has of generating a monster is given by MONSTERPROB;
	the probability of generating an item is given by OBJECTPROB.
	Both are expressed in "chances per 10000" form.
	For example, lets say you have set "MONSTERPROB = 80" and 
	"OBJECTPROB = 100".  This means that each empty space has a 0.8%
	chance of getting a monster each day; a space that doesn't get a
	monster has a 1.0% chance of getting an object.
	These probabilities might not sound like much, but over the whole
	map, they add up.  The map is (at present) 100 x 50 -- the settings
	indicated would generate about 40 monsters PER DAY -- and about 
	50 objects.
	There is an added complication, however: not all of the map is
	necessarily given a chance to generate.  Only the areas around the
	players can generate.  This keeps huge numbers of monsters and
	objects from being generated in unvisited rooms and hallways,
	thereby clogging the system.

 
	MAGICPROB
	
	This gives the probability (in chances per 10000) that a given
	object dropped during daily maintenance will be enchanted.  It
	defaults to zero, so non-registered sysops never get this.
			 

	EXTERMINATION
	
	Monsters that are far away from any player are pretty much useless.
	They wander around, taking up precious time during the daily
	maintenance and no-one would ever miss them if they disappeared.
	So the system may decide to simply erase them.  It will do so a
	certain	percentage of the time, as given by the EXTERMINATION
	parameter.
	It is expressed in 10ths-of-a-percent form, so an "EXTERMINATION =
	250" gives each such "lonely" monster a 25% chance of being snuffed
	out each day.  Monsters Controlled by players, and those under
	spells, and those carrying "interesting" items, are exempt from
	this form of extermination.

 
	CACHE
	
	The game internally caches certain database operations for reasons
	of efficiency.  If the game is running a little slow on your BBS,
	try setting the this option to higher values.  (It isn't a simple
	number-of-kilobytes measure).  Experimentation will probably pay off,
	and can't hurt you.  Try "CACHE = 300" for best results. If the
	system can't allocate that much (it would take about 64k), then
	it will automatically downscale the cache and try again.
	I've found that this doesn't make as much difference as one might
	hope; there's roughly a 30% speedup with "CACHE = 300" (which is the
	maximum).  A REAL disk cache would make a LOT more difference.

 
	TIMEALLOWED
	
	Allows you to set the maximum time (per day) that a player can stay
	in the game.	For the unregistered sysops, that number is equal to
	the players' total remaining time on the BBS.  For registered sysops,
	it is the lower of that value and the value provided with this
	option.  (Multiple entrances to the door will NOT allow the player
	more time -- it adds up).  I don't think this one will matter much
	to most people, since it seems that a typical "session" of WIZARD'S
	ARENA is not very long.  Still, if you want to limit your players
	to only 5 minutes, use "TIMEALLOWED = 5".


	HELLOMSG
	
	If you want to send a short message to all the players as they
	log onto the game, you can assign one with the HELLOMSG parameter.
	Simply make a line like the following:

		 HELLOMSG = Your sysop sends you greetings, mortal.

	and the user, after seeing his mail will see that on in the
	text-area of the screen, just before the "You are in Wizard's
	Arena" line.  You could, for example, use this to remind non-
	registered users that they might like to register.


	AUTOSAVE
	
	Setting this parameter on (i.e., "AUTOSAVE = Y") will cause the
	game to back up the databases before the game, and, if an error
	occurs, to restore from this backup when the next player logs
	in.  This won't obviate all errors -- some types of error might
	cause the game to terminate OK but leave the databases in a bad
	state, for example.  It by no means replaces regular backups.


 	REGISTRATION
 	
	Sets the key sequence -- see SYSOP.TXT for details on registration.


 	STARTBONUS
 	
	A player is given a certain number of extra AP on the first day
	he's in the game.  The default is 10;  this option lets you change
	that value.  Setting it higher lets new players move around more,
	explore farther and play longer on their first move, which lets
	them have a greater chance of survival.


 	AUTOVALIDATE
 	
	When a player enters the game after another player has bombed
	out, the system will try to fix the databas. The map, for example,
	can be corrected from a copy kept of the original map.  If a
	persistent problem comes up, you can set this option on (via
	"AUTOVALIDATE = Y") to force validation even if the system hasn't
	bombed out.


 	FRATERNITY
 	
	You can disallow fraternity membership to your players by setting
	"FRATERNITY = N".  The idea here is that if you maintain seperate
	configurations for your registered and unregistered users, it
	becomes possible to only allow registered users to join frats.
	By default, "FRATERNITY = Y", meaning that players by default
	are able to join frats.


 	MIDNIGHT
 	
	The game uses the computer's real-time clock to determine if
	daily maintenance should be run.  This is perfectly reasonable,
	unless you do the maintenance off-line at some hour other than
	midnight.  If this is the case, a user who logs in AFTER midnight
	but BEFORE your off-line processing will trigger the daily
	maintenance.
	You can change this by telling the game never to perform daily
	maintenance before a certain time of day.  If, for example,
	your off-line stuff happens at 4:30, you might set "MIDNIGHT=4:45"
	(to allow some leeway).  The WA-UTIL program will IGNORE this
	parameter -- it is assumed that the time you call WA-UTIL is
	when you want the maintenance to occur.


	FREEMOVE
 	
	For sysops who like a more wide-open game, movement can be made
	free (for players).  By setting "FREEMOVE = Y", all players
	(but not monsters) will be allowed to move as far as they like
	each day.


	MAPPING
 	
	If there is a shortage of RAM, sysops can turn the MAPPING
    feature off.  This will only save about 1K, though.


    SPELLTHRESHOLD
    
    If spell "A" is a prerequisite for spell "B", then a player
    must have a proficiency of SPELLTHRESHOLD with spell "A" to
    study spell "B".  By default, the value is 80.

	
    GARBAGE
    
    This parameter gives the percentage chance for a "generic"
    item to be cleaned up (destroyed and removed from the map).
    Items will only be destroyed if they are not carried, and
    if they have no spells on them.  The percentage chance is
    per day, per item and defaults to 0.  If your map tends to
    get cluttered with swords and shields and whatnot, set this
    parameter higher (to 10 or even 20, for example).


A FURTHER NOTE

Monsters move entirely during daily maintenance.  So setting
MONSTERSPEED high when you have a lot of monsters running around will
make the daily maintenance go slowly -- perhaps several minutes.  The
same caveat applies to the APMULT and APDIV parameters: if monsters
have a lot of AP to spend, they'll take a little longer to spend it. 
So experiment around with good trade-offs between the speed of your
system and the effects you want to produce.



THE DEFAULTS

Your CONFIG.WA file MUST specify a BBSNAME.  The REGISTRATION
parameter is only meaningful if you've bought a registration sequence
from the author.  By default, DOORFILE isn't defined, which means
that the door-information file must be specified on the
command-line.  Also, the PORT parameter is not defined, which means
that comm-port info is derived from the door-information file.

The other parameters default as follows:


	DEBUG			= N
	REMOTECOLOR		= WHITE
	LOCALCOLOR		= WHITE
	PARANOID		= N
	APDIV			= 2
	APMULT			= 1
	ABSENCES		= 14
	TRAINCOST		= 100
	TRAINSLOPE		= 100
	MONSTERPROB		= 50
	OBJECTPROB		= 60
	MAGICPROB		= 0
	MONSTERSPEED	= 2	
	TIMEALLOWED		= 60	
	EXTERMINATION	= 250
	AUTOSAVE		= Y
	STARTBONUS		= 20
	AUTOVALIDATE	= N
	SEMAPHORE		= Y
	FRATERNITY		= Y
	MAPPING	        = Y
	SPELLTHRESHOLD	= 80
    GARBAGE         = 0

A sysop who wishes to favor his registered users over the unregistered
ones might set up two files, one named REG.CFG and the other named
UNREG.CFG.

For example, REG.CFG might contain:

	TRAINCOST		= 100
	TRAINSLOPE		= 100
	TIMEALLOWED  	= 60 
	BBSNAME	  		= The Example BBS
	REGISTRATION 	= 55555555

and UNREG.CFG might have:

	TRAINCOST		= 100
	TRAINSLOPE		= 110
	TIMEALLOWED  	= 10 
	BBSNAME	  		= The Example BBS
	REGISTRATION 	= 55555555
	HELLOMSG	 	= You should send your sysop some money, scumbag.
    MAPPING         = N

He could then arrange his batch files so that, for registered users,
REG.CFG is copied over to CONFIG.WA before WIZARD is executed.
Obviously UNREG.CFG would be copied to CONFIG.WA for unregistered
users.  The net effect is that registered users have an easier time
acquiring power, and have longer to play each day.  He also would
not be abused every time he came into the game.

