Reading through old topics, I kind of understood it that an item is an entity that either can be linked to the player by an InInventoryOf component or I can use an InContainer component to link it to a bag and then use an OwnedBy/ChildOf component on the bag entity to link it to the player.
Not sure which approach I should follow.
The idea with bags seems complicated, if I want to know who is the owner of an item I must first get its bag then get the owner from the bag.
What are the use cases for having bags? (except that I can organize stuff visually which I can do in the first one as well)
An item can be in a chest on the ground. Who owns it?
An item can be in a bag on the ground and then that bag picked up by the player. Who owns it?
When is âownershipâ actually needed and what for?
InContainer is very clear (and can even have container position as part of it if there is never a reason to separate them). It does just the aspect it says: âthis entity is inside this other entityâ. Whether the container is a chest on the ground, a bag being carried, or the playerâs hand just depends on how you want to model things. (I think my first approach had inventory slots: left hand, right hand, back, belt, etc. to which items could be attached⌠and those items could be containers. So âinventoryâ and âcontainersâ were separate.)
If you need to find out âwhat player is holding this arrowheadâ then that seems like a relatively rare request and itâs probably ok to see that itâs in a small silver box inside of a bag inside of the playerâs backpack.
For me, it was only during transitions that I cared about this stuff. And there is almost a transactional quality to it because you donât want the InContainer to get removed and the world Position not to get set when something is dropped on the ground. You have to make sure to always do them both together. I struggled with several ways to do that when Iâm running âtakeâ and âdropâ scripts and have to sort that out through container hierarchies and stuff. (Example I used was a cursed item that the player is not allowed to drop.)
âŚin the end, I cleaned up a lot of problems by leaning into the ES ideas and using a MoveTo component. A separate system would handle the script mechanics and kept multiple systems from trying to write the same components. (The âcursed itemâ thing is still tricky as you need âCanDropâ handlers and such.)
I donât know what the best solution or if I will think of something better for the new engine but thatâs essentially where I ended up last time I played with this.
For example in combat. An enemy NPC can have multiple weapons that can be used in different combat situations (near attacks, far attacks,âŚ). So the combat system wants to check what weapons an NPC has in his inventory to automatically take a proper one based on the situation. Here it does not matter where the item is, in his back, in his bag,âŚ
I mean, it could matter if you want to model each search as an action. Pulling a potion from his belt versus rummaging around in the bag he keeps in the bottom of his backpack.
Either way, searching for an item is not particularly difficult or costly. And that would depend on how deep you allow your inventory to be. Is the NPC the container or does have have backpacks and bags and boxes and stuff? If the former then itâs no problem⌠if the latter then you canât really get away from searching anyway.
And maybe the AI just needs quick slots like the player has.
Regarding loot items. Are you handling them like real items that have all the stats and stuff on them or they are just a placeholder for a real item that when picked up, the âtakeâ script will make a real one?
This is only âthe planâ because none of this was implemented yet.
âŚbut loot drops would be real items. I needed NPCs, mobs, etc. to be able to interact with them just like any dropped object. So itâs easier if they are real and not a particularly strong reason for them not to be real in my case.
Do you ever had an idea for shared containers in your game?
For example in multiplayer game, when a team member finds an object that can be used by others (like a key to a door) you put it to that shared container so anyone can use it.
Or a loot container, so when a team member finds a loot, it will go into that container and only Game Master should be able to take them and split them among players.
Items that are non-unique can stack, like a stack of health potions, a stack for mana potions, a stack of arrows, etc etc
But an item that can possibly have unique instances (like a weapon-item that can be customized, leveld up, has durability, etc) should not stack, so that the player can differentiate between them in their inventory.
Thatâs how I do it for my game, and most games do it this way I think. Like minecraft does not let you stack pickaxes or armor - but you can stack iron ore, seeds, and other non-unique items
Yes, I check for an isStackable() boolean on the item, and if its true I increase the quantity, otherwise if its false and not stackable I create a new instance of the Item that gets added to the list of items.
I should note I do not use Paulâs Zay-ES since I started my project before I knew of many extra libraries like that. But I think I do things in a way that sounds similar to an entity sytem in a lot of cases.
You mean a container that actually exists in multiple places? So it can be opened anywhere in the world?
When an object is clicked to open the container it runs the open script for that entity⌠which will popup the inventory for some entity on the userâs screen. They need not be the same entity.
For stackable items, the entity is not the item but the stack⌠so when itâs only one item itâs just a stack of 1.
So if potions can be stacked, you are never holding a âpotionâ but always a stack of potions⌠which may only have one item in it.
In my original engine, the handler scripts could be chained⌠so the âuseâ action of âpotionâ and the âuseâ action of âstackâ would both be called. The latter would decrement the count and destroy the entity if 0.
I think I didnât implement stacks yet in that version of Mythruna but I canât remember. Iâm 99% sure that I did in a little 2D RPG I started just to play with inventory mechanics. So this is just from memory.
No I mean a virtual container which has not a position on scene, it is just visible from inventory menu and will be displayed for all players. I find a key and put in there then all other players can use that key to open locked doors.
A stack is an item like any other item. It just has a limited number of uses.
So, whatever question you are going to ask next, if you can do it with a âswordâ or âa penâ or âan amuletâ then you can do it with a stack⌠because a stack is literally just an item with an extra StackCount component or something.
Exactly the same as an item. It is an item. Itâs just when you run out of uses it disappears.
Edit: like a wand with a certain number of recharges. Itâs not a âspecial kind of thingâ⌠itâs just another item that when there are no more âwhateverâ then itâs gone.