adonthell-devel
[Top][All Lists]
Advanced

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

Re: [Adonthell-devel] Item spec


From: Sasha Kushnirenko
Subject: Re: [Adonthell-devel] Item spec
Date: Mon, 13 Jan 2003 15:57:02 +0300
User-agent: Mutt/1.3.28i

Hi, Kai!

> I was thinking about coding the lowlevel character/item/inventory stuff.
Well, you made it quite clear :)

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

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

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

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

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

> * description (string)
> * weight (int of float)
>   The actual weight would then be: weight + weight_per_charge * charge
Good idea.  Can aslo be applied for "size" 

> Well, so much for basic item attributes. Anything I have forgotten?
> Anything that should be changed?

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.

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.

Anyway I always setup ID for database entries.

> What remains, the interface to the Python item implementation,
Can not comment

> * Pick up
Will NPC do this?
> * Drop
>   Equipped items need to be unequipped before dropping them.
Could be automatic
> * Equip
> * Unequip
> * 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?

> With that I'll come to an end. Sorry if it's a lot of info, and not all
> of it explained in detail. If nobody sees any huge flaws in the above, I
> would go about implementing (and documenting) that stuff. Sounds okay?

I would recommend creating a skeleton or something.  You already started it
with a torch.

Great job anyway!

Sasha.




reply via email to

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