It is easy to keep track of what tile of a tilemap tiny game objects are in. What is not as straight forward is how to sort larger objects objects into a tilemap such that each tile that contains part of them has a reference to the object – especially when the objects are moving and the tilemap has to be kept up to date.
Recently we have seen how we can create our own types to encapsulate physical concepts such as position, velocity, timespan and more. We developed all the types needed for movement in one and two dimensions, however so far we have not talked about rotation.
Today we will look at how to implement the types necessary to also gain the advantages of type-safety when it comes to the rotation and orientation of an object.
We will consider only the two dimensional case, since it is relatively straight forward. However, a similar approach could be taken in three dimensions as well, though it would significantly complicate the mathematics.
In this recent post we saw how we can represent the physical units of length, speed, acceleration, and time using our own types to only allow for type-safe operations between them, and find errors and bugs at compile time.
Today we will expand these ideas to more than one dimension, with the example of two dimensional types.
As discussed in this post there are some potential advantages in representing physical quantities like position, velocity, and similar in a type-safe way.
Instead of using simple floating point types, we can write our own wrapper types that have semantic meanings like ‘length’, ‘speed’, or ‘time’ and only allow physically correct operations between them.
That is exactly what we will look into here. We will implement the basic types for such a system, and show what operations between them are relevant and well defined.
When developing games, working with positions and velocities, time stamps and time spans and similar physical quantities becomes second nature to us.
I would like to explore how we can represent the physical nature of these values, and their relation to each other in code.
An important aspect of almost any game is that things move right. The movement of objects needs to feel natural or intuitive, so that the players can interact with them effortlessly. We can use the manipulation of velocities and accelerations in order to achieve this.
While we my not often think about it, movement of objects is one of the key aspects of most video games. In any game that has any sort of characters, enemies or items interacting in a fictional – or real – world, these agents and objects have to move in order for anything to happen.
In most cases, we want these movements to appear natural, or at least believable and consistent. This allows the player to better put themselves in the feet of the protagonist, or avatar, as they can control their movements in an intuitive way – not having to think about each key press individually, but merely willing to move in a certain direction and letting muscle memory take over from there.
Following another object is one of the most basic movement behaviours an item can exhibit – both in the real world, and in games.
There are many different ways in which objects can follow each other, and depending on the circumstances, different kinds of movement may be appropriate.
Today we will look at one particular kind: A number of objects following another in a trail at regular distances. The movement found in games like Snake.
However – unlike the original Snake and many of its spin-offs – we will neither constrain ourselves to a grid, or to fixed time steps.
Instead we want our solution to follow arbitrary paths with arbitrary accuracy.