Re: [Adonthell-devel] Item spec

[David White]

Kai,

Good idea to come up with a spec, and the detail you went to is even better.
I agree with most of it, but I just have a few comments below:

>   Of course, it makes no sense to have categories that are not used
>   throughout the game. For convenience, it should be possible to add or
>   remove categories throughout an items lifetime. (Like a burned out
>   torch could have the "Lightsource" type removed, but still act as
>   "Club" or "Weapon")

I am guessing that this example is mildly contrived, but I still thought I
would comment: I think that 99+% of the time in the game, the player is
going to have a weapon that is far more powerful than a burnt-out torch.
Thus it seems to me that one can use a burnt out torch as a club is a detail
that is going to end up irritating players far more than enhancing the game:
i.e. most players will immediately drop a torch after it becomes burnt out,
since it will simply be taking up space/weight in their inventory. Having to
continuously drop annoying items like this (and I would say ditto with your
potion/bottle example) is going to detract from the game more than any
enhancement that I can see.

In principle I agree that an item may 'transform' into another item as you
suggest, I'm just saying that I think it'd be best to specifically avoid
getting bogged down in minutae with thousands of unimportant, irrelevant
items.

> * value (int or float)
>   How much the item is worth compared to other items. This attribute
>   does not define the items price when buying or selling, but it is the
>   base for calculating the price. Other attributes, like the player's
>   barter skill or a merchant-specific modifier will play a role here.

A possibility is that different towns/localities might have different
'supply' and 'demand' rankings for different items or types of items. For
example, town X might specialize in making weapons, and so weapons are
cheaper there.

> First of all, lets look how the C++ and Python side of items can be
> integrated:

Your suggestions sound good, although I don't know enough about Swig and
C++/Python integration yet to be able to comment on the best approach.

> As far as I can tell, those five 'actions' cover everything we'll ever
> need. Note that these methods affect items, but would be implemented on
> character level. I.e. you'd have 'character.use (item)', not 'item.use
> (character)'.

What about someone firing an arrow from a bow?

One possible solution is to have the arrows as 'charge' of the bow.
Presumably only one type of arrow can be usefully fired from a certain type
of bow (i.e. longbow arrows from a longbow, crossbow bolts from a crossbow
and so forth). That way, the arrows need not be a seperate item, they can
just be a charge; but if two characters have bows, can we transfer some of
the 'charge' from one character to the other? Also we'd have to make bows
'rechargeable' (i.e. go to a shop and buy more arrows), and as well as a
charge weight there'd have to be a charge cost.

Of course, we might want to make some kind of 'special' arrow (a magic one
maybe?) and this would rule out that; but I'm not sure we really want to do
that. Making arrows a 'stackable' item seems like an attractive approach,
but would need work in that they are used in conjunction with a bow.

>
> So lets have a look at the parameters and conditions required for
> each method.
>
> * bool pick_up (item_base *item)

Just a stylistic comment here: is there a reason why item isn't a reference
instead of a pointer? Is it something to do with Swig not liking references?
Otherwise, item should probably be a reference since it presumably can't be
NULL.

>       vector<item_base*> get_item (string item, int flag)

Another stylistic comment: I noticed that Adonthell consistently seems to
pass strings by value. strings may be expensive to copy (they aren't on
Copy-On-Write (COW) implementions, but COW is becoming increasingly
unpopular), and thus they should be past by const reference instead of by
value.

Other than these few comments, the rest looked great to me!

Cheers,

-David.