Re: Circlemud design issues

From: James Turner (turnerjh@XTN.NET)
Date: 04/23/98

George <greerga@CIRCLEMUD.ORG> writes:

> On Thu, 23 Apr 1998, James Turner wrote:
> >As for added flexibility -- what added flexibility is gained from:
> >
> >#define GET_AC(ch)        ((ch)->points.armor)
> >
> >None.
> The fact you don't have to remember exactly where in the structure that
> variable is.  It will also leave all your code unchanged if you restructure
> the char_data structure.  Typing it out has disadvantages.

No advantages over

getAC(CHAR_DATA *ch)
  return ch->points.armor;

setAC(CHAR_DATA *ch, int ac)
  ch->points.armor = ac;

Except that the latter allows for range checking if desired, and the
former allows for computations to take place every time AC is checked,
which could allow for a variety of things, such as AC variation on
weather (rain soaking your armor and belongings, a foot of snow
slowing you, etc) without needing to deal with syncrhonization.

Generally, when possible, it's best to compute actual values than to
compute changes in value, since it doesn't lead to issues of adding X
but then removing (X+1).  For instance,

GET_AC(ch) += apply_ac(ch, pos);

If armor gets damaged, you have to subtract then add later.  Since AC
is only computed in fights, and not terribly often anyway (ie not in
any tight loops or in performance critical spots), it could be done

getAC(CHAR_DATA *ch)
  int base = 100;

  if (AFF_FLAGGED(ch, AFF_SLOW)) base += 10;
  if (AFF_FLAGGED(ch, speed)) base += 15;

  switch (getPrecipitation(getZone(ch))) {
    case RAINING:
      base -= 5;



This would make it much easier than having to change weather modifiers
when someone enters or leaves a zone, or enters/leaves a building, or
when the weather changes, or when they use an umbrella, etc.

James Turner     

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | |

This archive was generated by hypermail 2b30 : 12/15/00 PST