Inventory

Overview

Inventory defines the container layer of the PVERSE gameplay system. It determines how resources and certain gameplay assets are held, moved, and preserved across player activity through two primary containers: Bag and Storage.

This page is descriptive rather than balance-final. It explains the meaning of capacity, settlement, overflow, and movement rules while leaving exact kilogram values, bonuses, precision handling, and expansion parameters to future SSOT-controlled references.

Scope

Inventory defines how gameplay value is allowed to exist and move inside the Game Systems layer.

• Bag and Storage as distinct capacity containers
• kilogram-based settlement and occupancy interpretation
• strict overflow handling and atomic state transitions
• forward-only inventory integrity enforced through authoritative runtime logic

Core Model

The core model is that gameplay assets persist only if they can be settled into valid capacity. Inventory is therefore not merely a visual organization layer; it is part of the ruleset that determines whether a result becomes durable state.

• Bag is the primary gameplay container for immediate outcomes and active use
• Storage is the longer-term holding container for preserved assets
• capacity, occupied weight, and free weight are distinct runtime concepts
• inventory transitions must resolve atomically rather than through partial settlement

Operational Behavior

In operational terms, most gameplay outcomes are evaluated against inventory capacity at commit time. Discovery, mining, refining, forging, claims, or other inventory-producing actions only become durable if the selected settlement container can accept the result under current authoritative rules.

Players may also move assets between Bag and Storage when allowed by current policy. These moves are not cosmetic rearrangements; they are real container transitions that must pass server-side validation. UI may simplify the presentation of weight and stacking, but settlement and integrity are resolved from authoritative state.

Constraints

• this page does not hard-code final kilogram limits, subscription bonuses, or precision parameters
• inventory does not override broader security, economy, or participation policy
• overflowed outcomes do not settle partially by default
• future inventory rule changes apply forward-only and do not retroactively rewrite prior records

Integrity Considerations

Inventory integrity depends on clear separation of roles. Docs define meaning and behavior, SSOT owns mutable numeric parameters, and code enforces the settlement boundary that determines whether value can persist. This prevents “free storage,” partial commits, and hidden record mutation.

• authoritative inventory state is server-side, even if the client view is rounded or delayed
• inventory actions should commit atomically or fail without partial persistence
• historical inventory outcomes remain auditable even after future capacity or policy updates

Future Expansion

As PVERSE expands, inventory may connect to richer container types, more explicit warehouse tooling, mail claim routing, marketplace settlement paths, and future quality-of-life systems. The conceptual model should remain stable: gameplay value persists only through valid, auditable settlement into allowed capacity.

Summary

• Inventory defines Bag and Storage as the containers where gameplay value may persist.
• All container behavior is interpreted through kilogram-based capacity and settlement rules.
• Overflow handling is strict and favors atomic integrity over partial success.
• All inventory changes follow forward-only interpretation and remain auditable over time.