Inventory system

[jack_norton]

Hello,
was wondering if anyone implemented a sort of inventory system. You know, like those you see in "normal" adventure games, maybe activable clicking on a icon, to pop-up a list of icon/texts representing the object you have in your inventory. I believe should be possible to make it using python code inside renpy right ?

[x__sinister]

This thread has a demo for download which has the option of an inventory system.

http://lemmasoft.renai.us/forums/viewto ... f=8&t=3816

[jack_norton]

Ah thanks, quite impressive demo. I loved the Lone Wolf gamebook series myself...

[Gau_Veldt]

Okay a lot of people ask about this so I'm thinking about biting the bullet and crafting an inventory displayable that could be plugged into any project with the complexity not much more than setting up a working set of ui.xxx calls.

First I'm thinking that the overall class be a displayable so that it may be added to a ui layer then left there. Once there you'd call one of its dialog methods as appropriate (OpenSelect/OpenShop) then have the script hang around in a ui.interact() until the dialog is dismissed.

I'm thinking text list (like FF1NES/FF6), iconified list (like Lunar) or rings (like Secret of Mana/Secret or Evermore) for display schemes. For rings a full blown displayable would be needed since the rings animate. The ring mode is not strictly necessary (I just think it would be a neat--though slightly complicated--piece of code to write).

The persistence logic is the first caveat. If the class is a displayable it might be removed by Ren'Py during normal running of a script which is highly undesirable since it means a player's inventory would reset each time the ui was dismissed. Alternatively there's layers but I'm wondering again about the safety of a lurking displayable meant to stay active the lifetime of a script (not to be cleared between scenes or any such). The class should (obviously) persist the inventory between successive calls on its methods to show the inventory interaction dialog (or shopkeeper dialog). Overlay perhaps? I could use some design direction here since this is one of those design issues that will bite back hard if I pick a bad way to do it.

So the basic way it would work is as follows:
1. You make a "master list" of all the items in the game (probably in a separate .rpy)
2. At the beginning of the script you'd create an InventorySystem object and specifying the master list to the constructor.
3. Aside from the usual methods involving inventory (scriptomatic addition/checking/removal of items and so forth via appropriate method calls) the .OpenInventory() and .OpenShop() would be the most interesting methods for the player and pop up appropriate dialogs until dismissed by the player.
4. The whole thing needs to work with rollback and save.

Open source for the system code something along the lines of the Ren'Py license though ideally I want improvements public and not sealed away behind individual games' archives (sounds like LGPL but there may be differences from the above stated to bona fide LGPL).

