To start, each character needs a definition, which is pulled from the master character
list. You store this definition value in the def variable. To tell similar
characters apart, you assign a unique identification number (ID) to each one.
Think of using identification numbers as you use names. Instead of adding a character
named “George” into the game during play, you refer to that same character
as character 5.

Each character being tracked is of a specific type, either a PC, an NPC, or a monster.
To determine the value for Type, use the following three macros:

#define CHAR_PC 0
#define CHAR_NPC 1
#define CHAR_MONSTER 2

Next are the character’s artificial intelligence settings. Remember that a character
can stand in place, wander around, walk a route, follow another character, or evade
another character. The artificial intelligence of each character is stored in the ai
variable and can be set to one of the following macro values:

#define CHAR_STAND 0
#define CHAR_WANDER 1
#define CHAR_ROUTE 2
#define CHAR_FOLLOW 3
#define CHAR_EVADE 4

Finally, each character needs to be enabled in order to be updated. The update_enable flag
determines this, and setting it to true lets the controller update the character every
frame, whereas setting the flag to false means that the character is never updated
(until enabled, that is).

You need to store the character’s MCL definition for referencing, and for characters
with an inventory, you contain the ICS.

Because the character’s definition stores only the maximum values of
the abilities and attributes, the sCharacter structure needs a way to
track the current values as they change through game-play. This
includes the health points, mana points, status ailment flags, and the
current charge of the character.

NOTE
Remember that characters can perform specific actions (attacking or casting a
spell, for example) only when their charges are at full peak.This charge rate increases
at the rate defined within the MCL.

As characters move around performing their various actions (moving, idling,
attacking, and so on), you need to provide a way for their actions and positions
to be tracked. In addition, their last known animation needs to be maintained
(in order to update their animation), as well as the last time their animation was
updated.

You also need to provide a way to prevent characters that perform specific actions
from being updated until the completion of those actions. When a character is
attacking, for example, there’s no need to update the character any further until
the character finishes swinging the weapon. What is needed is a countdown timer
to lock a character’s actions; this countdown timer is action_timer.

To permanently prevent a character from being updated, you use a second variable,
called is_lock. If you set is_lock to true, the character controller will not update the
character until you set is_lock to false.

When a character attacks another one, the pointers to both the attacking character
and victim character are stored in their respective sCharacter structures. The attacker
remembers the victim while the victim remembers the attacker. Also, when a character
uses a spell, the MSL spell number is stored, along with the spell’s target coordinates
and the type of character to target (CHAR_PC, CHAR_NPC, or CHAR_MONSTER).

Recall that characters have actions, and those actions have a set of associated animations.
The reason for storing the attacker, victim, and spell information (as well
as the following item information) is that a character’s action and animation must
be completed before the results of the action take place. Once an attacking character
swings a weapon, the results of the attack are calculated. The same goes for
spell; once a character casts a spell, the spell information in the sCharacter structure
is used to determine who, or what, is affected.

The same goes for using items; the pointer to the item used during a use item
action is stored, as well as the pointer to the ICS cCharItem structure of the character
(in order to remove the item if it was marked as USEONCE).

You’re about halfway through the structure. Now, you store the information about
the character’s artificial intelligence. You’ve already read about most of the following
data. You have the distance to follow or evade a character, along with the
pointer to the character to follow or evade.

For characters that use a bounding area, you store the minimum and maximum
coordinates, followed by the route information.

Moving on, you use a trio of variables to store a simple message that is overlaid on
top of a character during game-play (as illustrated in Figure 16.15).

Character messages help relate tiny bits of information, as Figure 16.15 shows.
To set a message, copy the message string (up to 128 characters) into the Message
buffer, set the amount of time (in milliseconds) to display the message, and assign
a color to the text to be displayed.

Finishing up the sCharacter class variables is the Graphics Core cObject object that
maintains the character’s mesh and animation. To enhance the visual appearance
of the characters, a separate mesh and object are used to represent a character’s
weapon. This weapon mesh and object are configured any time a new weapon is
equipped. Last comes the linked list pointers prev and next.

That’s a lot of information to store for each character, and to help the controller
prepare a structure every time a new character is added to the fray, the sCharacter
structure comes complete with a constructor and destructor in order to prepare
the data and help release its resources.

And that’s it! I told you sCharacter was a big structure, but it is nothing compared to
the character controller class that uses the structures.