Movement of game elements

One of the first challenges when making a game is moving our characters and objects around the screen.

This movement could be implemented in different ways. Still, here it’s a common approach for 2D that could be simplified for movement in a single axis (like moving the bar in Pong or Arkanoid) or extended to 3D.

We could start with something that looks like the following code, which would be called at some point in our game Update cycle. The example code is in C++, using some third-party code like SFML or some custom or made-up classes to exemplify. However, it could be easily translated to other object-oriented languages like, for example, C#

First, we get the movement direction from some input (in this case a Keyboard) and then we increment the object's position in the direction got.

As a good practice, and to simplify the example code, let’s assume the code to handle input to get the movement direction is moved to another class, in this case, InputManager.

Configurable movement speed

In this way, our objects will be moving at one pixel or unit in each frame while there is any input for movement.

In order to balance the speed and allow different objects to use different values, we can then introduce a variable for the movement speed and multiply it by the movement direction before adding it to our object’s position.

Movement speed independent from device speed

It would work as it is now but we face the first issue, the movement speed is dependent on the device speed, like a computer or a mobile phone; our object will move faster on fast devices and vice versa. We want to have a consistent speed no matter which platform or device it is running on.

Luckily, this is easy to overcome by taking into account the elapsed time between frames. In Unity, for example, we could use Time.deltaTime. By multiplying this value by our velocity, we would modify the position only by the corresponding movement fraction.

Normalizing the direction vector

The current code supports moving only in one direction of four possible (up, down, left, or right). It might be enough for some games but for others we might want to move diagonally by pressing two keys, or in any direction, like when using an analog stick.

Let’s modify it for the keyboard to evidence the next challenge.

Before, when the player was pressing one direction it was moving at the speed set, let's say 5 pixels per second (pps), in that direction. Now if the player moves diagonally, e.g. by pressing UP and RIGHT, it will move 5 pps vertically and 5 pps horizontally, which results in a magnitude of ≈ 7 pps.

This can be fixed by normalizing the direction vector before using it, in that way the magnitude will be always 1 (if there is movement) and it would not affect the speed multiplication.

This was a simple example of the challenges a gameplay programmer would face and I hope to continue writing more in the future.