***** A General Guide *****

As you may have guessed (or not) from the title OGHAM is designed around
a medieval fighting fantasy themed mud. To adapt it to a science fiction
theme would not be hard but would be time consuming.

Remember this mud is written in C not forgiving LPC. If you make a mistake
in LPC code the driver will just give an error when it tries to run the code.
If you make an error with this and it compiles you're on the way to some
interesting bugs or even a crash.

I have tried to build some rules into the mud eg strength, weapon skill etc
goes from 0/1 to 100, weight limits on users and objects. It is trivial to
break these rules however. For instance - users weight limits are enforced by
the get() functions but npcs have no equivilant function so it has to 
be written into their own code if they wish to get an item. Because of this 
they could pick up anything no matter how heavy since its a simple matter of
changing a few variables. Other breaking of rules could be a monster which zaps
a user dead as soon as he enters a room. Anything is possible but remember - if
you piss your players off by building an unfair mud you soon won't have any.


Comments on the code
--------------------
I would be the first to admit that I'm not the worlds greatest coder. I tend
to program seat-of-the-pants style (otherwise known as "making it up as you 
go along") rather than sitting down and thinking it out (I actually find its 
more productive since any problems turn up very quickly whereas just musing 
over the algorithms on paper tends not to lead to problems being found so 
quick if at all). So if when you look through the code you come across 
something that you think you could have done more efficiently or you come 
across multiple inline copies of the same bit of code that you think code all 
be put in one function, you're probably right. You're bound to find some bugs
as well (though hopefully I've purged all the major ones) bearing in mind that
main.c by itself is over 6000 lines of code so its not possible for it to be
bug free. If you do find any bugs I'd appreciate it if you'd mail me what
you've found whether you've solved it or not.


Omissions
---------

Invisibility for users. I did not do this for 2 main reasons:
   A: Because only wizes & gods usually can use it so it adds nothing to the 
      gameplay.
   B: Checks would have to be built in to most of the user functions. eg If 
      an invisible user called Fred picked something up, the mud could not
      write "Fred gets ...." since this would blow his cover but it would 
      have to write something appropriate. This would require enormous coding
      effort for very little reward.

Snooping is not built in to main.c since this is best coded as a skill function
to be learned or given.

Corpses are not built into the code but the framework is there for them to
be included. The function create_corpse() in main2.c is called whenever a
user or npc dies. If it returns 0 (as it currently does) the user or npcs's
objects are dropped in the room and there is no corpse. This function if it
is to be used correctly must create the corpse (a corpse object will most
likely be needed) and transfer all the equipment and money to it etc..


Giving
------

User and monsters (npcs) can be given to but this is controlled by certain
variables - accept_items and accept_money in user and object structures.
The purpose for these is to prevent users being given objects they do not
want (eg a bomb which blows up when it changes hands and kills them) and
money when they do not want it (eg there could be some temple where having
greater than a certain amount of money is punishable by death).
   I also have these restrictions on the monsters so they don't end up carrying
around items and money which they're not programmed to use.
   On login users accept items and money by default, whereas monsters refuse
by default.
   For users the command "accitems", "refitems", "accmoney" and "refmoney"
control the accept variables.


Fighting
--------

Coming up with an equation to give a sensible value for hit points in
every fight situation is very difficult. For instance,  what do you do
if there are no weapons involved - would weapon skill come into hand to
hand combat? What about defense? I have kept it simple. Weapon skill is only
of any use when the fighter (user or npc) has a weapon and only armour and
dodge speed is used in defense (ie no parrying). This may seem too simplistic
for you so if you wish to change it the hits are worked out in the function
fight_hits() in main.c. Hits from standard magic spells are worked out 
differently.

Armour
------

I have defined 5 types of armour which can be seen in the globals.h file.
It was not strictly necessary for me to do this but it makes the game more
realistic. User store whether they are wearing certain types of armour in
ustr[].arm[NUM_ARM_TYPES]. If a user is already wearing one sort of armour
eg BODY armour then the "wear" command will not let him put on any more. 
Eg he could wear chaimail and a helmet at the same time but not chainmail
and ringmail. Npc's do not have this restriction simply because it is
impossible to enforce as npc functions can be written as you please and if
you want an npc to wear chaimail & ringmail at the same there is nothing
to stop you do the following...

obj1=clone("chainmail",WITH_OBJ);
obj2=clone("ringmail",WITH_OBJ);
check for null
obj1->obj_with=npc;  obj2->obj_with=npc;
obj1->worn_wield=1;  obj2->worn_wield=1;
npc->arm+=obj1->arm;  npc->arm+=obj2->arm; 

When a user is in a fight his total ustr[].arm[NUM_ARM_TYPES] is added up
and used as his defence. Npc's simply use the npc->arm variable.
If you want a user to be able to wear eg a cloak on top of ringmail then you
set the cloaks can_wear var. to 1 but do not give it any armour value.


Weapons
-------

An item can be wielded if it has damage > 0. The user must have a weapon
skill equal or greater to that of the weapon to be able to wield it.
This rule does not apply to npc's for the same reason the armour rule doesn't -
its impossible to enforce.
	The users damage in a fight is that of the weapon he is wielding 
multiplied by his (weapon skill/100) else it is zero.
	The only reason that structure element exists in the user structure
is to avoid searching through all the users belongings every time the mud
wishes to find the wielded weapons damage. It is set when the user wields the
weapon and unset when he unwields it.


Passwords & clients
-------------------

My knowledge of telnet control and configure codes is limited. I have got
password blanking working but it only seems to work properly when the client
is unix client - VMS telnet buggers up (so I've been told). Unless you can 
fix this problem I suggest you set the PASSWORD_ECHO macro in globals.h to 1 
if you wish to have any VMS users and this will cause passwords to be echoed.
But lets be honest - how many people use VMS these days?
	The server now works with character mode clients such as Windows telnet
(what a dog that client is). Since DOS and Windows clients require \n\r instead
of just \n it was necessary to change the code to accomodate this. One way
would have been to change every single string but this seemed to much bother.
So I only changed a few strings , the more() function and most importantly
the write_user() function. This goes through all strings it is sent and 
adds \r to any \n. This feature slows the mud down a bit and can be switched
off by setting the DOS_NEWLINE macro to 0. Another macro is CHAR_MODE_ECHO.
Most clients do their own echoing, some don't. It is best to leave this as 0
unless you have a LOT of users who need server echo else everyone on normal
character mode clients will get 2 of everything they type in.
