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

[Alexandre Courbot]

The dummy tries to understand his mails, take II! ;)

I see better where you want to go. Globally, you'd have one class per
action possible per item, for example the consume class which would
consume an health potion as well as a poison. What worried me most was
that there is only one member function - it's kind of waste of space, as
well as my 'one-file-per-item-type' solution. But I'd say your start is
good. Let's generalise a bit more:

We'd have a lot of different potions, you all agree. Most of them will
have the same basic behavior for all actions, no matter whether they are
health potions, poisons, or whatever: they will have a list of
attributes that they will change on the target. But all actions of all
potions will globally be the same. Remember my reference to schedules? I
think we can do the same here and take advantages of both methods.
Knowing that (nearly) all potions have all the same behavior, you could
have a class that doesn't define what a precise object do, nor defines
an action possible for all kind of objects, but instead defines a
behavior for any number of actions for any kind of objects. Say for
example:

class potion:
        def use:
                #modifies the corresponding attributes
        def combine:
                #combines two potions together

        ....

This class could be assigned to any kind of potion. Their behavior
could, in certain cases, be tuned by constructor time parameters. Just
like schedules. Whenever you need to specialise one action for one
special potion, just inherit from this class, and overload the function
you need to change. Most often, you'll have to call the base function
too, so it will be available anyway.

Advantages:
- One behavior can fit to many, many kind of different objects
- All actions can be grouped into the same file
- Very generic and flexible
- Looks a lot like schedules

> But once special fx come into play that are unique to a certain item,
> there needs to be a special script for each item. But why not? That stil 
> means that practically all items can share the same consume or combine 
> script (in case they are consume- or combinable), but each item could 
> have their own special fx scripts.

This is where overloading would do the trick! :)

> There could be a special effect slot for each use an item has (consume,
> attack, drop, equip, combine, etc ...) , although the slot might be
> empty if we need no special effect. (Espacially to begin with, we would
> not need to think about special effects, but could easily add them later
> on when we have a particle system in the engine, etc ...). But the
> mechanics would be there. And we could already add scripts that have no
> graphical output, but rather change character schedules/dialogues or other
> things.

This makes me think we can push the system one step further again. Each
object has a slot (or rather Python method pointer) that can be NULL
(action not possible) or point to the corresponding method to call when
the action is triggered. When you set the behavior of an object, all the
possible slots are filled with the corresponding function of the class.
But say you want to specialize a (stupid example) chocolate sword. You
can fight with it, but also eat it. All the actions belong to the weapon
class, excepted that you'd also need the 'consume' method of the 'food'
class. That's it: you could set the behavior to 'weapon', but then after
call a set_eat_function ('food') method that would only fill the 'eat'
slot with the 'eat' function of the 'food' class. That way, you have a
sword you can eat, and the same flexibility as Kai's initial proposal, a
bit less messy maybe ;)

This is globally Kai's initial idea, with small parts from mine - I
don't know whether you like it, but it seems to me that it would satisfy
all our needs, and it the right thing to do!(C) ;)

Looking forward for your reactions! :)
Alex.

-- 
http://www.gnurou.org