I assume it’s a pretty common thing for games in Unity (or games in general in its multi-decade history), whether it’s ScriptableObjects or game-world pickups:
What’s the thought process behind deciding where the code should go when you want the pickup to do something?
One extreme (which is obviously not the way to go) is to have a script on the player know ahead of time every kind of pickup and every functionality they implement. So the pickup object would just have an identifier of its type, and the player object has a collider, and reacts to items colliding with it and checks what it can do with it. “if it’s a health globe, restore health”, “if it’s a weapon, put it in my inventory”, “if it’s gold, add it to my gold variable”.
The sample in this video, which I assume went for the simplest to teach rather than something with a system in mind, seems to go the opposite route and the script on the pickup object waits for a collision and reacts to it and modifies the player script (albeit via APIs). It conjures a weird image of the sword waiting for a player to come near it and leaping into the character’s hand against their will. But it makes it so you can store the code that handles the item in the item’s script itself.
I’d like to learn about how this has been handled properly to make it both understandable and easy to work with. And is there a lesson here about being okay with kind-of-wonky imagery for the sake of simpler code? How much will that be beneficial or harmful to the code in terms of bugs or maintainability? Or is a lesson about saving things for refactoring later?