Skip to content

🎒 Inventory — What This System Does (and Doesn’t Do)

This page explains what the Inventory system is responsible for and what is intentionally left to you.

No code. No implementation details. Just boundaries.

✅ What Inventory does

Inventory is responsible for:

  • Managing item definitions
  • Managing item stacks
  • Managing slot-based containers
  • Supporting multiple named containers such as Backpack, Hotbar, Belt, or custom containers
  • Handling exact add, max add, remove, split, merge, swap, move, and transfer operations
  • Returning explicit operation results instead of hiding failures
  • Supporting container resizing, including safe truncation rules
  • Supporting slot acceptance rules and filters
  • Supporting equipment slots and equipment filters
  • Supporting item use effects through public extension seams
  • Supporting container change events and deltas
  • Supporting JSON snapshot capture and restore helpers
  • Supporting missing item handling during snapshot restore
  • Supporting authority checks when mutations go through the inventory service

👉 In short:

Inventory owns item storage, stack movement, equipment storage, and inventory mutation rules

❌ What Inventory does not do

Inventory intentionally does not provide:

Persistence

  • No automatic save system
  • No cloud sync
  • No profile management
  • No automatic save/load timing

Inventory can capture and apply snapshot JSON, but you must decide:

  • when to save
  • where data is stored
  • when to load
  • how saves are versioned
  • how saves are synced or backed up

Networking

  • No replication
  • No prediction
  • No rollback networking
  • No multiplayer state sync

Inventory supports authority checks through interfaces, but you must implement:

  • server ownership
  • client permissions
  • replication
  • reconciliation
  • multiplayer UI sync

Authority Rules

  • No built-in multiplayer ownership model
  • No hardcoded player permission rules
  • No assumption that every game uses the same authority policy

Inventory can ask:

👉 “Is this owner allowed to mutate this inventory?”

But:

👉 You define the answer

UI / UX

Inventory does not provide a full production UI.

It provides:

  • bindable read models
  • container access
  • operation results
  • change events
  • presentation helpers

You still own:

  • inventory screens
  • drag-and-drop UX
  • item tooltips
  • item icons and layout
  • player-facing error messages
  • controller/gamepad behaviour
  • accessibility choices

Item Design

Inventory stores and moves item data.

It does not decide:

  • what items exist
  • how rare they are
  • how valuable they are
  • what they do in your game
  • how they affect stats
  • how they are balanced

Item definitions provide structure.

👉 Game design is still yours.

Equipment Gameplay Rules

Inventory supports equipment slots and filters.

It does not automatically provide:

  • stat modifiers
  • character builds
  • animations
  • combat changes
  • class restrictions
  • socketing systems
  • durability loss rules
  • multiplayer equip validation

Equipment answers:

👉 “Can this item go in this slot?”

Your game answers:

👉 “What does that equipped item actually do?”

Item Effects

Inventory can resolve and apply item use effects through extension seams.

It does not prescribe:

  • healing rules
  • damage rules
  • buff systems
  • cooldowns
  • consumable balance
  • VFX/SFX
  • targeting models

The item use system is a hook point, not a whole ability framework.

🧠 Responsibility Split

Responsibility Owner
Item definitions Inventory
Item stacks Inventory
Slot containers Inventory
Add/remove/split/merge/swap/move/transfer Inventory
Equipment slot storage Inventory
Equipment acceptance filters Inventory
Inventory operation results Inventory
Container change deltas Inventory
Snapshot JSON helpers Inventory
Save/load timing You
Save file location You
Cloud sync You
Networking You
Authority rules You
UI / UX You
Gameplay balance You
Stats, buffs, combat effects You
Full ability system You

🧩 The Mental Shortcut

If you’re ever unsure:

  • “Where is this item stored?” → Inventory
  • “Can this stack fit here?” → Inventory
  • “Can this slot accept this item?” → Inventory
  • “Did this inventory operation succeed?” → Inventory
  • “When should I save this data?” → You
  • “Who is allowed to mutate this inventory?” → You
  • “How is this shown to the player?” → You
  • “What gameplay effect does this item have?” → You

🔐 Authority Reminder

Inventory service mutations can respect authority.

Direct convenience components may expose local container operations for simple setups and demos.

That distinction is intentional:

  • Use the inventory service when authority matters.
  • Use direct component helpers only when local convenience is acceptable.
  • Do not treat direct local helpers as your multiplayer security layer.

👉 If your game has ownership, multiplayer, server validation, or anti-cheat concerns:

route mutations through your authority-aware service layer.

🧪 Result-First Behaviour

Inventory operations return explicit result codes.

That means failures are meant to be handled, not guessed.

Examples include:

  • no space
  • not enough quantity
  • empty slot
  • invalid arguments
  • filter mismatch
  • missing slot
  • swap blocked
  • no authority
  • partial transfer

👉 The result is the contract.

Your UI, logs, tests, and gameplay code should read the result and respond properly.

🎯 The Point

Inventory is designed to be:

  • Predictable
  • Modular
  • Explicit
  • Service-friendly
  • UI-friendly
  • Testable
  • Safe to extend without depending on internals

It gives you:

👉 a reliable item storage and mutation layer

It does not try to be:

👉 your entire RPG, survival game, MMO, shop system, loot system, or UI framework

TL;DR

Inventory stores, moves, equips, and reports item state.
You own persistence, networking, UI, authority policy, and gameplay meaning.