What equipment / inventory system should I use for my project?

[Madui]

Some months ago I started a Godot Mock-up project that runs a simple dungeon crawler based off of

You must be registered to see the links

. It's part of a bigger project that aims to create a procedurally generated word filled with user-generated content.
The inventory system that I wrote for it is way too complex and requires too much maintenance when other part of the code are worked upon; I'll sum it up briefly:

- All races in the game have 1 to n "Default bodies", these determine the standard starting body for that specific race and can be different for various genders.

- All bodies contain 1 to n "Components", these represent individual components of the body, such as limbs and organs.

- Components are flagged with a "has_equip_slot" flag that is true for limbs that can somehow have something equipped on them (e.g. hands can have gloves) and are false for organs and limbs that cannot equip items (e.g. a livers and wings both can't wear clothing).

- All of the mentioned objects have an arrayof tags associated to them, these are used by the game to identify some propreties about them.

The pros of this system are:
- Allows the player to define every component of a species body down to its limbs and organs.
- Allows the player to define different bodies based on the different genders of a spieces.

The cons are:
- Code is complex and requires extensive tailoring around other pieces of code (e.g. events).
- Requires a dynamic UI in order to have a comfortable equipment menu.
- Might be too complex for users to understand / use comfortably.
- Is overkill for the scale of the project

Since I'm set on canning this system entirely I though that it was best if I asked someone with more experience for a system that I could substitute it with.
The features that I would like to achieve are these :

- Good flexibility around the character race, as it's the main reason that i'm not using a traditional RPG system, that usually have hard-coded slots.
- Decent level of detail, in order to expand what TiTs already offers, to allow the player to have more variables to customize their character with.
- Simple structure as to lower the code maintenance down to a minimum

I know that a system with all of those 3 is probably impossible to achieve, but if you guys know of any particular model that can check some of the boxes that would be a great help.

 

[Winterfire]

Keep it simple and actually use the traditional RPG system with hard-coded slots, it is not bad.
If a specific race cannot use a slot, disable it by loweing the opacity to 50% and make it not interactable, it shows the player that it is a possibility, just not for said race (Example: Boots, for a feline race having beast feet).

You could extend it further by having invisible slots like TES games, so again a feline race would actually make use of said invisible slot to have a tail item attached to them. Not something a player can or should be able to take off, but you can do so within the code if a particular item is meant to hide the tail (or any other attachment a race has).

 

[Madui]

Keep it simple and actually use the traditional RPG system with hard-coded slots, it is not bad.
If a specific race cannot use a slot, disable it by loweing the opacity to 50% and make it not interactable, it shows the player that it is a possibility, just not for said race (Example: Boots, for a feline race having beast feet).

You could extend it further by having invisible slots like TES games, so again a feline race would actually make use of said invisible slot to have a tail item attached to them. Not something a player can or should be able to take off, but you can do so within the code if a particular item is meant to hide the tail (or any other attachment a race has).

If I went for a hard coded system I would encounter two issues:

- The character class would be bloated with flags and/or equip slot objects that are not used by the specific character (like TES games)
- The player couldn't create new equipment types for custom races or would have to workaround this limitation with unstable solutions (again, like TES games)

But:

- It's the best system code-wise because it's simple.
- It requires way less UI work.
- Allows for less uncertainty in events and other scripts as it requires less checks to be read.
- Players are already familiar with these structures.

Any workaround regarding the cons? It's the second one that I particularly aim to resolve, as it is a big point on the project goals.

 

[Winterfire]

If I went for a hard coded system I would encounter two issues:

- The character class would be bloated with flags and/or equip slot objects that are not used by the specific character (like TES games)
- The player couldn't create new equipment types for custom races or would have to workaround this limitation with unstable solutions (again, like TES games)

It is a tried and working system. A class with some unuseable variables is perfectly fine, it is meant to be a template and as long as it's reuseable, it's doing its job.
Calling it "bloat" and rejecting a whole system is premature optimization, which is bad.

 

[Satori6]

There is a tool for Rimworld called Humanoid Alien Races Framework. It could be worth looking into its code, because it does a similar thing to what you're aiming for.

 

[anne O'nymous]

- The character class would be bloated with flags and/or equip slot objects that are not used by the specific character (like TES games)

Why the fuck do you want the slots, and in fact the inventory itself, to be part of the character class ? There's no real interest to use POO if it's for you to have tote bag classes.

As you describe your characters, it should be a class embedding two subs classes. The Character class, that handle the physical description of the character (how many limb, what limbs, etc.), the Stats class, that will be embedded and handle the game description of the character (what are his stats, how they works, etc.), and the Inventory class, that will also embedded, and handle the inventory.

Of course, it will not change the fact that the inventory class would have unused slots, but:
Firstly, it's just half a problem. Classes are meant to have unused content, it's where they really enhance your code. Apparently Python's duct typing have contaminated me...
Secondly, this can perfectly be easily solved. It suffice to have a class to handle the slots themselves, and you would only have as many objects than what you effectively need.

In the end it leads your characters looking like:

character:[Object of Character class]
    stats: [Pointer to a Stats class object]
    inventory: [Pointer to an Inventory class object]
        slots: [Dictionary of Pointer to a Slot class object]
        display( slotID ): [Function returning a widget for the slotID slot]
        list(): [Function returning all the slotID, or possibly slotID:Pointer_to_corresponding_object pairs]
        canAdd( item ): [Function returning True/False depending if the inventory have or not a slot that can accept the item]
        add( slotID, item): [Abstraction function that internally will point to slotID.add( item )]
        [...]

Both "stats" and "inventory" classes being created when you finalize the character creation, and directly tweaked accordingly to the character physical composition. By example, a character with four legs is expected to be faster than one with only two legs, and while creating the stats object, you would then pass the modifier value for the speed stats, and it's the only time when you would have to care about what the number of legs imply for the stats.

- The player couldn't create new equipment types for custom races or would have to workaround this limitation with unstable solutions (again, like TES games)

Are you really sure that Godot is the engine you want to use for your game mock-up ?

Perhaps is it grumpy me talking, but it really looks like, whatever your knowledge of the language itself, you don't have yet the knowledge to use it at such level of algorithm.
I mean, there's absolutely nothing in a slots approach that prevent the player to create custom races, nor to create custom equipment or to tweak existing one to fit a custom race. This whatever if you use a frozen or dynamic slots approach. It's just a question of algorithm, and therefore code design. A design perfectly doable in C#, a bit less easily in C++, more natural with Java/EcmaScript, totally natural with Python. Therefore, the level of code design experience needed will depend on the language used.

Even with a dynamic slots approach, the player will be limited by the kind of limb/organ that can be created. This simply because you can't have him create a Sdoutiede organ that will make his Poootsy organ works faster ; it would be possible with a script language. But with a compiled one, handling this kind of creation would double the size of your code because you would have to create by yourself all the dynamism implied by that. And like you struggle with just the inventory, I don't want to imagine how you would struggle with that part and its implication both in regard of the stats, computation and text.
Therefore, there's just a defined number of limb/organ that would appear an undefined number of time. Each one of those limb/organ being able to host a defined, or not, number of equipment. It's relatively basic as approach with a POO design.
Hint: look at the way slots are handled.

- It requires way less UI work.

You are using classes, whatever the way you handle the inventory if should imply the exact same UI work.
You have an "inventory" extendable/scrollable widget that will host as many equipment/slot widgets as needed for the given character ; equipment/slots widgets that are directly returned, and handled, by the Inventory class.

 

[Madui]

Why the fuck do you want the slots, and in fact the inventory itself, to be part of the character class ? There's no real interest to use POO if it's for you to have tote bag classes.

As you describe your characters, it should be a class embedding two subs classes. The Character class, that handle the physical description of the character (how many limb, what limbs, etc.), the Stats class, that will be embedded and handle the game description of the character (what are his stats, how they works, etc.), and the Inventory class, that will also embedded, and handle the inventory.

I described the structure incorrectly, sorry. All in game characters are an object of "Actor" class, and all Actors contain an "Attribute handler" class.
The Body, Inventory and stats of an Actor are all different classes that the handler is designed to work with and are instantiated as child nodes of the handler.
In retrospective I kinda should have started by mentioning this...............

There is a tool for Rimworld called Humanoid Alien Races Framework. It could be worth looking into its code, because it does a similar thing to what you're aiming for.

Thanks for the info, I read the docs and it seems like it uses a hard coded structure.

Based on what you guys say it looks like the best course of action would be to make the switch to a traditional hard coded structure, I'll think about it a couple more days then get to work. Thanks for all of your inputs.

 

[anne O'nymous]

Based on what you guys say it looks like the best course of action would be to make the switch to a traditional hard coded structure,

Yeah, totally. Using an inventory class that handle, in a duck typing like way, a dictionary of slot objects, is the strict definition of "traditional hard coded structure"...

 

[eugeneloza]

I guess I'm working right now on this kind of inventory system in my game and I planned to finish it in Summer, and still knee deep in it (plus it's an amazing motivation killer ). Initially I wanted to implement a hierarchical structure of the inventory (bodyparts are almost identical to inventory slots), but eventually decided against it - so there is a "Blueprint" (aka race) which defines the available body and inventory slots. I'm still thinking about attachment slots for inventory items, but not yet sure, most likely they'll just be item's properties like enchantments. The biggest challenge in this system is multi-slot items, which may be relatively bizarre (like catsuit which takes most of the clothing slots) and "projecting" it over shape and pose (which would have been easier with a boned skeleton, but I'm not an artist, so I have to resign to regular stack of 2D images "+" better for performance "-" no hope for animations except the most simple ones like blinking).

So, in more detail:

> Good flexibility around the character race, as it's the main reason that i'm not using a traditional RPG system, that usually have hard-coded slots.

Technically the slots are still hardcoded. Because too many game system rely on them. E.g. monsters attack specific slots and the outcome of attack is different depending on if there were clothes or restraints in the slot or if it was empty. However, each blueprint (race) can miss some slots. Like nagas don't have feet.

> Decent level of detail, in order to expand what TiTs already offers, to allow the player to have more variables to customize their character with.

Depending on the goal - you may go as wild as you wish. In my game clothing damage is one of the primary systems, so I need to show the important slots on the screen. And to have the game mobile-friendly, those should not exceed 15 But there are multiple body slots (which work exactly same as equipment slots but are not displayed all the time) and virtual/render slots which are logic-only. But if you want only customization, then you may skip on-screen UI/UX design and just go with as many as you see fit.

> Simple structure as to lower the code maintenance down to a minimum

Unfortunately it was kinda complicated. The resulting code itself wasn't too big, but it's convoluted and took me several "rewriting attempts" to hopefully get right. As I've mentioned - half a year in free time. And it's not yet done - though I feel like I've finally nailed it, so now will just to carefully implement ability to change paperdoll pose on demand (by equipment) and hopefully it'll hold tight

 

[Madui]

I guess I'm working right now on this kind of inventory system in my game and I planned to finish it in Summer, and still knee deep in it (plus it's an amazing motivation killer ). Initially I wanted to implement a hierarchical structure of the inventory (bodyparts are almost identical to inventory slots), but eventually decided against it - so there is a "Blueprint" (aka race) which defines the available body and inventory slots. I'm still thinking about attachment slots for inventory items, but not yet sure, most likely they'll just be item's properties like enchantments. The biggest challenge in this system is multi-slot items, which may be relatively bizarre (like catsuit which takes most of the clothing slots) and "projecting" it over shape and pose (which would have been easier with a boned skeleton, but I'm not an artist, so I have to resign to regular stack of 2D images "+" better for performance "-" no hope for animations except the most simple ones like blinking).