Planned support:
1. Textual or iconified inventory. Ring mode (more complicated) only if demand warrants (it's somewhat more work since rings are motion and require a more complicated displayable)
2. Item classes to split items into groups of usage (ie: spells vs. useable items) so that a call to the selection dialog can be filtered to a certain class (eg: cast only shows spells)
3. Multiple characters. In games where multiple characters each may have their own inventory.
4. Stack size (how many of an item may be held) support.
5. Multiple currency (think: the gold/silver/copper, faction tokens, and honor points all used as currency in various shops in World of Warcraft).
4. Suitable defaults so simple games (one player without using item class) involve none of the extra work incurred by 2 and 3 for their use.

The non visual parts of this are fairly straightforward and I'll work on that first, then the tedium of making selection and shop displayables. It won't be very interesting to show with just the management aspects but it'll be the first milestone I post.

My main concern right now is what to watch out for in the container class to keep this safe for saves and rollbacks though any other feedback will be appreciated too.

Should I set up the selection and shop UI elements as separate classes that require passing of the InventorySystem object to the constructor? Or can the entire thing be made to work with a single hybrid container/displayable class?

EDIT: I forgot to mention planned support for callbacks for actual use of items. More relevant to the displayable end of things but is partly applicable to the management as a case of scriptomatic usage of an item chosen either by the script (as part of the story) or the player via a normal Ren'Py menu.

[chronoluminaire]

It seems to me that the basic inventory object/system shouldn't be a displayable / UI object. There are a variety of interactions with an inventory that aren't anything to do with displaying it, such as saving and loading, programmatically receiving or losing objects (eg for plot reasons), programmatic queries to see if the player has an item in their inventory, and so on. Saving and loading is potentially of particular concern, given how some objects can't be saved.

However, it makes perfect sense for an inventory object to have a method called "display", "view", "interact" or whatever, which allows all the interactions you describe.

[monele]

It's quite old in my memories but there is a way to display UI elements as permanent elements on the screen (other than using the Overlay trick). Now where did I use this? ^^;.......

[Jake]

Now where did I use this? ^^;.......

The Phoenix Wright thing, perhaps? I seem to remember that had a court-record button on-screen at all times, although I never looked at the code so I don't know how you did it.


But I agree with Chrono, really - don't make the point-of-contact class a displayable, just either give it some method that returns one, or even better have a set of displayable classes which take your point-of-contact class as a construction parameter. The OOP approach never intended to have monolithic do-everything classes; taking the inventory class as a constructor parameter makes it a lot more easy to extend it with new displayable schemes at a later date.

[Gau_Veldt]

Now where did I use this? ^^;.......

The Phoenix Wright thing, perhaps? I seem to remember that had a court-record button on-screen at all times, although I never looked at the code so I don't know how you did it.


But I agree with Chrono, really - don't make the point-of-contact class a displayable, just either give it some method that returns one, or even better have a set of displayable classes which take your point-of-contact class as a construction parameter. The OOP approach never intended to have monolithic do-everything classes; taking the inventory class as a constructor parameter makes it a lot more easy to extend it with new displayable schemes at a later date.

Can the secondary displayable classes be nested in the point of contact class or should I just make them separate classes completely? In the latter case is there a way to properly connect the class data of the PoC class to the displayable classes? I have not yet looked much into whether or not Python supports any data hiding (like C++ access declarations such as public, private, protected, and friend do).

EDIT: ... or if data hiding is even appropriate in this case, or in Python in general.

[monele]

Jake : Might be... I'd have to dive in the code of all my projects to find it ^^;...

As for OOP, I agree : try making a class that has no visual aspect whatsoever... only lists, variables, objects, etc... Then, make the visual class use this one. The good point is that one would be able to make another interface to suit his needs, yet keep using the same base. Your examples with bullet list and ring types could be exactly that. One class for Inventory, one class to show inventory as a list, one class to show it as a ring. The last two both use the first one.

[Gau_Veldt]

Jake : Might be... I'd have to dive in the code of all my projects to find it ^^;...

As for OOP, I agree : try making a class that has no visual aspect whatsoever... only lists, variables, objects, etc... Then, make the visual class use this one. The good point is that one would be able to make another interface to suit his needs, yet keep using the same base. Your examples with bullet list and ring types could be exactly that. One class for Inventory, one class to show inventory as a list, one class to show it as a ring. The last two both use the first one.

That's looking very much like the way to move with this one, having the manager separate from the presentation and actually, since I have to code the management part first anyways, the project is already heavily in that direction.

I've got the basic initialization, query and give shelled in which I'll be pushing into debug/test phase now. It's mostly making sure the code does the same thing as the comments.

[monele]

A few things I had to think about for my RPG inventory system :
What happens if the same object is added again? Is it a new entry? Does it stack? If it's a new entry and I say "remove this object from inventory", does it remove them all or just one instance?
(this is only interesting for games where one might carry 34 arrows and 3 potions of healing... as most point & click adventure games are about unique items).

[Jake]

What happens if the same object is added again? Is it a new entry? Does it stack? If it's a new entry and I say "remove this object from inventory", does it remove them all or just one instance?

Personally, for this kind of issue I would be tempted to make items either unique or nonunique, and have different classes/definitions/whatever for each. Then, the inventory manager class can overwrite or stack as appropriate. It might also be worth considering an optional 'quantity' on the remove method which simply defaults to '1'... maybe a 'removeall' to remove all instances of a particular class of item.

[monele]

Sounds like what I did for RPGBattle.... mmm.... Should I just post the code file? >.>... We coders keep redoing what others have done many times over ^^;

[Gau_Veldt]

A few things I had to think about for my RPG inventory system :
What happens if the same object is added again? Is it a new entry? Does it stack? If it's a new entry and I say "remove this object from inventory", does it remove them all or just one instance?
(this is only interesting for games where one might carry 34 arrows and 3 potions of healing... as most point & click adventure games are about unique items).

The current incarnation of my manager honors a "stacksize" attribute so items may have a maximum stacking. I have default values like Jake was suggesting as well for quantity in the methods for .give() and .remove(). The most common usage of .remove() (for consume-on-use) is handled by adding a "consumable" attribute for the item entry in the master list so scripts may just call the .use() method and the item will be consumed without any additional work.

The manager also supports different inventory groups (so you may use the manager for spells, story goals, combos, etc. as well as just the main items) and multiple inventories (for games with more than one character).

[Gau_Veldt]

Sounds like what I did for RPGBattle.... mmm.... Should I just post the code file? >.>... We coders keep redoing what others have done many times over ^^;

I blame that on the ability to seal everything in an archive which results in many projects that do not give any code back to help others as well as the general culture of secrecy that surrounds graphic novel design.