Is This code considered good practice?

[vivid cloak]

I've been trying to see how to use the new input system to its full potential, and have been trying to unify all the input scripts into one script to make my life easier when the project scales up, so was looking into some design patterns to help with that. I've been following this guide so far: https://www.youtube.com/watch?v=ZHOWqF-b51k

Is this actually good practice and do Unity devs really resort to this? Or should I just go with the much simpler send messages mechanism?

[manic mortar]

This looks like a complete waste of time to me

People definitely do this sort of thing all the time and I always see it and say "WHY???"

This entire class is just duplicating stuff that's already in the generated input action asset class

Literally just expose the GameInput instance to callers from this script and delete the rest

Let callers interact with it directly instead of creating a less flexible middleman class that you need to constantly keep in sync with the actions asset

So overall yes, people do this but no, it's not a good idea

[vivid cloak]

The only thing that makes me inclined to go this approach, even tho so far, I believe it really is a huge waste of time, is the scale I'm aiming for with the project and because I'm working with non coding experts which apparently think this is easier to read and trace.

I had previosuly done the code where my inputs were written where the action script would be execuded but idk.

Just wanted to make sure that my instinct is right that this stuff in lunacy, but similarly wanted to know what was considered good practice and this stuff came up alot

[patent magnet]

I think the main thing is splitting up roles/tasks, if you had an NPC character that could do similar things to the player, you wouldnt want them to reference input scripts, would you?

so having an intermediary layer can be good for seperating the players inputs from the actions they perform

but, if you just have the player or no linked behaviours, then i suppose theres not much point!

but even then if you had a lot of input related logic to be executed, for example, if a player switches inputs, or modifying inputs. It could be a good idea just to not gum up your game logic scripts with a lot of irrelevant input boiler-plate.

[manic mortar]

Non coding experts will never see this

[rich shore]

the whole architecture in the video is completely backwards for the stated goal he wants to achive. Havin a system depend on a InputReader type produces coupling instead or reducing it and thats the antithesis of scalable. If you want to separate a system from its input (for unit-testing ai/player separation or whatever), make a input struct scoped to that system and drive it from a throwaway input adapter component for that system specifically and orchestrate input routing abstractly via enable/disable on action maps and wiring everything via input action references.