Skip to content

Inventory — Documentation Guide

Where should I start?

New to Inventory?

Start with:

👉 System Overview (README + Mental Model)

This explains: - What the Inventory system is
- How containers, stacks, and the service layer work together
- How Inventory integrates with Equipment, Use Effects, Crafting, Currency, and Pickups
- Typical setup and usage patterns

Want to know what you can safely depend on?

Read:

👉 PublicAPI/

This document defines: - The supported runtime surface - Stable types, methods, and events - Guaranteed behaviours and lifecycle ordering - Explicitly unsupported usage

This is the contract

If something is not listed there, it is not supported — even if it appears public in code.

Adding gameplay or extending the system?

Start with:

👉 Integration Surfaces/

This shows exactly where logic belongs: - gameplay mutations
- equipment rules
- item usage
- external system integration

Then use:

👉 FAQ/

The FAQ answers questions like: - Should I use the service or a wrapper? - Where should gameplay logic live? - How do I handle multiplayer authority? - Can I replace the host? - What should I avoid?

It focuses on decision-making, not API reference.

How these documents work together

Document Purpose
Overview Explains the system
Public API Defines what is supported
FAQ Guides correct usage choices
Integration Surfaces Shows where new logic should plug in
Mental Model Explains how to think about the system
Guarantees Matrix Defines behavioural contracts

Each document serves a specific purpose.
You do not need to read everything — start with what matches your task.

Important support note

RevFramework Inventory is:

  • Service-driven
  • Slot-based
  • Deterministic
  • Authority-aware
  • UI-agnostic
  • Netcode-agnostic

Support is provided for

  • Behaviour defined in PublicAPI
  • Usage patterns described in Overview, FAQ, and Integration Surfaces
  • Guarantees listed in the Guarantees Matrix

Support is not provided for

  • Modifying internal services or containers
  • Depending on undocumented behaviour
  • Reflecting into runtime internals
  • Treating public-looking types as supported by default

You will see one internal component, and that is correct

CharacterInventory declares [RequireComponent(typeof(InventoryOwnerHook))], so Unity adds InventoryOwnerHook alongside it and will not let you remove it while CharacterInventory is there. It is in an Internal namespace, it appears in your inspector and gets saved into your scenes — including the Inventory quickstart — and none of that is a mistake. Its whole job is to release the owner's tracked containers when the GameObject is destroyed.

Leave it alone: do not add it by hand, do not configure it, and do not write code against it. "Internal" here means not a surface you drive, not should not be present.

  • Teaching Panels
    Add debug or teachable panels (Editor / optional tooling) to visualize behaviour live

  • Samples
    See Samples/Systems/Inventory/ for runnable examples

  • MkDocs site
    Mirrors this documentation for web browsing

System philosophy

Inventory is:

  • A service-controlled system (not component-driven state)
  • A container model (not arbitrary item lists)
  • A result-first API (no silent failures)
  • A replaceable host architecture (no lock-in to our implementations)

Every public API surface exists for a reason.
If something feels unclear, you're likely using the wrong extension seam.

TL;DR

TL;DR

  • Want to understand Inventory → Overview
  • Want to build safely → Public API
  • Want to choose correctly → FAQ
  • Want to extend cleanly → Integration Surfaces

If you stay within these boundaries, Inventory will behave predictably and remain future-proof.