According to Unity, the Update function is called every frame. And if we render a set amount per second, then in theory, that should be the amount of times Update is called per second.
Why is this important? Because, as computers get faster and more powerful, Unity is able to render more FPS, and as FPS gets larger, the Update function is called more often.
If Update function is called more frequently, wouldn’t this be a good thing? Not necessarily, especially if the code is being reset every time the Update function is called. As a result, a player who has a recently built computer will not have the same experience as someone who might have a computer that’s a couple of years old.
A Controlled Logic
In this example, we are trying to move the player left and right while allowing them to jump. We are changing the y value whenever the player presses the Spacebar because the character is jumping.
However, if we don’t cap the FPS, this is what we get:
Even though we are pressing the Spacebar, it doesn’t look like the character is jumping. This could be because we are setting the character’s position back to 0 at the start of the Update function.
Limiting the FPS
If we want players to have similar experience with our game, we might have to limit the FPS. Just by adding this line of code in the Start method, we can limit the FPS to any number we want:
Application.targetFrameRate = 30;
By limiting the FPS to 30 instead, this is the result we get:
And if we were to increase the FPS limit, we get to see a jump that is closer to the ground: