RE: [Adonthell-devel] character class

[Mike Avery]

> No worries! I fear the problem is that one does not really 
> know the requirements of the 
> character class before thinking ahead. Which basically means 
> we'll have to jump back 
> and forth until all the functionality is there.

Yeah.  There isn't really all that much missing, I just need to tie things
together so I can work with something functional. 
  
> Much like with item_base.cc and item.py, I think. The 
> functionality is provided by the 
> python implementation. The C++ class provides an interface, 
> so it can be accessed from 
> C++ side. As with item_base, we might want to keep 
> functionality that is mainly 
> required on C++ side in the C++ character class, though.

Right.  I've noticed that.  Just trying to wrap my head around it all. 
  

> When we want to be flexible with the rules, the former would 
> be the better solution, I 
> think. Of course that makes only sense if the rules are also 
> kept mainly on Python side.
> 
> As said above, what should be kept on C++ side are those 
> things required by other 
> parts of the C++ code.
 
Right.

 
> Since we agreed that the stats would be put into a seperate 
> class, most stuff that 
> currently is in character.py would be moved elsewhere.

Right, ok so let's make sure I'm clear on this so I don't go and make
assumptions that lead to a botched attempt, or something functional that
doesn't meet our design requirements.  Kai, please let me know if I am on
the right track hare, or please clarify if necessary.  I'd like to have a
very good understanding before I go munging things.

The character class (C++ side) defines those things which are required by
all character-like objects (PC or NPC).  Things like a name and a race.

On the Python side, character_base class is extended with generic "Genus"
scripts which define those things specific to disparate groups of
characters, like humanoids, wolves, etc.  These extensions should be generic
as possible, as ALL character's of this "Genus" extension will inherit these
traits.

Also on the Python side, the class is extended further for instances like
player characters (with inventories, special qualities or any special
circumstances) or any other "special characters", as necessary.
These scripts will be used to further extend and grant finer granularity to
handle things like, say, unique  feats and abilities, special properties,
equipable slots etc,  and whatever data is required to support that.


> I guess the various inventories would remain with the 
> character class, though. 
> (Backpack, equipment, spells, feats, ...)

Right, see above.  Am I on track with how we want the logic layed out?
 
> Then there's the party management code. Not quite sure how 
> that would be 
> implemented. But I guess it'd be a canditate for the C++ 
> side, while the above would 
> reside on Python side.

Anything I do I will attempt to make generic enough so that by supplying a
pointer to a character or unique ID to the methods, we won't run into
limitations because one protagonist is assumed.

With this in mind, we need a couple of things which seem to be missing now:

For player charachters, or truly special NPCs (one of a kind), a Unique ID
string
For generic creatures and NPCs like "peasant", "guard", "wolf" or that sort
of thing, we need a process whereby unique_name is automatically changed to
if several characters of same name are observed.

Right now there is name, and something on the Python stide that
distinguishes PCs from NPCs, but niether of these uniquely identify a
character.  We need something more. 

In working on the char_snapshot structures for the manager, I am building a
method build_char_snap().  In order to support multiple party members as
well as handling several non-unique character types in one combat encounter
(like, say 3 wolves in one fight), this is a rule that we MUST ensure is
followed:

At any given time, "active" characters, or, characters currently being
"acted upon" by ANY part of the engine, MUST be identified with a unique
identifier.

I'm going to add a string "display_name" to the base character class, and
use charachterid for unique identification.

Individual party members are easy to handle, since they will probably have
special scripts which define them, same with special NPCs. We just need to
add this to the base class, which I will do.

Creatures and NPC characters are a different story, but I have an idea.
Where possible, characterID can be used to define a creature type, such as a
wolf.  All wolves can start out with a common characterID.  If we have a
situation where multiple wolves are encountered, we will change the names of
all characters of the same display_name to make them unique.  Something like
appending a count to the end of the name should work fine.  displayname =
wolf, wolf, wolf and characterID = wolf1 wolf2 wolf3.  This would probably
have to be worked into the mapengine, since I assume that we will only be
fighting or "interacting" with characters that occupy a mapsquare.  Is this
a safe assumption?.

If 3 wolves come into view on the map and attack the player, the combat
engine will expect to be supplied 3 unique characterIDs, one for each object
of name wolf.

Same goes for any character.  This means then that as characters are
"encountered", each one needs to receive a guaranteed unique identifier.

Any suggestions on this Kai?

> I imagine that you already have some things in mind, which 
> are required for your stat-
> mangling to function. So feel free to tear my character code 
> apart, keep what you wish, 
> rewrite what needs to be changed, add what's missing.

There isn't too much really that needs to change, the stuff there now is
good, I just want to get things to a state where we can get a solid test
program built which uses real interfaces as we envision the design to run
test cases.

If we can build a testbed using native manager, character, inventory and
combat interfaces implemented as we envision them (without fudging things to
test specific pieces of code), I think we would have a powerful tool to test
and refine core rules, and the engine itself.  Testing ideas and
implementations using the "actual engine" will give us great insight I
think.

I'll keep plugging away.

Mike