So, in more detail:

> Good flexibility around the character race, as it's the main reason that i'm not using a traditional RPG system, that usually have hard-coded slots.

Technically the slots are still hardcoded. Because too many game system rely on them. E.g. monsters attack specific slots and the outcome of attack is different depending on if there were clothes or restraints in the slot or if it was empty. However, each blueprint (race) can miss some slots. Like nagas don't have feet.

> Decent level of detail, in order to expand what TiTs already offers, to allow the player to have more variables to customize their character with.

Depending on the goal - you may go as wild as you wish. In my game clothing damage is one of the primary systems, so I need to show the important slots on the screen. And to have the game mobile-friendly, those should not exceed 15 But there are multiple body slots (which work exactly same as equipment slots but are not displayed all the time) and virtual/render slots which are logic-only. But if you want only customization, then you may skip on-screen UI/UX design and just go with as many as you see fit.

> Simple structure as to lower the code maintenance down to a minimum

Unfortunately it was kinda complicated. The resulting code itself wasn't too big, but it's convoluted and took me several "rewriting attempts" to hopefully get right. As I've mentioned - half a year in free time. And it's not yet done - though I feel like I've finally nailed it, so now will just to carefully implement ability to change paperdoll pose on demand (by equipment) and hopefully it'll hold tight

This sounds really interesting, especially given the fact that you are putting it in a 2D view. I'm going for a text-based main screen with a 2D secondary screen like TiTS, so I'm going for static portraits for the time being.