adonthell-devel
[Top][All Lists]
Advanced

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

Re: [Adonthell-devel] On item slots and equipping items


From: Kai Sterker
Subject: Re: [Adonthell-devel] On item slots and equipping items
Date: Wed, 12 Mar 2003 22:41:09 +0100

On Wed, 12 Mar 2003 20:59:36 +0100 Alexandre Courbot wrote:

> How about using slots classes? What I'm saying here also probably
> applies to other fields (thinking about items and combining). Python
> has high introspection capabilities. It is for exemple capable (AFAIK,
> need to definitely check) to know whether an object is of a certain
> class or is derived from a class). Say we have a Python hierarchy of
> items. Sword derives from Weapon. During a usage/combinaison test, we
> should be able to check whether the object is of class "Weapon" by
> simply using normal Python functions. This could also apply to slots.
> Say there is a "Ring" abstract slot class, from which "Left Ring" and
> "Right Ring" derives. Instead of having to explicitely list the two
> slots rings can be equipped to, we could simply say they equip to
> anything that is of class"Ring". That way, we could really dynamically
> add new rings classes.

I see what you mean. But wouldn't that be quite a lot of work? You'd
have to make a special class for each type of slot. Also note that the
slot class is already implemented in C++, as part of the inventory
system. You could derive Ring, Weapon and whatnot classes from it on
Python side, but I find that this adds too much overhead when a simple
string could do the same.

As for the Left and Right ring slot: we could also have two slots named
"Ring". But then we could not retrieve them by name, as that would only
get the first and never the second. However, if for example the GUI
retrieves the slot the player choses by some other means that wouldn't
be an issue. (Haven't yet decided how the GUI would map its graphical
slot representation to the underlying slots. But I guess it could simply
keep a pointer to each slot).

So the equip method would get a slot (instead of a slot name) and could
easily check whether the given item is (derived from) a class with the
same name as the given slot. That would save us a bit of work when
creating items. We just had to ensure that all weapons actually derive
from weapon, etc. But I guess they'll do that anyway. However it also
means all our bullets, arrows and bolts would have to be derived from a
"quiver" baseclass ;). But why not. 


> > Another thing worth mentioning is that the character carrying an
> > item and the character equipping it need not be the same. If we
> > want, we could limit this somewhat in the inventory GUI. For
> > example, we could check whether a path no longer than N units exists
> > between the two characters.
> 
> This should be limited at the lowest-possible level, methinks. It'd
> not be fair if a player could be more things just because he twiddled
> his client.

Right you are. Well, doesn't matter much where such limit is added.

Kai




reply via email to

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