adonthell-devel
[Top][All Lists]
Advanced

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

Re: [Adonthell-devel] Thoughts on character implementation


From: Kai Sterker
Subject: Re: [Adonthell-devel] Thoughts on character implementation
Date: Sun, 9 Mar 2003 18:06:59 +0100

On Sun, 09 Mar 2003 16:48:12 +0100 Nils Fohrbeck wrote:

> the code works fine!

Well, there were problems when the level was too high. Those are
corrected now, but I didn't bother to send the changed script. Instead
I'm currently working on an actually useable character implementation.
Well, actually I am browsing the Python 2.2 docs. I guess it might be
worth to switch completely to the new class model introduced by Python
2.2, as it offers a lot of cool features.


> have you had a look at the rules i send you? what
> do you think? 

Okay, here we go:

>  These are skills like ride, open locks or pickpockets. One dice (d6)
>  is rolled for each rank you have in this skill then modifies are
>  added. () Ranks are 0-5. (BTW forget about the routine checks I had
>  in my test, they were not that great at all..)

For skill tests I would probably just write one generic skill check
method, like the one I posted earlier. You could pass the rank to get
the number of rolls, and even the number of sides the dice has. That way
we are very flexible.

Nothing needs to be done for routine checks, as you say. I wouldn't say
that they are totally useless, though. There might be situations where
we want a test that either fails or succeeds, no matter how often the
player tries. But in that case, we can query the desired skill directly.


> 2 Combat Skills:

Why don't we go with what is described in the current rules doc?
(v0[1].5). Also, for a start, I would concentrate on melee combat. The
questions we have to ask are:

What properties does a weapon have?
Are those properties applied to the character when equipping the weapon?
To which attributes of the character are they applied?

>From what I can see from the rules, we'd have the following:

* Damage, which is a range, i.e. a Python Tuple with minimum and maximum
  of the range.

* DamageType. In case of ordinary (unenchanted, unpoisoned) weapons, the
  enemies health would be damaged. The best solution would be to
  implement this as a method of the weapon-item. For an ordinary weapon,
  it would be something like:

    def deal_damage (self, character):
        damage = random.randrange (self.Damage) - character.Armour
        if damage > 0: character.decrease ("Health", damage)

  For a magical enhanced or poisoned weapon, the method had be changed
  accordingly.

  The actual combat would always call the method of the weapon that hit
  the opponent, if it hit. 


As spells would also be implemented as items, it would be much the same
for spells. However, as said above, we should concentrate on one thing
first and add more stuff later.


Another topic are constraints. Like the example from the rules doc:

  "The 'Phoenix Shield' requires the character to have 2 ranks in shield
  as well as 2 ranks in fire magic"

Those constraints could be implemnted in the item's "equip" method:

    def equip (self, character):
        # -- check whether character may equip the item
        for constraint, rank in self.Constraints[:]:
            if getattr (character, constraint, 0) < rank:
                return 0

        # -- apply item boni, if any
        ...

        # -- item equippable
        return 1

Constraints would be a list of (attribute, rank) pairs. For the above,
it'd look like follows:
    
    self.Constraints = [("Shield", 2), ("Fire Magic", 2)]

(Now I also know how the "equip" method of items will have to work :))


And last but not least, weapons (just like other items) may modify some
attributes. Actually, there are three kinds of modifiers: those that
modify the current value, those that modify the maximum and those that
modify both.

I am not quite certain yet, how character attributes and modifiers are
stored, so I cannot give sample code. But I imagine that it would work
similar to the constraints code. Some more work needs to be done for
temporary modifiers. Permanent ones are easy, and those that apply as
long as a certain item is equipped can be taken care of by the "equip"
and "unequip" method of an item.


> 3 Racial:

At least spells are fairly easy. They are implemented like items. And
like weapons, they'd have constraints, like "character needs rank 4 in
fire magic and rank 2 in earth magic to learn the spell". That way, it
is ensured that only a certain type of character can learn them. The
constraints could also be alignment based, of course, or on any other
attribute a character has, as long as it makes sense.

Comments?

Kai




reply via email to

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