Re: [Adonthell-devel] Adjustments to items.h ?

[Alexandre Courbot]

> > I've read over the items stuff  (item.cc, item.h, item.txt).  Further to 
> > the 
> > email I sent last time, should we expand the existing item superclass to 
> > incorporate weapon/armour/foci attributes or do Kai/Alex have a different 
> > and 
> > preferred way to do this?
> 
> I don't know if it should be in the item superclass. Basically, it depends
> on what attributes certain items need. Even if all items need those
> attributes, it might be cleaner to put them into a different class.
> 
> But if there are plenty of attributes only needed for weapons or armour or
> foci or gems, etc., then it would be better to have a generic
> weapon/armour/foci class with only the attributes it needs.
>
> Which means you cannot equip the lamb chop, unless it is meant to be a
> weapon ;).

I think it's time to expose my ideas on items.

What I've been thinking about is HOW do items act. An heal potion gives
heal points, a sword hits, a rune can be combined with a weapon to
influence it's action, etc... Items should be easy to design, and their
actions certainly not hard-coded in C++. You guessed it, our old pal
Python would help here once again.

The idea is that each item (no matter whether it's a weapon, a yeti
figurine, or something else) is defined (at least partly) by a Python
class that allows it to do certain things lets say for example a heal
potion:

class heal_potion:
        
        # At construction we can set the capacity of the
        # potion.
        def __init__ (potion_capacity):
                this.capacity = potion_capacity

        # Run when you use the potion with something. The "something"
        # is passed as a parameter - it's a simple superclass from which
        # would inherit characters, item, etc...
        def use (to_use_on):
                # The 'type' member of our superclass is filled by it's
                # sons' constructor to help knowing what it is: a 
                # character, a weapon, a classic item, ...
                if (to_use_on.type == CHARACTER):
                        to_use_on.health += potion_capacity
                        # Returns 1 if the use succeded
                        return 1
                # if we tried to use the potion on something else
                # than a character, it returns the use isn't possible.
                return 0


This file would define the behavior of any health potion. Of course, you
could define others members functions to the class: one for combining
with something else (which would return a new object pointer, or NULL if
the combinaison isn't possible), use_in_combat, ... others functions
would certainly be needed. The advantage is that virtually any object
can combine with any other. If you want the health potion to be able to
be used on a sword too, you just need to add another 'if' statement,
test whether the item passed is a WEAPON, then check whether it's a
sword, and do what you have to do with. Of course, such functions are
optionnal. I don't know if such an idea has already been proposed yet,
but in doubt, I submit it.

The consequence is that all 'passeables' objects need to inherit from a
class that contains at least a 'type' member so we can guess which kind
of object it is when we pass it to a Python function. This is basically
what Kai did with the events, and what I'm doing with the new map engine
- so maybe the items could inherit from my base class (which is really
'basic') or maybe I could split my class so it can fulfill both usages.
Either way, you'll have to wait for my first map engine commit to see it
:p

I *think* the same idea applies to the combat system discussion. Combat
moves could be IMO defined in Python, for at least the usage of weapons.
It also opens a lot of possibilities from what have currently been
discussed. I'd say it's 'the right thing to do', because it allows all
that has been discussed yet with the advantages of flexibility, game
engine independance and ease of creation. But there are certainly
improvments that are possible :)

Alex.
-- 
http://www.gnurou.org