Endacopia items

The official room screenshot shows small icons along the lower portion of the scene that appear consistent with an inventory or action strip. The image alone does not preserve readable item names, descriptions, acquisition order, or input behavior. This archive therefore avoids assigning names based only on pixel silhouettes.

That restraint matters because a mistaken item label propagates quickly: walkthrough steps, puzzle pages, alt text, and search snippets all inherit it. The data model keeps a temporary visual descriptor separate from a canonical name so editors can update one field without losing the original observation.

Each item record should contain canonical name, descriptive alias, first acquisition location, acquisition condition, inspect text, visible features, inventory icon, compatible targets, failed reactions worth preserving, confirmed uses, consumed or persistent state, and build version. Sources should point to either direct gameplay capture or official material.

A confirmed use should state both action and consequence. 'Use item on object' is incomplete if the action changes another room, unlocks dialogue, or returns a transformed item. Record the entire state transition so the walkthrough does not omit the reason the step matters.

Start with function. What could the item physically, symbolically, or comedically do? Then identify targets with a matching need. A rigid tool suggests leverage or adjustment; a container suggests holding or transferring; a marked object suggests matching symbols or identity. Endacopia may deliberately subvert these expectations, but a reasoned test remains more informative than brute force.

Use feedback as a classification signal. A generic rejection may mean the target is irrelevant. A unique joke or animation may mean the relationship is recognized but incomplete. A partial state change may indicate that the right target lacks a prerequisite. Preserve distinctive feedback in notes without copying long stretches of game text.

Some adventure items change after use: opened, filled, broken, combined, activated, or returned. Treat each meaningful state as a variant linked to the same base entity. This prevents a guide from telling the player to use an item that no longer exists in that form.

State tracking also clarifies optional versus mandatory actions. If two routes produce different variants, document both and identify whether they converge later. Do not assume that a demo supports only one route until a clean replay confirms it.

The main item index should show icon, name, first safe description, and acquisition chapter only when that information is not itself a twist. Exact uses belong in collapsible sections or puzzle pages. Search cards and metadata should never reveal a late-game transformation or final target.

The item archive remains methodological where exact names and functions have not been reproduced. Records should come from a clean, versioned playthrough rather than community recollection.

Capture the inventory before and after each acquisition. Transcribe the exact item name and inspect text. Test whether selection persists across scenes, whether items can be combined with each other, and whether using an item consumes it. Record at least one representative failure response only when it helps identify intended logic.

After verification, update items.json, the walkthrough, puzzle cross-links, media manifest, and route review date together. This keeps the database and prose aligned.