[Adonthell-devel] mutable and immutable items

[Kai Sterker]

*Sigh*. I thought I could finish work on an inventory spec today, but it
seems that more problems turn up the more I get into detail :/.

What really gives me a headache are mutable items, like the torch that
uses up charges. So I endend up thinking, "what if we only had immutable
items?"

For one, we only needed a single instance of each existing item. At game
startup, all items would be loaded into a global hashmap (for example). 

A slot in an inventory would only contain a pointer to an item and a
reference count. Looking for an item in an inventory would be simple,
because all items of the same kind point to the same instance. So we
only had to compare pointers.

If we wanted to access an item without having a pointer to it, we could 
retrieve the pointer from the hashmap via the unique item name.


That would be a very easy and efficient system. Unfortunately, it would
be rather limited, wouldn't it? Well, maybe not :).


Lets have a look what might make an item mutable:

* For one there could be items with two states: on/off, whole/broken,
  etc.

  In that case, we could actually make them two different items.
  Whenever an item switches state, it could be transformed into 
  its counterpart.

  That would make sense, as the different states would definitely
  require different graphics. Also, we would not want to stack two
  items that are in completely different states.


* Other than that we'd have items that undergo finer transitions:
  charges being used up, items getting more and more damaged, etc.

  Obviously, if a torch can have 40 charges a 5 minutes, we wouldn't
  want to have 40 different torch items. Given the fact that items 
  would need a unique name, this wouldn't be possible anyway.

  Those cases would have to be handled differently. For example we could
  have an item and an item-state. Of course, the item-state couldn't be
  part of the item. But it could be part of the item slot. So if a slot
  would contain 5 mutable items, it would also contain 5 item-states.


* And finally we'd have containers, i.e. items that may contain other
  items. 

  I imagine they wouldn't be stackable. Instead of an item-state, they'd
  be associated with an inventory.


I think that all mutable items fall into these three categories. Some
might be a mixture, but that shouldn't be a problem. Please correct me 
if I'm wrong :).


A brief note about keys and books/scrolls:

Though they differ in only one attribute (the lock they open
respectively their content), I think they should be unique items, so
that they can have individual graphics. That means that keys wouldn't be
stackable, but we could for example have a keyring item as a container
for keys. (Stacking either of those items wouldn't be a terribly good
idea anyway, because it wouldn't be possible to retrieve a certain
key/book/scroll from a stack, only the topmost. Which might not be the
one we wanted to get.



Finally, some implementation notes:

I imagine that items need a "Mutable" flag to indicate that they have an
associated item-state or inventory. Item-state objects itself could be
actual python classes. That means, mutable items could have all the
attributes they desire (be it a simple integer, an event or a complete
inventory). 

When an action method of a mutable item is called, it would get this
python object passed as parameter. (So what we basically do is splitting
items into their immutable and their mutable part).

Not quite sure what implications this will have for the item
implementation. But from the inventory point of view it would greatly
simplify things. 

Just so you get an impression: If I would proceed with the current item
implementation, each item would need a copy or clone method. Each time
an item changes, it needs to be cloned so it does not affect other items
in its stack. Since a stack might contain several items in several
different states, passing stacks (or parts of stacks) between
inventories is a real pain, because there's so much to watch out for. 

Plus all the overhead with having multiple instances of equal items, the
need for those md5 hashes, etc. I'd really love to have an easier and
more efficient solution. Not sure if the suggestion above is the best
way,
but it's already better than what we had before.


So what do you think? Any room for improvements?

Kai