#Inventory

1 messages · Page 1 of 1 (latest)

olive hare
#

Assumptions

  1. Items in world are entities
  2. Must handle all types of games
  3. You have slots where items go, certain items can stack

Options for slots

  1. Slots are entities, referenced from a dynamic buffer
  2. Slots are dynamic buffer with general meta data

Options for items in slots

  1. Items in slots are the same entities that would exist in the world)
  2. Items in slots are custom slot entities
  3. Items in slots are just data stored in the slot
    the question i'm basically trying to figure out is, when an item is in a slot, what should be an entity?
    at work we go the full entity approach, slots themselves are entities, items when stored in inventory are just the same entity
    but it's been a huge pain but that might be more implementation than design

It gets tricky when you have stacking items, and large stacks of them
One of the flaws of our inventory at work are stacks of items become a single entity so you can no longer track individual item state
Durability is averaged or lost etc

Few more thoughts first though. The biggest question I have been going back and forward about are
Item slots - should they be entities?

Item slot as inventory
Pro

  • Versatile you can attach data and do cool things

Cons

  • Slower; lookups required to access
  • Tiny archetype so 128 limit kind of sucks
  • Generally have no logic so does it make sense to be an entity
  • State harder to maintain
    Then there is the whole, backpacks
    How does that play into slots?
#

i'm leaning against doing slots as inventories
but I am worried I am pigeonholing myself
how do i handle something having 2 separate inventories?!
do I just write this as a layer on top of a single buffer
this is basically been my thought process, layer the logic

Keep a very basic inventory operations on a single buffer
Add, Remove, Swap
Layer application specific logic on top of it
Inventory layout
Multiple inventories
Advanced inventory operations, transfer, slot restrictions, etc

#

performance consideration for me here is simply avoiding 20,000,000 slot entities
inventory operation performance is not really a consideration
The 1 consideration is inventory operations usually need to run single threaded
So it can bottleneck if game went crazy but I'll deal with that when I get to it
So the other half of this is,
Items in inventory slots, should they still be the underlying item/entity
Or should they be replaced by a simple representation
My current thought process is, both
Keep the existing item entity around to help maintain state, disable it and no longer replicate to clients
And create a simple inventory representation to replicate
Issues -> updating representation with state from item if it changes
Easiest way would be to add a slot reference to the item - should this always exist though? I don't like structural changes.

#

@strong crag

can you elaborate? is it networking issues?
because every system has to have checks/separate paths if the item is inventory or not.
Do an overlap sphere etc, check every entity etc

#

oh and also why does item logic have to be single threaded?
it's hard to make transactions safe otherwise

#

if you do 1 entity per thread, what if 2 separate entities want to pickup the same item in the same frame?
if you item by thread, what if you try to put 2 items into the same slot

strong crag
#

most of the time you dont care about the inventory anyways. like pickup etc. do you actually need to assign a slot in that moment?

#

cant you assign it only when inventory is needed

olive hare
#

I'm not sure what topic you are referencing

#

do you mean for threading?

strong crag
#

assigning slotIDs on pickup. its actually just relevant that the item is in the inventory. not where it is

#

im thinking about reducing the actual state needed on the item and having that slotstate maybe somewhere else

olive hare
#

well that's not really an issue i even thought about

#

i'm not sure why assigning the slot id on pickup would be a problem though

strong crag
#

i mean is it needed to have an inventory Entity that has a dynamicbuffer with slotentities and then those slotentities have again a dynbuffer of items? cant you just build the UI from an itemlist you get by quering all items in the inventory

olive hare
#

there's no inventory entity in any of my proposals

strong crag
strong crag
olive hare
#

ah sure

strong crag
#

its just me but i would not do a single dynamicBuffer having items of different inventories

olive hare
#

but yeah i don't think i want inventory as an entity in that case

olive hare
#

it would be
player -> inventory -> slot -> item

#

i guess the question is

#

when would i even need more than 1 inventory on an entity

strong crag
#

yes. slow but does it matter? at least for me the structure would be easy to grasp

strong crag
#

and a weapons stash at the same time

olive hare
olive hare
#

it's about usability

#

to check an item i need to do 3 lookups

#

i'd definitely need to aspect this

olive hare
strong crag
#

but here my point from above comes in. i miss the right words i think.
by tagging items correctly you can easily query them and get them into lists to feed to the UI

olive hare
#

or just different slot rules

#

