00 — Pickups Quickstart (Minimal)¶

Goal¶

Show the smallest honest pickups flow and prove that pickups can execute behaviour without depending on Inventory or other systems.

This scene demonstrates two valid pickup execution paths:

The core mental model is:

Actor + Effect → Runner dispatch → Effect decides behaviour

The pickup system provides the flow and execution, but does not enforce where results are stored or how they are handled.

There are two observable flows in this scene:

Interactable handles input — this one is in PressToPickup mode, interact key F
Stand in its trigger and tap F; walking through it alone does nothing
Custom logic runs instead of Inventory integration
Item id is added to a simple runtime container
UI updates to reflect the change

Actor and Effect are bound explicitly
Preflight shows:
IDamageable availability
Null-target support
Dispatch path (Reporting / Context / Standard)
Apply calls PickupEffectRunner.TryApply(...) and prints the bool it returned
Result message is the source of truth — including when it says the payload was refused

This scene covers:

This scene does NOT cover:

This scene may include a permissive sample authority setup for demonstration purposes. Production projects should enforce their own authority rules.

No networking is included in this sample. Multiplayer integration (Mirror, NGO, Photon, etc.) is the developer’s responsibility.

Enter Play Mode
Test Trigger Pickup (Teleport)
Walk into the cube
Observe immediate effect execution (teleport)
Test Interactable Pickup (Sword)
Move into the sword's trigger
Tap F (its interactKey; the mode is PressToPickup, so holding is not required)
Observe item added to the runtime container
UI updates immediately
Test Quickstart Panel
Assign:
Actor → Player
Effect → PickupEffect
Review Preflight:
IDamageable
Allows Null
Dispatch path
Click Apply To Actor
Observe result message
Make the panel report a refusal
TeleportEffect carries a 1 second cooldown
Click Apply To Actor twice in quick succession
The second result comes back as refused, not as a green "Applied…" — that is the cooldown gate reporting itself through TryApply
The cooldown is keyed per (owner, effect), so walking into the teleport cube also starts it for the Player

Failures come from the runner validation and effect execution path:

No Actor assigned Meaning: runner has no target Fix: assign a valid GameObject
No Effect assigned Meaning: no behaviour to execute Fix: assign a PickupEffect
Actor has no IDamageable and effect does not allow null Meaning: effect requires a valid damageable target Fix:
Add an IDamageable component
OR use an effect that allows null targets
Apply reports "refused" Meaning: TryApply returned false — the effect is still on cooldown for this owner, a decorator cancelled, or the effect declined. Nothing was applied. Fix: wait for the cooldown window (1s on TeleportEffect) and apply again
Context effect fails Meaning: the effect implements IPickupEffectWithContext and no reporting seam, so the runner calls it directly, skips the base gates, and assumes delivery — Apply reports success whatever the effect did Fix: inspect the effect implementation
Runtime exception Meaning: failure inside effect logic Fix: check effect expectations vs actor data

This scene uses:

PickupEffectRunner.TryApply(...)
PickupEffect
IPickupEffectWithContext
TriggerPickup (the teleport cube, effect TeleportEffect, destroyOnUse, requiredTag "Player")
TriggerRelay3D (on both the cube and the sword)
InteractablePickupBase
SimpleItemPickupInteractable (the sword, PressToPickup, interact key F)
DebugKeysInputService (on the Player — this is what supplies the key state)
IDamageable

Pickups provide execution and flow, not storage or ownership.

You control where the result goes. The pickup system guarantees how it runs.