In this lesson, you will learn why your objects might speed up or slow down depending on the computer running your game and how Update is tied to your hardware's performance.
The Heartbeat of Your Game
In Unity, the Update method is the "heartbeat" of your script; it executes once every time a new frame is rendered on the screen. If your game is running at 60 frames per second (FPS), your code inside Update runs 60 times in one second. If it runs at 30 FPS, it runs 30 times.
The problem arises when we move objects based strictly on this frame count. Consider this simple script:
void Update()
{
// Moving the object 1 unit every frame
transform.position += new Vector3(1, 0, 0);
}
Hardware and the Speed Gap
Imagine two players: Player A has a high-end PC running the game at 120 FPS, and Player B has an older laptop running at 30 FPS.
- Player A’s computer executes the
Updatemethod 120 times in one second. Their object moves 120 units total. - Player B’s computer executes the
Updatemethod only 30 times in one second. Their object moves only 30 units total.
Even though both players are playing the same game, the object on Player A’s screen will move four times faster than on Player B’s screen. This is called "frame rate dependency." Because hardware performance varies wildly between different devices, your game's logic cannot rely on the speed of the hardware to dictate the speed of your gameplay. If you don't account for this variability, your game will feel broken, unfair, or inconsistent for anyone who doesn't have the exact same hardware performance as you.
To build reliable games, you must ensure that movement and logic are measured by real-world time rather than frame count. We will explore how to normalize this behavior in our next steps by using the time elapsed between frames.
Key Takeaway: Because Update runs once per frame, code that ignores hardware performance will cause your game to run at different speeds on different computers.