Re: [Adonthell-devel] Item spec

[Kai Sterker]

On Mon, 13 Jan 2003 15:57:02 +0300 Sasha Kushnirenko wrote:

> > * name (string)
> > * type (list of strings)
> >   The 'categories' an item belongs to. Like "Weapon", "Sword",
> >   "Temple property" or "Banec's equipment". Obviously, an item can
> >   belong to several categories at a time.
> Hm-m-m may require a bit more structure than just a list of strings.

Possibly so. But it surely won't hurt to start simple and improve at
need. 
 

> > * quantity (int)
> >   For items that are stackable, it's important to know how many are
> >   in a stack. 
> 
> I think it is a property of a slot, rather than of an item.  Item can
> have a"size" (like in real life).  And I can buy
> magic-slot-size-enchancer. It also opens possibility for an object to
> occupy a couple of slots.

Right. Quantity could also be property of an item slot. But that would
also mean that a 'slot' has to be a class of its own, with at least an
'item' and a 'quantity' member. An inventory would then contain a list
of slots instead of items. Haven't thought much about the inventory yet,
but it might make sense to do it that way. OTOH, keeping quantity within
the item means a little less overhead.

Size is a bit like weight. I'm not sure if it needs to be a basic item
attribute. I wonder if we need either of them for Adonthell.

Items using up multiple slots is more an aspect of the inventory GUI
(and game rules) Don't think this belongs into the lowlevel item class.


> > * charge (int)
> >   We probably need a max_charge value too.
> 
> Usual approach is 0 < charge(float) < 1.   Unless there is a charge
> enchancer :), but it is always possible to redefine the "capacity" of
> an item.

That's probably just a matter of style. With the above, you only cover
the relative charge though. I.e 50% or 75%. With the above you can give
the absolute value. I.e. a large torch has charge 50, a small torch
charge 25 to start with. With the max_charge value you can calculate the
percentage if required.

 
> >   As a matter of fact, items can not be chargable and stackable at a
> >   time, as stackable items share the same attributes. So using up
> >   one item of the stack would use up all the others.
> 
> I disagree.  Imagine I have 0.5 of a canle and 0.7 of a candle - I
> really like if the game would reorganize it in 1.0 + 0.2 candle and
> stack them in one slot.

Yeah, but that way you destroy the original items and get one big
candle, not a stack of candles. There is no way you can stack items that
differ in their attributes. You could easily stack candles that are
fully charged. But once you use one you'll have to keep it seperate.

You could of course allow that a slot has a list of items. Then you
could stack candles in different states and still tell them apart. If
that is desired, then it might be the way to go.


> > * value (int or float)
> Maybe - price?  It is more specific.  There as well can me magic
> value.... But it is really minor.

No, price would be misleading. The number doesn't say what you have to
pay for the item in a shop. It's the objective value of the item.
 

> FIRST:
> From my little Database experience there is ALWAYS a gadget with a
> property that doesnot fit database description.  So we need somethig
> very generic like a "property" or "specifics" (I do not like generic
> names... but) It can be a link to some list or something.  Color,
> presence of a ... sparkling green star ... that differs real from fake
> gems and so on.

Such things would go on python side. The basic idea is to cover those
attributes that are used by 95% of all items in the item_base class.
Anything item specific goes into the actual python item class.
 

> SECOND: 
> You discuss information passing around later in python example.  I
> have not even zero - negative experience in those questions - but
> would you consider something like "item.ID" to solve some of this
> problems?  So you pass ID and perhaps have acces to all relative
> information?  I apologize if all of this is complete nonsense - I do
> not really know details that well.

I thought about IDs, but it gets tricky if you stack items. Say you have
candle #123 and candle #5312. What do you have when stacking them? Of
course, what was said above would resolve that problem. And yeah, we
might want to give items an ID for those few cases where we need to
retrieve exactly _that_ item from the inventory, and not one that is
just of same kind or has the same name.

As far as my problems go, they are already resolved in a different way
:).


> > * Pick up
> Will NPC do this?

Sure. Not that they'd loot treasure that was meant for the player, but
they should be able to pick up tools lying around in their workshop,
etc. 

> > * Drop
> >   Equipped items need to be unequipped before dropping them.
> Could be automatic

Of course. :).


> > * Use
> >   What happens here depends much on the item being used. A
> >   lightsource might be turned on or off, a potion might be consumed.
> >   That means the use method needs to be implemented on python side.
> I really like the idea of mixing ingredients to create things: would
> "use" have enough flexibility to do that?

Well, depends how mixing is implemented. If you'd use some sort of
recipe, then it would work. Its use method could check for the
ingredients and produce some result if they're available. But uf you
rather think about dragging one item on top of another to 'combine'
them, then something else would be required. 
 
Kai