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

[Alexandre Courbot]

> > The idea is that each item (no matter whether it's a weapon, a yeti
> > figurine, or something else) is defined (at least partly) by a Python
> > class that allows it to do certain things lets say for example a heal
> > potion:
> 
> Since we're already talking about this topic: I had done that in a 
> different way. 
>  
> Instead of defining classes for each type of items, I would rather define
> classes for 'actions'. Like 'consume', 'combine', 'drop', 'equip', and so
> on.

I see your point, but do not completely agree. There is only a limited
set of actions, and it is very unlikely that we'll have to add others
ones. So there is no reason to be able to 'extend' the set of possible
actions, which could be hard-coded in the C++ side with no harm (when
you use, it search and calls a 'use' method of your object, etc...). On
the contrary, none of the existing items (heal potion, sword, etc...)
should be hard-coded in C++ - I think you already agree with this.

Whenever an object is used or combined, it makes sense to me to call a
Python method of this object to decide what it do and only rely on it.
Simply because using an object will, of course, most often only change
some attributes of the thing it's used on, but sometimes it might do
more complex things.

Say I use a torch on some powder I've found, it might do some fireworks
and therefore call a cutscene or sets special schedules. You can also
achieve this by only changing attributes, but it's much harder and less
straightforward. Or you would have to define another "use" class for
this special object, but that'd create a lot of redundancy and
confusions.

Of course, using the system I've proposed, you'd have one Python class
per kind of object that exists in Adonthell's world. But anyway an
object has to have one file at least if we want the game to be modular,
so there's nothing wrong in having this file being a Python class.

> > The consequence is that all 'passeables' objects need to inherit from a
> > class that contains at least a 'type' member so we can guess which kind
> > of object it is when we pass it to a Python function.
> 
> Sure, that is a necessity.

Good. This class is the one that should contain the text-mapped
attributes, me thinks. That way you wouldn't have to cast to another
object type whenever you need to access an attribute that you know
exists on all objects.

> Anyway, right now we're doing basic stuff, so it might be a bit early to
> get too detailed on the subject of using items and such.

Isn't 'using' an item a basic thing? ;) I fear that if we don't decide
how items can interact with each others, we might have to change our
design once again because we came up with something not adapted. The
current item class seems for example too 'static' - there are too much
things that are hard-coded. Items actions are very occasionnal and quick
things, so I'd say it safe to move them to Python without any
consequences on the game's speed. Tell me what's wrong in my proposal,
or what would be the advantages of yours on it. I'd say it's the good
time to discuss about items (so maybe we will finally do them! :))

Troll open, I'm awaiting the second wave ;)

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