Inventory & Equipment

Items are assets

An ItemDefinition asset carries both representations of an item at once: a sprite for UI slots and a world model for dropped items and worn gear. Sprite is UI, model is world — an item with no model still works, and falls back to a generic placeholder crate when it lands on the ground.

Create one with Create → Party Core Kit → Inventory → Item Definition. Everything downstream — hotbar tiles, pickup prompts, drops, loot tables, the network layer, save files — reads the asset. Adding an item is authoring an asset, not editing code.

Carrying: the hotbar and the bag

CharacterInventory is one flat array of slots split into two visible regions: the leading slots are the hotbar, the rest are the bag. Selection cycles the hotbar; the bag is what the inventory window shows.

Wearing: five slots, and why bonuses live in stats

CharacterEquipment holds one EquipmentDefinition per slot — Head, Body, Legs, LeftHand, RightHand — and requires a CharacterInventory on the same object, because gear is moved in and out of the bag rather than existing separately from it.

An EquipmentDefinition is an ItemDefinition — it inherits every field above and adds the wearing ones. That inheritance is also the whole eligibility rule: the item type is the category. A piece fits a slot when it is equipment and its slot matches. There is no separate tag list to keep in sync.

// The entire eligibility check, from CharacterEquipment:
public static bool CanEquip(ItemDefinition item, EquipmentSlot slot)
{
    return item is EquipmentDefinition equipment && equipment.slot == slot;
}

Worn visuals attach to the rig's Humanoid bones — head to Head, body to Chest, legs to Hips, hands to LeftHand and RightHand — so any Humanoid character wears the same gear without per-character setup.

Dropping and picking up

Dragging a slot out of the inventory window — or right-clicking it — drops the stack into the world as a physical pickup wearing the item's worldModel. The drop is a real object — a trigger sphere for range, a collider and a rigidbody so it falls and rests, and an InteractableBehaviourthat shows a prompt once you are close. Activating that prompt — press, hold, or repeated press, whichever the item's pickupActivation says — puts the stack back in your bag.

Dropped items belong to the world, not to whoever dropped them: every player can see and take one, and they survive a save. That last part takes a little machinery, because a runtime-spawned object cannot be "remembered" the way a scene object can — there is nothing in the loaded scene to restore onto. The save holds a recipe instead (which item, how many, where it came to rest) and rebuilds the drop. See Saving & Loading for the three shapes persistence uses.

Set allowItemDropping to false on CharacterInventory for a game where items should never reach the floor.

Giving a player something

1. Author the item

   Create → Party Core Kit → Inventory → Item Definition. Set an id, a displayName, an icon, and a maxStack above 1 if it should pile up.

2. Add it to knownItems

   On the player's CharacterInventory, append the asset to knownItems. Skipping this works offline and fails online, which is the worst way for it to fail.

3. Hand it over

   Either place a pickup in the scene, add the item to a container's loot, or call AddItem from a rule or a script.

4. Press play

   The tile appears in the hotbar, the details pane reads the description, and dropping it puts the world model on the floor.

The API, if you want it

The surface is deliberately small, and every mutating call returns bool so a refusal is something you can branch on rather than something you discover later.

using Curitor.PartyCoreKit.Inventory;
using UnityEngine;

public class StarterKit : MonoBehaviour
{
    [SerializeField] private CharacterInventory inventory;
    [SerializeField] private CharacterEquipment equipment;
    [SerializeField] private ItemDefinition stone;
    [SerializeField] private EquipmentDefinition helmet;

    private void Start()
    {
        // false when there is no room -- the item is NOT silently eaten.
        if (!inventory.AddItem(stone, 10))
            Debug.Log("Bag is full.");

        // Equip from whichever slot the helmet landed in; whatever was
        // worn goes back to the bag.
        if (inventory.AddItem(helmet))
        {
            for (int i = 0; i < inventory.SlotCount; i++)
            {
                if (inventory.GetSlot(i)?.item != helmet) continue;
                equipment.EquipFromInventory(i, EquipmentSlot.Head);
                break;
            }
        }
    }

    private void OnEnable()
    {
        inventory.OnSlotChanged += HandleSlotChanged;
        inventory.OnSelectionChanged += HandleSelectionChanged;
        equipment.OnEquipmentChanged += HandleEquipmentChanged;
    }

    private void OnDisable()
    {
        inventory.OnSlotChanged -= HandleSlotChanged;
        inventory.OnSelectionChanged -= HandleSelectionChanged;
        equipment.OnEquipmentChanged -= HandleEquipmentChanged;
    }

    private void HandleSlotChanged(int index) { }
    private void HandleSelectionChanged(int previous, int current) { }
    private void HandleEquipmentChanged(EquipmentSlot slot) { }
}

The rest of the surface: GetSlot, FindItem (id to asset, through knownItems), MoveSlot, DropFromSlot, RemoveFromSlot, RemoveFromSelected, SelectSlot and CycleSelection; on equipment, GetEquipped, CanEquip, EquipFromInventory, UnequipToInventory and DropEquipped.

The windows

The inventory window supports mouse drag-and-drop and a gamepad-native select-to-move flow; container windows use hover-for-details, click-to-take. All of it is built from the toolkit's themed widget kit, so restyling your game restyles these screens too.

The window is opened by the Inventory input action — I on keyboard, Select on a gamepad by default — routed through a HotkeyBehaviour and a Toggle Object instruction rather than hard-wired. Rebinding it is editing the input asset; re-pointing it at a different panel is editing one instruction, no code either way.

Multiplayer