adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Adonthell-devel] Character design


From: Kai Sterker
Subject: [Adonthell-devel] Character design
Date: Tue, 4 Mar 2003 21:52:10 +0100

All in all, characters are a quite complex topic, as there are so many
things involved. I'll try to list all the different character related
things and see if I can come up with something sensible.

Character parts:

* schedules
* graphics
* misc stuff
* map-related stuff
* basic attributes and properties

The basic attributes and properties are (mostly) related to the actual
game rules and stuff. As such, I would completely implement them on
Python side. As most other game rule related things (like combat
calculations or skill checks) are implemented in Python, it is more
efficient if they can directly operate on Python classes instead of
going through the SWIG layer.

The only basic attributes that are really needed by the game engine
would be map related things. Coordinates and speed, etc. ... 

But that would be part of the map related functionality. I'll leave that
to you, Alex :).

The schedule stuff would sit on top of the map related stuff, as it
controls movement of characters. However, it'll also need access to a
character's Python side, so that characters can use items, etc ...

Then there are things that I do not really know where they belong:
character actions: i.e. what happens when the player 'acts' on a
character. Further the speech bubble thing. The dialogue related
stuff like portrait, text color and dialogue script. Those make only
sense for characters that are walking the map. Guess they would sit
between basic map stuff and schedules. They shouldn't be part of
mapcharacter or character_base like they are in 0.3.


That's not much cleaner than the current character code, I fear. Any
ideas to improve it are welcome.


Concerning the implementation of the Python character class, I haven't
been able to come up with anything complete so far. Just a few ideas:

As most attributes of a character have a maximum (either defined by the
rules or computed from other attributes), I'd make a class that contains
some tables with these maximum values. Either in a fixed table where the
values or fixed, or as methods where the maximum depends on other
attributes. This class would be global and shared between characters.

Of course, temporary or fixed modifiers a certain character might have
to those maximum values would have to be taken into account. That means,
a character needs the current value of each attribute, and an (optional)
modifier. For example, if a character has a maximum health of 40 (10 *
hardness) and wears a ring of health (health +4), the character's actual
maximum health would be 44. Current health could then be between 0 and
44. Things would be similar for other attributes too. If a human
character normally can gain a max rank of 0 in fire magic, but has
joined the Rods of Chaos, the fire magic modifier would be 1. Etc. ...

Attribute modifiers would often change when equipping items or removing
them, but also when casting spells or drinking potions. If they are
related to items, they had to be adjusted through the item's "equip",
respectively "unequip" method. In case of spells and potions, a time
event could be used to remove them once the effect wears off. There
might be permanent modifications that do not wear off at all.

For simplicity, modifiers should be cumulative. That means we can simply
keep adding (or substracting) effects of items and potions, etc. If that
isn't desired, we'll have to think of something.

The current value of an attribute should always be changed through an
"increase" or "decrease" method that would make sure that attributes are
in the range [0, maximum + modifier]. There would further be a "get" and
a "get_max" method, which would get the current value of an attribute
respectively the sum of maximum and modifier.

Direct access to current attribute values shouldn't be allowed. But
AFAIK, Python still doesn't allow private variables, and probably never
will. Well, nothing's perfect, I guess.


So much for now. Comments welcome.

Kai




reply via email to

[Prev in Thread] Current Thread [Next in Thread]