It’s normally suggested that u should use Update/FixedUpdate for getting input from player (joystick) or physic’s. However that means that if u run at 50 fps the program will adjust the player’s input 50 times in just one second, isn’t that a little bit too much also considering having two joystick left and right in a simple mobile game? Is it not better to use a coroutine with wait for seconds and then something like 0.1s-0.05s? Because also if an object is moving I can’t tell below 0.1s if that object is updated 50fps or “10fps” in general.
Do you have any specific concerns about frequently updating the player movement?
I could imagine if your player movement is computationally expensive (more than the typical examples), it would be worth to consider moving the computation into a Coroutine. Then you also have to allow the engine to interrupt your movement computation using the yield return statement (see Coroutines), as otherwise, the frame where the Coroutine will continue after the WaitForSeconds will block until the computation completes.
If it is not clear if your computation is unusually expensive, it is better to avoid optimizing prematurely and keep the code simple and predictable (e.g. having every FixedUpdate the same performance penalty). Later, when the project gets more complex and you imagine some optimization would improve the gaming experience try to justify your optimization decisions with the help of the profiling tools.
well it has nothing to do with lag/too many comprobations of inputs, this is how all Inputs works in all engines. I will try to show an example: all inputs are events, it doesnt matter if the event is called onmousedown, onmouseup, onclick etc… these events are updated every frame, so for example, if your game is running at 60fps, but you want to check every 0.5 seconds your inputs, for example the Input.GetButtonDown, and fire a bullet whenever the onmousedown is true, the chances of the bullet failing and never firing are of 58 fails of 60 tries, because inputs get “cleared” every frame, so if the input is fired at frame 10, but you dont want to check all frames input, and you want to wait till frame 30 to compare the input, the program will consider the event has never been fired. obviously there are some cases in which you can use a coroutine for managing the inputs, for example it might be usefull to use the coroutine for the Input.GetButton, since this event is getting fired always while you are pressing the button. anyways, having some if else conditions and catching the inputs all frames will most likely never be the performance problem