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.

---

What This Scene Demonstrates

This scene demonstrates two valid pickup execution paths:

• Effect path Actor → PickupEffectRunner → effect executes behaviour

• Custom pickup behaviour Interactable → custom logic → developer-defined result

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.

---

What To Look For

There are two observable flows in this scene:

1. Effect-based pickup (Teleport)

• Trigger fires on overlap
• PickupEffectRunner is called
• Effect executes immediately
• Result is visible in the world (player is moved)

2. Custom pickup behaviour (Sword)

• Interactable handles input (hold-to-pickup)
• Custom logic runs instead of Inventory integration
• Item id is added to a simple runtime container
• UI updates to reflect the change

3. Quickstart Panel

• Actor and Effect are bound explicitly

• Preflight shows:

• IDamageable availability

• Null-target support
• Dispatch type (Standard vs Context)
• Apply calls the real runner path
• Result message is the source of truth

---

Sample Scope

This scene covers:

• Effect execution through PickupEffectRunner
• Trigger-based pickups
• Interactable pickups with custom behaviour
• Minimal runtime item storage (SimpleItemBag)

This scene does NOT cover:

• Inventory system integration
• Authority or multiplayer validation
• Save/load or persistence
• Production pickup spawning or pooling

---

Authority Note

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

---

Networking Reminder

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

---

How To Use

1. Enter Play Mode

2. Test Trigger Pickup (Teleport)

3. Walk into the cube

4. Observe immediate effect execution (teleport)

5. Test Interactable Pickup (Sword)

6. Move near the sword

7. Hold the pickup key
8. Observe item added to the runtime container

9. UI updates immediately

10. Test Quickstart Panel

11. Assign:

12. Actor → Player

13. Effect → PickupEffect

14. Review Preflight:

15. IDamageable

16. Allows Null
17. Dispatch type
18. Click Apply To Actor
19. Observe result message

---

Failure Behaviour

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

• Context effect fails Meaning: effect implements its own execution rules Fix: inspect the effect implementation

• Runtime exception Meaning: failure inside effect logic Fix: check effect expectations vs actor data

---

Behind The Scenes

This scene uses:

• PickupEffectRunner.Apply(...)
• PickupEffect
• IPickupEffectWithContext
• TriggerPickup
• InteractablePickupBase
• SimpleItemPickupInteractable
• IDamageable

---

Key Takeaway

Pickups provide execution and flow, not storage or ownership.

• Effects run through a consistent runner path
• Custom behaviour can replace built-in integrations
• The system does not enforce backend choices

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