Re: [Adonthell-devel] character class

[Kai Sterker]

On Thu, 22 May 2003 13:12:13 -0700 Mike Avery wrote:

> > 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.

Alright. 

> 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.

Right. The most basic things that would probably be used by any
character system.
 
> 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.

Exactly. These Python scripts could called character templates, if you
want. Now initialize the different stats with different values and
you'll get individual characters of a similar kind.


> 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.

Yes. Although I believe that there won't be too much need for this. Two
characters using the same template could still be quite different. After
all, a lot of customization can be done with the schedule scripts a
character will have (which will determine their behaviour). So you could
use the same "beast" template for both harmless and dangerous animals.
You might have a specialization for animals that can do magic, though.
Anyway, you're on the right track here.
 

> 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. 

Right.

> 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?.

Yes, I would say so. After all, to have a well-defined position
characters need to be on the map. Without knowing where characters are,
we cannot possibly let them fight. So the assumption is right. Just keep
in mind that this may not neccessarily take place in the Player's view.

Also note that Alex is going to rewrite the mapengine anyway. So he can
take care of the things above if that is required.


> 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?

Sounds okay to me.

Just one thing: why not give them that unique id when they are spawned?
Just have a map with screen_name/count pairs, and whenever a new wolf is
created, you also generate a unique id. Whenever the game is restarted
(or reloaded) you could recalculate the id, so the danger of running out
of ids is practically 0. (I don't think there'll ever be 2^32 wolves).
Of course you would require a way to distinguish between characters that
are already unique, and the others. Because then any scripts can access
plot-relevant characters by their unique id that the author knows
beforehand, while the 'minor' characters whose id one cannot know
beforehand are still treated correctly by the engine.
 

> 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.

Yeah, that would help us a lot indeed. 

Kai