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

[Kai Sterker]

On 14 Feb 2002 14:23:05 +0100 Alexandre Courbot wrote

>> Instead of defining classes for each type of items, I would rather define
>> classes for 'actions'. Like 'consume', 'combine', 'drop', 'equip', and so
>> on.
> 
> I see your point, but do not completely agree.

You really want me to do some extensive thinking that early in the
morning? Please, have pity ... :P


Well, lets keep the healing potion example for a while:

Your idea, of a python class dealing with a complete healing potion, and
mine with a consume-script for healing potions are equally flawed: they
are not really reusable. They would only work for a healing potion, but
not for a potion of strength, or a bottle of liquor.

So I agree that my proposition was no improvement, maybe it was even a
step back, as it required multiple scripts for each item ;).

But what if an item itself keeps a list of modifiers and what attributes
they affect. The list of modifiers are exactly the attributes of the item
itself. If we kept the names of modifiers and attributes they affect the
same (I.e item.strengh would affect character.strengh) we'd only need a
single list.

So when consumed, you'd pick the affected attributes from the consumer and
apply the corresponding attributes of the potion. Now it's completely
independent from the type of potion, as no data would be kept in the
script. Everything comes from the potion and the consumer.

Now imagine you mix two potions. You could simply add the attributes of
the first potion to the second (possibly weighted with the quality of both
potions), and add attributes the second potion has, but the first not, to
the firsts attribute list. Again, the mixing code will work with either
two potions, no matter what item-attributes they have, and what
character-attributes they affect.


OTOH, it will not alway be that easy. Say you wanted to use poison on a
weapon. This would improve the weapon for the next few attacks, but finally 
the poison will be washed away and the weapon needs to be reset to its 
former state. So there needs be some sort of undo function. A similar case 
would be a temporary enchantment, like a protect spell on a character, which 
is only active for a certain time.

The undoing could be done via a list of modifier-items attached to each item,
together with a counter for each modifier-item. The counter would be
decreased by one every game cycle (or by other means) and when it reaches
0, the modifier-item effects (and the modifier-item itself) are removed again.


Okay, so far we dealt with items that modify attributes and nothing else.
They could be handled with a single script.

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.

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.

Further, special effect scripts might be fed certain item-attributes too.
For example, a torch or lamp or candle could have a brightness attribute,
and the script that 'turns the light on' when the item is used might make
use of the brightness attribute to render the light in different ways.
Smaller radius, less bright, different color, etc. So one effect script
could be used for any light source.



> There is only a limited
> set of actions, and it is very unlikely that we'll have to add others
> ones. So there is no reason to be able to 'extend' the set of possible
> actions, which could be hard-coded in the C++ side with no harm (when
> you use, it search and calls a 'use' method of your object, etc...). On
> the contrary, none of the existing items (heal potion, sword, etc...)
> should be hard-coded in C++ - I think you already agree with this.

Right. The only difference between your suggestion and mine is that I
would make each of the uses a different script, while you would put all
uses of an item into one script. 

I imagine that if my idea would be well thought through and well
implemented, we could reuse many of the scripts, while your item scripts
probably contain lots of duplicate code. Because you have possibly dozends
of different types of potions alone that all need their own script, even 
though they are used and combined the same way.
 

> Say I use a torch on some powder I've found, it might do some fireworks
> and therefore call a cutscene or sets special schedules. You can also
> achieve this by only changing attributes, but it's much harder and less
> straightforward. Or you would have to define another "use" class for
> this special object, but that'd create a lot of redundancy and
> confusions.

Right, I would have to define a own fx class in that case. But wouldn't
you need a special class for the powder as well? And your class would need
to define all uses of the powder, whereas my approach could possibly reuse
a 'combine' or 'consume' script.
 

> Troll open, I'm awaiting the second wave ;)

Here it is. Mind you, I'm not saying my plan is all good and yours is all
bad. I don't even know if my suggestions will work. (They'll certainly
need some modifications.) 

I just think that we should try to come up with something more modular
than 'one script per item type', as I fear that we'll end up with loads of
different item types.

Feel free to flame me anyway :)

Kai