Handling player controls across multiple scripts or in a single controller

Hello Unity Community!

As the title suggests, I have I am curious about how to handle the overall architecture of player controls when multiple scripts are involved. More or less, I am looking for either best practice, general advice, or different methods to handle it, or maybe just a confirmation of if what I am doing is on the right track.

For example, I currently have a script called ‘PlayerController’ that registers input from WASD and mouse buttons to move the player in the scene. I have another script called “InteractableHidingPlace” where the player can press the space bar and interact with the GameObject attached to the object. I also have “InteractableMovementItem” where again if the player pressed the space bar, they interact with an item that allows them to hop on a mini catapult in the game and launch themselves using the mouse + space bar.

So as you can see, my player controls are divided between different scripts. The reason why I currently divide them is to avoid dependency issues and edge cases because of the different intractable I have. Also, it allows me to control what controls are currently active and which ones are not, depending on what the player is up to in the level.

My questions are as follows:
1.) Is dividing player controls between various scripts a good idea in the first place.
2.) Are there alternatives that might be a better idea?
3.) On a slightly unrelated question but still relevant, would it be best to create a “Key Master” script so I (or the player in game) can set the interact button to space bar or the ‘p’ key or whatever floats their boat. This way, I ensure among my divided scripts that controls are consistent.

I know this question is a little odd, but I would appreciate any feedback.

Thanks Unity Community!

So, to question 3, yes: you will probably want a custom class to abstract away the inputs, so you can provide for runtime configuration.

For the interactable items, I would make an interface (IInteractable) that components can implement if they want to provide some interaction. Your PlayerController script would use GetComponent to check for such a component on whatever object is selected (or under the mouse or however your game works). If found, then you’d call methods within that interface to tell it to do its thing — respond to the “action” button or whatever. Or, if necessary, just tell them “ProcessInputs” and let them check inputs themselves, using your input abstraction layer.