First of all, thank you, there is definitely something to get from this.
I guess I know there isn't one best solution for every case.
So I want to understand why the input detection in the script mentioned in the tutorial is considered "not best practice" (bad practice?).
There must be something about this that is bad, when it is mentioned like that.
I would like to know what exactly. Is it a coupling thing or a readability thing or the one thing should handle just one thing, thing?
You mentioned some things like saving input for later use or to look at the last few events in cases where it's relevant to know.
A singleton as a input manager.
Interesting stuff, I might want to look into.
I am working on a 2d sidescroller and my main character got pretty convoluted. So I tried it with an enum + match state-machine but then I found this tutorial on how to implement the state pattern with scripts, and I really like having a class for each state.
In basically every basic tutorial, they just put the input detection in the player script, you also mentioned that this is ok for some scenarios.
Now they tell me that it is not best practice
So assuming the only thing that's bad, is to have that code in that script...
I made a class StateInput which is instanciated in the player class (persistent_state from the tutorial) where a setup function is called to give itself to the StateInput.
And then I call methods on that member like:
input_reciver = player class in this case
Func update ():
Now if I plug in another receiver like a different character then it should just work at least if all the methods are implemented in this case move_left().
Or maybe it would be better to not call functions on the receiver and instead save the input in a direction field like:
If move left
direction = -1
And in the receiver get it from the object
var direction = state_input.direction
Velocity *= direction
Or something like that