adonthell-devel
[Top][All Lists]
Advanced

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

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


From: Alexandre Courbot
Subject: Re: [Adonthell-devel] Adjustments to items.h ?
Date: 14 Feb 2002 20:50:34 +0100

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

Right. The only flaw I can see is that it only fits a certain kind of
behavior, which is of course the one we'll meet most often, but not the
only one.

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

Exact. In my solution you would have to put an additionnal 'if'
statement to test the kind of the object you combine your potion with.
But you could just test whether it is a potion (no matter which one)
and, knowing which attributes a potion have, apply the treatment without
any further check.

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

Hey, I was waiting for a solution, not another problem! ;) Another thing
to deal with...

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

Isn't this complicating things? In this case, using one file per item
type would be as simple, I'd say! :)

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

Right. On the other hand, you can perfectly make a base 'potion' Python
class, which others potions would inherit from ;)

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

Of course, but anyway each item will have to be defined somewhere, so I
fear we can't do much against that...

> Feel free to flame me anyway :)

Is it enough? ;)

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




reply via email to

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