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

[Mike Avery]

> 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.

I agree that the attributes should be stored with the item.  If an item is 
changed at some point, it would be best for that very item to store that 
information.  They should not dictate how they effect a target, but perhaps 
which targets they can potentially effect.

If an item has a core potential for fire (Molotov cocktail), and by 
interacting with another item it becomes a poisonous gas potion, we need not 
change the core attributes of the potion.  We only need to set an attribute 
into the secondary and tertiary property fields in that item's definition.

This is perfect, because it allows us to treat alchemy in the same way as the 
magic system (on a number-crunching level), except that Alchemy deals with 
real, touchable (and consumable) items.  The generic item mechanisms then can 
be used to govern Alchemy.


> 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.

Agreed, the DATA should come from the potion and the consumer, but I would 
caution against having the item system double as general game mechanics 
(unless of course we're talking about creating a general state-and-change 
system here which would really be the core game mechanics).  How the potion 
effects the consumer may depend on influences outside the "drinking a potion" 
scenario.  There needs to be a central engine which decides what effects what 
and to what extent.

I think we need to do start with a decision on which possible attributes and 
characteristics are to be valid.  Kai and I talked abou this in another 
thread.  We need to make a short list of global properties and effects. 


> 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.

This is the same calculations to be used in determining foci potential at 
cast time, as well as alchemy, as well as determining melee weapon potential. 
Perhaps this code should be centralized into a general mechanics engine, 
since it will be needed both in and out of combat.

> 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.

Right.  We use the Weapon's secondary and tertiary core properties.  I think 
perhaps rather than time we could use a hit count. (After 20 successfull 
melee hits, the poison attribute is cleared from the sword's properties 
list).  We could even weaken the effect as the count winds down.


> 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.

Good idea.


> 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.

Well, I would just say be careful.  If we come up with one way of handling 
this, it will greatly simplify maintainability of code.  If we make one 
central mechanics system which can handle everything, the items need only 
store their attributes, and everything is done by one piece of code, rather 
than spread between many scripts.


Mike