Yes, you’re not the first person building a store/catalog and inventory system on Nakama. The implementation details vary depending on the use case but here’s a typical one.
Store/catalog:
- A collection called
catalogwith keys representing items that can be purchased. - Keys are usually item IDs of some sort.
- Owner is the system user.
- Permissions allow public read access to the object.
- Value usually contains information like price, description etc.
- The store can be browsed from the client directly with the appropriately filtered storage listing request.
- Purchases are made through a RPC function that deducts from the user’s wallet and adds the item to their inventory.
Player inventory:
- A collection called
inventoryrepresenting individual player inventories. - Keys are either item IDs or a unique reference for the item (the guid you’re suggesting, assigned at purchase time in the purchase RPC function).
- Owner is the player user ID.
- Permissions allow owner read but no write access.
- Value contains perhaps info about the number of copies of that item you own (unless each copy is its own key with its own guid like you propose).
- Listing items to view the inventory is again a storage listing operation.
- RPC functions can be exposed to move items around the inventory, “consume” items, or whatever is appropriate.
Generally there’s enough logic that needs to live in RPC functions (purchase exchange of item for currency) that assigning an ID to the purchased item being done in the server rather than database hasn’t been a problem so far.
In my opinion I would key inventory items on the item ID that matches the store/catalog entry for that item, and in the value somewhere I would track how many copies of that item the player owns.