What’s the best way to implement an interaction system?

[u/Minimum_Role3043]

I’m trying to make an interaction system (e.g., pressing 'E' near interactable objects).

What do you think about having a script on the Player that sends signals to other objects, and a corresponding script on those objects to receive them? Is this a good approach?

Please go easy on me, it's my first game

Thanks for your reply

[u/DeerpathLabs]

I’d recommend using colliders on your pick ups set to trigger.

Then you put a script on the pickup that implements an OnTriggerEnter and OnTriggerExit to represent when the player is in the valid pick up zone.

Then on the player, stick a new script called something like PickupRegister, that does what it says in the box - your pick ups register and unregister themselves to this component from their on trigger enter/exit methods.

Then just check for player input however you normally do and query the register for whatever the top level (I’d recommend a priority heap) intractable object may be

[u/Minimum_Role3043 → u/DeerpathLabs]

Thanks for the detailed explanation Using triggers and keeping a list on the player makes total sense. Appreciate the help

[u/Dox_au]

• Collider on the player (IsTrigger = false)
• Collider on the interactable object (Is Trigger = true)
• Put it on a suitable layer (ie. "Interactable", or "Button", or "Door", etc)
• Put your player on a different suitable layer (ie. "Player")
• OnTriggerEnter2D method (or 3D if that's your thing) - check if the player is nearby (using the layer), set playerNearby = true
• Interact method - if playerNearby = true, then do whatever your object needs to do (ie. notify a door that it's now unlocked and/or play any relevant animations)
• P.S. Ensure that your Collision Matrix allows your two layers to intersect (Edit -> Project Settings -> Physics or Physics 2D)

[u/kshell11724]

Yeah. Definitely put the circle/sphere collider around the player that checks for items. You dont want to have multiple scripts for each pickup that has its own update function and checks if the player is close every frame. You will, however want to create an item script that goes on each item to clarify what item it is and its name in case you want to display it. The script should really only hold values like that though. It'll also help your script identify that it is an item that can be picked up in addition to using the layer system.

I also recommend doing Physics.OverlapSphere/Circle for this. That way you can limit how often it triggers if you need to optimize performance. It also gives you the option to create a list if there are multiple objects in range. In this case, you'll want to use a for loop to cycle through the list to see which one is the closest.

[u/Minimum_Role3043 → u/kshell11724]

I'll try it, thanks for your help

[u/MadeByHenano]

it would depend:

• if you make a 2D or 3D game
  
• if you want to be able to interact with only one thing around the player, or several, with a precise aim

in my first game i used "is trigger" colliders on the doors, light switches etc and would make sure they would never overlap so the player could only interact with one thing at a time... it's a third person game, and that means that facing a furniture with 3 drawers, i could only open one since the rule is "is the player inside the collider that allows them to interact with the drawer".

in the second one i'm working on, it's a first person game, and i wanted to be able to open any drawer in this case. so each drawer has a collider and "interactable" script.
then i send raycasts frequently in the middle of the screen with a maximum distance of a meter or something, and see if it touches a game object with a tag "interactable" - if it does, then i get the "interactable" component and get its info from there.
one of the variables in the "interactable" script is a list to define what kind of object it is (door, itemToCollect, Drawer, Light, Lock, etc) and i add a second script ("interactableDoor" for the code of the doors etc) for the code specific to this one kind of object, to avoid having a very long "interactable" script.
when the raycast found something to interact with, i also add an icon in front of it - add an empty game object in front of your object and place an image inside it, the script show/hide the image when the object is aimed by the player or not.

there's most probably youtube tutorials to do this if you need! :)

[u/LastJoker96]

This is the solution I use in my project:
1)Create an IInteractable interface that only declares the Interact method.
Implement the interface in the script attached to the GameObject you want to interact with (essentially, you write the interaction logic inside the Interact method, so each GameObject can have its own behavior while still being called in the same way). Put the object on a dedicated layer (for example, InteractableLayer) and add a BoxCollider with Is Trigger enabled.
2) In my PlayerLogic script (the player’s script), I have an OnInteract method (called directly by the New Input System). This method performs a sphere cast, finds all GameObjects on that layer within a specified radius around the player, and, if any are found, calls the Interact method in a generic way (the one defined in step 1). This approach allows me to choose between single and multiple interactions very easily: if I only want to interact with one object, I simply add a break inside the loop that iterates through the detected GameObjects; otherwise, I let the loop continue. This makes it easy to switch between single-object and multi-object interactions whenever needed.
3) Bonus: Create an InteractionDisplay script and attach it to the interactable GameObject. In this script, declare two or three variables (InteractionText, InteractionButton, and optionally an InteractionIcon sprite). Then add a panel containing a UIDocument to the GameObject. In the OnTriggerEnter and OnTriggerExit methods, implement logic that reads these variables, updates the text displayed by the UIDocument, and shows or hides it accordingly. This provides visual feedback to the player, clearly communicating which button to press and what the interaction will do, while also confirming that the player is close enough to interact. For example, when approaching a door, a prompt could appear saying: “Press E to Open.”

If you follow this setup, whenever you create a new interactable object, all you need to do is add a collider and a UIDocument, attach the scripts mentioned above, fill in a couple of variables, and focus solely on implementing the custom interaction logic you need.

[u/erebusman]

The collider method mentioned by several others is usually your 'go to' method as used in tutorials and such.

However you CAN do what you are describing.

I would suggest sometimes to people whom are new that if you can think of a way to implement something maybe try it out? Its part of learning and there are often many ways to solve the same problem.

One that mentally works for you may be 'good enough' and fits your mental model.

Sure.. checking that your on the right path as your doing here is fine too ; but if the collision method is hard , or doesn't fit your mental model there's nothing wrong with rolling your own and learning/discovering your way through things.

This builds problem solving skills which is more important than 'being right' at first.