Re: [Adonthell-devel] Item spec

[Kai Sterker]

On Tue, 14 Jan 2003 19:49:52 +0100 Alexandre Courbot wrote:

> First, how about having totally Pythonized objects? Where py_object
> will become a simple interface to PyObject *. It would have the
> methods to call Python methods, as it already have, but also set/get
> attribute methods that manipulates Py_GetAttrString and
> Py_SetAttrString.

Hm, the more I think about this, the more I like it. I imagine that most
item attributes would be accessed from python side, so it'd eliminate
the overhead of retrieving them from the C++ class each time.

So basically our item_base class on C++ side would be just a nice
wrapper for its Python counterpart. Yeah, makes sense to me :).
 
 
> Second, using a hierarchy of objects sounds really cool. We already
> discussed about that: having for instance a "weapon" base class that
> contains the attributes common to all weapons, then a "sword"
> subclass, and so on...

Not quite :). I imagine that the weapon class is already enough to model
a sword or an axe or staff. All it needs is giving different values to
it's attributes. Of course, more special weapons would extend the weapon
class. An ordinary sword wouldn't. (See my mail about item templates,
items and item instances)
 

> Some methods would of course be standardized, like use, equip, and
> combine (which returns a new item or None if the combinaison is not
> relevant - can also modify or delete the items it has been passed).

I was thinking about a combine method. I guess we'll need that too. But
otherwise "pick_up", "drop", "equip", "unequip" and "use" should be
enough. At least for now :).
 
Basically, "combine" would cover using one item with another, much like
in your average Graphical Adventure Game. Apart from that, "using"
recipes enables combinations of more than two items.


> About the charges and stack items: IMO charges should be items of
> their own. Let's take the lamp example again. The lamp is an item. Oil
> packs are items too. When combining an oil pack with a lamp, the lamp
> gets loaded, and the pack destroyed. All this is coded in the "oil
> pack" combine method, when the passed item is a lamp.

Of course. Only I would do it the other way round: lamp.combine (oil).
If the item being charged handles charges, it can easily handle
different objects as charge. Simply make them all the same type
("Lampfuel") and check for that type. (Don't know what else could be
used in lamps, but there might be items where this actually makes
sense.)

Still the lamp needs a "charge" attribute to tell _how much_ oil is
inside. After all, a lamp can have more states than full and empty :).
 

> That's my first thoughts. I'm sure I haven't adressed all issues -
> especially with the callback stuff that made Kai prefer solution C
> instead of B. But no matter which direction we head to, I think it's
> most important to formalize that very well on paper before thinking
> about coding anything. How about this Kai? The problem is not very
> complex, but quite large, and it gets hard to get it from a single
> mail. Moreover we'd better avoid falling into the code-mess trap
> again!:)

Well, sometimes you just have to try something out. The simple torch
example already revealed a number of problems with the stuff I've
written in the original mail. Coding something doesn't hurt, as long as
we're ready to throw stuff away if we come up with something better. I
mean, we're doing this all the time :). 

Also, you have to start somewhere, otherwise we talk and talk and
nothing happens afterwards, as often was the case. Talking and coding
at the same time might get things actually done.

Besides, what we talk will surely benefit from the practical experience
we make with the code.

Kai