that's what i've been grappling with

olive hare
#

that's easy

#

i'm barely thinking about client except for disabling items so they don't replicate

#

my thought process is entirely wrapped up in the server atm

strong crag
#

okay sorry im not used to thinking multiplayer ^^

#

but then do you ever need the actual slot where the item is at? would it ever matter aside from displaying it in UI?

#

so a shared component with InventoryID is all is needed on server no?

#

ah again chunk fragmentation cause we said to use the actual items...

olive hare
#

swapping items

strong crag
olive hare
#

i'm designing to handle all cases

#

but yes diablo like inventory would be a core implementation

#

or even just an inventory like game at work

#

which is just 12 slots on bottom of screen

#

with 2 sub inventories above, 4 for equipment, 4 for data and an optional backback inventory

#

but i also want to support things like ragnarok infinite size inventory but dependant on weight

#

this is why i want to layer logic

strong crag
olive hare
#

🤔

strong crag
#

give me a sec ^^

olive hare
#

backback 😄

#

i was very confused

strong crag
#

most complicated inventory i can think of right now^^

olive hare
#

never seen this game

strong crag
#

check out some gameplay. very interesting design

#

inventory is the main gamemechanic

#

items next to each other affect each other in certain ways

olive hare
#

i wish this game was called rat pack

#

or packrat

strong crag
#

yep pretty basic name

olive hare
#

Packrat definitely would have been so good

strong crag
#

well lets assume they did market research on that name theyve got

olive hare
#

we're meant to do market research on names?!

strong crag
#

its one of the questions i saw a lot of people asking testers

#

giving them some options to chose from after they have played your game. just to see which name best conveys the experience

olive hare
#

testers 🤣

#

haha yeah these are things we lacked

strong crag
#

i know right. hard to come by

#

its not something you would ask in a alpha release when players die xD

olive hare
#

🦗

strong crag
#

just from a user perspective (they are still used OOP) layering those concepts seems fine

#

or you give each item some kind of "path" where it is located in the inventory?

#

like /Herbs/Slot1/stackposition5

#

no idea how to make that performant but would be nice to use

olive hare
#

as weird as it sounds

#

it's too entities for me

#

i've transitioned from the phase of make everything into entities

#

i'm not sure i think things should be entities unless queries operate on them directly

strong crag
olive hare
#

it as a lot of complexity and just general slowness

#

and makes things like saving etc more complicated than need be

#

as well as just requiring exist checks everywhere

#

i have considered writing this whole inventory thing outside of entities

strong crag
#

as long as items you add are entities id say it doesnt matter how the inventory works

olive hare
#

exactly

#

but then i realized saving that would be even harder 😄

strong crag
#

but im still not over the shared component thingy.
what if you do have extra iteminventory entities that hold a reference to the stored item. that would allow you to use shared components to split the InventoryItemEntities into inventories and query them.
and items in stacks get their own stackID too. youd get rid of all the dynamic buffers

olive hare
#

i don't really see the point of the shared components

strong crag
#

im trying to invert the datastructure (not sure if i can call it like that sry)

olive hare
#

what is it letting me do

strong crag
#

instead of nesting entities and dynamicBuffers you have entities belonging to a Collection. it lets you store all the items a player has easily.

#

oh god im bad at explaining this im sry

olive hare
#

but does it not make querying them so much harder when i need them?

#

hmmmm

#

thinking

strong crag
olive hare
#

sure

#

AI can do all the same inventory operations

#

in fact there is no difference between my player and AI

#

you can take over and use any AI at any time

#

and then stop using and AI takes back over

#

i'm liking some concepts of this inversion

#

but i think it'd absolutely destroy my chunk utilization

#

it'd be 1 chunk per entity with inventory

#

that'd be like 10k chunks or 156MB

strong crag
#

yep i was not considering AI as having the same kind of inventory where slots matter

olive hare
#

i really need the concept of small chunks

#

before i think this is viable

strong crag
#

yes. i tried to do something similar in case of formations and had the same issues. chunk fragmentation is just too bad with shared components :/

#

(atleast now they can be bursted)

#

so what about the path idea?

olive hare
#

which was the path idea?

strong crag
#

having an item store /inventoryID/slotID/StackPos

#

and keeping that in one of your dynamic hashmaps

olive hare
#

funny enough, this is again what we do at work

strong crag
#

hmm hard to keep track again?

#

guess its a pain to swap items in slots