Build a Unity interactable-object system driven by events
Produces a decoupled interactable system — a reusable interface, a player interaction component, and UnityEvents or a scriptable-object event channel — so doors, levers, and pickups all plug in without hard references.
You are a senior Unity C# gameplay programmer who builds decoupled, reusable interaction systems. Interaction needs: [DESCRIBE THE INTERACTABLES — e.g. 'doors that open, levers that toggle state, pickups that go to inventory, NPCs that start dialogue']. Detection method: [RAYCAST FROM CAMERA / OVERLAP SPHERE AT PLAYER / TRIGGER COLLIDER PLUS PROMPT]. Constraints: - Unity version: [2022 LTS / Unity 6]. - Define an IInteractable interface (Interact, and optionally CanInteract and GetPrompt) so any object can opt in without inheritance. - A single Interactor component (on the player or camera) performs detection, holds the current target, and fires interaction on input. It must not know concrete types. - Use events to decouple: a UnityEvent on each interactable for designer hookups, AND/OR a scriptable-object event channel so listeners in other scenes react without scene references. Pick one default and justify it. - Handle the real edge cases: no target in range, target leaves range mid-prompt, rapid double-input, and disabled or locked interactables that should show a different prompt. - Optional context-prompt UI that reflects the current target's GetPrompt and hides when nothing is targeted. - Expose tunables (interaction range, layer mask, cooldown, hold duration if applicable) as [SerializeField] private fields with defaults. Output: 1. A 3-bullet design rationale covering why the interface plus events keep things decoupled. 2. Each class or interface as its own fenced code block, file name as a comment on line 1. 3. A wiring note: how to make a new object interactable in two steps (implement the interface, assign the event) without touching the Interactor. 4. A short checklist of the edge cases to test in play mode. State every detection and input assumption up front. Success signal: the output is good only if adding a new interactable type needs zero changes to the Interactor, the Interactor knows no concrete classes, and the edge cases (no target, leaves range, locked) are handled explicitly.
Use case
Use when your game has many interactable objects (doors, items, switches, NPCs) and you want one clean system instead of a tag check and GetComponent spaghetti per object.
When to use this
When you need many object types to respond to a single interact input. State the detection method (raycast vs trigger collider vs UI prompt).
Follow-up prompts
- Add a world-space interaction prompt that appears only for the current target.
- Convert the UnityEvent to a scriptable-object event channel so scenes stay decoupled.
- Add a hold-to-interact variant with a progress bar for locks and charges.
- Source
- promptfork seed
- License
- CC-BY-4.0
- Published
- 6/22/2026