Not Every Inventory Item Needs to Be a UObject
Separating identity, state, and behavior in a networked Unreal Engine inventory
Why should a stack of stone need its own UObject? In my first inventory model, every item had one, even when it had no item-specific behavior or custom state.
Even a simple stack of stone had a UItem, so every operation-adding it, removing it, saving it, replicating it, or transferring it- had to manage that object as well. But the stone had no object-specific behavior or state: all meaningful data already lived in the inventory entry. It needed an item key, not a separate UObject with its own lifecycle.
The mismatch became clearest while I was designing inventory-to-inventory transfer. Consider moving a stack of stone from a chest to the player's backpack. In ISK, a runtime UItem belongs to the inventory component that created it and is replicated through that context. Reusing the chest-owned pointer would put the entry...
Copyright of this story solely belongs to hackernoon.com. To see the full text click HERE
