Skip to content

Needs, Survival and Inventory

See Player/README.md for the verification-debt caveat.

1. Needs: hunger, today

A need is a value that drains on its own over time and only goes back up when something restores it — hunger is the one need actually configured right now (14_NEEDS_FRAMEWORK.md). Your hunger starts full and counts down toward empty over real time; nothing currently happens when it reaches zero — no damage, no penalty — because there's no Health system yet to apply one (14_NEEDS_FRAMEWORK.md §6). Eating restores it; see §3.

One real behavior change from the original game, worth knowing if you played it: the original's hunger ran the other way — 0 meant fine, 100 meant starving. Here it's flipped so the number you see actually means what it looks like it means: full is high, empty is low (14_NEEDS_FRAMEWORK.md §1).

Not built yet: thirst, temperature, disease, stamina, and every physical state (knocked out, tied, exhausted, and so on) that the original game had. The framework is built so adding these later is configuration, not new code — see 14_NEEDS_FRAMEWORK.md §2 — but none of them exist to configure yet.

A real gap to know about: hunger decay between your last meal and a server restart is lost — nothing saves it on a clean shutdown yet (14_NEEDS_FRAMEWORK.md §4). You won't lose progress you made by eating; you might get a small, free top-up from a restart's timing, which isn't intentional and isn't something to rely on.

2. Inventory

Your inventory has limited space — items take up space, not weight, and a full inventory is a full inventory regardless of how light everything in it is (Code/Inventories/README.md). Some items — pockets — are negative-size and grant extra space rather than using it. The same inventory system backs your character, a world container, and (in the future) a vehicle or a corpse — it behaves identically everywhere it's used.

Every item you're carrying is a distinct, individually-tracked instance, not a bare count — two identical-looking items in your inventory are two separate things, not interchangeable (ADR-0006). This is a direct fix for a defect in the original game, where two copies of the same item were indistinguishable.

Not built yet: nested containers you can actually open in-game (the data model supports it; the interaction to open one doesn't exist yet), and a virtual/shared container concept like a bank vault.

3. Using an item

Every item is built from a set of small, reusable behaviors, not custom code per item (09_ITEM_FRAMEWORK.md §2). Two behaviors exist today:

  • Edible — restores a need by a fixed amount. Eating a Delicious Cake restores hunger, for example.
  • Equippable — occupies a holster slot (Small or Large) and may consume ammo. What doesn't work yet: equipping an item doesn't yet actually give or select the weapon in your hands, and nothing enforces the holster-slot limit — the service that does both isn't built. The item data itself is real and correct; using it to actually equip something isn't wired up yet (09_ITEM_FRAMEWORK.md, see the Equippable listing).

Using an item goes through a real request-and-wait flow, not an instant effect — some interactions (like equipping) take time and can be interrupted (you moved out of range, you died, you dropped the item) — see 10_INTERACTION_FRAMEWORK.md if you want the full mechanism.

If you're an admin testing content rather than playing normally, /give <itemAssetId> [count] spawns an item straight into your own inventory — see 01_CHAT_AND_COMMANDS.md.