When we want to move a game object, the simplest way to do it is to update the position at a constant rate. This can work fine for some games. However, for simulating cars, spaceships, or even gravity, it won't look correct. For now, we will use this method as an example then look at physics-based movement a little later. Since we are just updating the object's position, the code to move the player to the right will look like this:

//Move the player to the right 
//This is just an example 
//A game should not be hard-coded like this 
pos.x += 5;

It is worth noting that the value 5 is not measured in inches or meters; it is in game units. Game units are completely arbitrary and are dependent on the size of objects in the game. 3D modeling programs will allow you to set up units of scale for your models. If the same units are used for every model, and the models are not scaled in the game world, it would be possible to think about the game world in terms of those units. However, it is more common to consider everything as arbitrary game units. The amount an object moves on the screen depends on the size of the object and how far it is from the camera. If everything looks and feels correct in relation to everything else, it is OK.

In the preceding example, assuming the size and camera distance are fixed, the distance on screen that the player moves will be completely dependent on our frame rate. For example, if we are getting 1,000 frames per second, as we might early in the development, our player will move 5,000 game units in the x direction. Later in development, when we are getting 100 frames per second, our player will only be moving 500 units in the x direction. To get the same amount of movement, we would need to change the speed of the player:

//Move the player to the right 
//This is just an example 
//A game should not be hard-coded like this 
pos.x += 50;

As we get closer to finishing the game, we might only be getting 60 frames per second. This would mean the speed of the player would need to be changed again. To get the same amount of movement, the player speed would need to be 83.333 fps. Unfortunately, even after the game is released, we still have the same problem. As graphics cards and CPUs become faster, our game's frame rate will increase, meaning the player will be moving too fast. The gameplay experience is completely dependent on the computer hardware.

This problem could be solved by enabling VSync. As we saw earlier, using VSync will effectively lock our frame rate to the refresh rate of the monitor. This would guarantee that our frame rate has a maximum value. However, the player will be very confused when they upgrade to a 120 Hz monitor and the player moves twice as fast. Additionally, if the game runs slow for a few frames, VSync causes our frame rate to drop down to 30 fps. Suddenly, the player is moving at half speed. Even when using VSync, our gameplay experience is completely dependent on the hardware.

Obviously using frame-based movement is not the way to go. As our frame rate rises and falls, we must change the movement speed of the player. As we said, this same problem occurs in all animation. Rotational speed of spinning objects, scale, fade speed of particles, and the number of frames to display a texture before changing it all must be constantly modified during development, and still won't be consistent across different hardware.