Re: Proposal for the skills array

From: Jesse Becker (
Date: 11/04/02

On Sun, 3 Nov 2002, Tseran wrote:
> >> dummy_mob.  Anyone have any thoughts on this?  Would this be feasible?
> >> Would it be likely?
> >
> > Maybe I misunderstood what you are trying to say, but I just added to
> > the
> > mob_special_data an mskill array just like players have.
> Not quite.  Moving the entire player skill array to a neutral place, so
> that it can be used for both players and mobs without problems.  That
> means less overhead as it doesn't require 2 complete arrays to do the
> job of 1.

Err...bad idea, IMO.  In stock circle, all skills are declared in the
struct player_special_data_saved, and skills are specifically defined as:

   byte skills[MAX_SKILLS+1];   /* array of skills plus skill 0     */

MAX_SKILLS is further defined as 200, and I expect that many coders
increase that number.  Thus, the skills array takes 201 bytes of memory
for each player--not a big deal.  However, stock CircleMud further loads
some 1397 mobs (of 569 different types).  At 201 bytes of memory each,
that's a 274kb increase in the MUD's memory foot print.  Add more
mobs/skills, and that will get even larger.  One of the coders I work with
actually did this (with MAX_SKILL defined at about 500), and the memory
footprint went up by almost 3 megs.

This, I think, a colossal waste, especially given that 99% of MOBs aren't
going to have skills at all (or have effective skills of zero, which
usually amounts to the same thing).  If you allow objects to have skills
(casting spells for example), then the problem is even worse (1440 objects
of 680 unique types).

A better approach is to use a simple linked list of skills that each mob
knows.  This increases the memory footprint of each mob by:
  sizeof(void *) + sizeof(skill_level_type) * num_skills_known_by_mob

The struct skill_level_type is below:

  struct skill_level_type {
    unsigned short skill;  /* What spell/skill number. */
    unsigned short level;  /* How well skill is known */
    struct skill_level_type *next;

On 32 bit machines, that should be a total size of 8 bytes per skill.

From this, you change GET_SKILL and SET_SKILL to handle mobs as well as
players (whitespace is for clarity):

#define GET_SKILL(ch, i)  \
           IS_NPC(ch) ? GET_MOB_SKILL(ch,i) \
                      : CHECK_PLAYER_SPECIAL((ch), \

GET_MOB_SKILL is, in my case, a trivial wrapper for the function
get_mob_skill(), which actually walks the linked list of skills.
SET_SKILL is handled similarly.

There are lots of examples online about linked lists.  I just found a
really nifty Java applet that shows an example searching function here:
(Finally!  Something useful in Java!)



   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/25/03 PDT