
Fight Code:

   The mud cycles a specified number of times each second, looking for events 
(settable in aime.conf as PollsPerSec).  It checks things such as input from
a network socket, someone trying to connect, or someone trying to quit.  Every
second, the mud does a more detailed scan.  It cycles through all mudobjects 
and players, looking for any specials events.  It also runs another turn with
the fight code.  This turn checks to see if first, the individual (could be
a mobile or a player) has a fight focus on someone, meaning they are trying 
to kill that target.  It then checks to see if it is their turn to attack.  An
individual gets one turn every 2 seconds to use their weapon (or fists).

   If the attacking individual is a player, we simply swing their weapon and
hope for the best.  If the attacker is a mobile, it gets a bit more complicated.
The mud performs a few checks to see if they have any spells or skills to use.
If they do, it randomly decides (based on the percent chance of using, settable
in the Mobile object) if they use that ability.  If they do, it runs through
the code for using the ability.  Their success depends on their rank in that
ability and their attributes (intelligence, strength, etc) if those attributes
are important for that ability.  If we have gotten through all the abilities
the mobile has at their disposal and they are not using any of them, then we
run the weapon swing code.
   
   First, the code decides which weapon to use.  If they hold two weapons, it
will randomly select a weapon.  If they have one weapon and the other is bare
hands, it will choose the weapon.  If no weapons, they are stuck using their
fists.  Next, if a range weapon (using projectiles), the code will decrement
one from the ammo in that weapon (one arrow, one stone, etc).

   Next, the code must decide if they are going to hit the body (absent
interference from their target).  If the individual using the weapon can't
see due to darkness, then they get a disadvantage.  The formula for accuracy
for bare fists is:

offensive_accuracy = ((random num 0-100) - ((50 - (dexterity / 2)))) * 
								    disadvantage;

For weapons it is a bit more complicated because it depends on the weapon's
dependance on strength and dexterity, and the wielder's strength and
dexterity.  Basically, first we calculate a strength and dexterity index.

str_index = (((the_wielder_strength - 25) * (the_weapon_dep_strength / 100.0)) / 
									   50.0);
dex_index = (((the_wielder_dexterity - 25) * (the_weapon_dep_dexterity / 100.0)) / 
									   50.0);

Then we use those to calculate a chance index:

chance_index = (50.0 + (dex_index * 67.0) + (str_index * 67.0));

Finally we can get accuracy calculating in disadvantage:

offensive_accuracy = ((chance_index * disadvantage) - (rand_num 0-100);

If accuracy is less than 20, they completely miss.  If greater than 20, 
their weapon is on the right track, but still could be deflected.  If a 
range weapon, we make the assumption it moves too fast to deflect so it will 
hit.  If it is not a range weapon, then we randomly select a body part.  
Certain body parts have a greater chance of being hit, such as the torso 
is larger than the head so has a greater chance.  Once a body part is 
randomly selected, we need to calculate whether the weapon has been 
deflected.  We calculate defensive accuracy in the same manner as we 
calculated accuracy above.  If the defensive accuracy is greater than 
offensive accuracy, then the weapon is deflected.  The exception is that 
fists will not deflect steel (ouch!).  

   So our weapon has now snuck past their defenses.  We need to calculate 
damage.  The mud calculates damage as such:

damage = weapon_damage * (offensive_accuracy / 100);

   Now we calculate damage done.  If they hold a shield, there is a 50% chance 
the shield will absorb some of the blow.  First, we add up the layers of 
armor on that body part.
We then subtract the armor from the damage to calculate damage done like so:

real_damage = the_damage - armor_value;

Thats basically it.  Granted there are some unrealistic sections and I am 
sure I will probably get a few e-mails saying "You should do it this way".  
Keep in mind that a balance must be made between code complexity and 
realism so not all realistic features can be implemented and still have 
manageable code.


