The Last Crown Warriors DEMO has been published recently. Since
the last entry on Imanolea's Games about the game has been some
time, and much functionality is pending for explanation. So I decided to ask on Twitter for the feature or system of Last Crown Warriors that you would like to be clarified on the blog.
Now that the demo of #LastCrownWarriors has been published, I will write about how some of its features have been programmed on Imanolea's Games. Is there one that interests you in particular?#gameboy #gamedev #indiedev— Imanol Barriuso (@Imanolea) 6 de diciembre de 2017
From this announce I received an email from Jonas proposing to write about the collisions.
Now, it is also true that this routine sometimes involves a lot of processing in each of the frames. And
just as in the times of the classic microcomputers a good scroll routine could
make your game stand out from the others, a good collision processing
can allow you (also nowadays) to maximize the number of enemies,
projectiles, power ups, and other interactive objects that we see on the screen.
And
naturally, managing a pixel-level collision in a modern video game
engine is not the same as trying to set up the collision of multiple
elements in a system like the Game Boy. So in the end I found that it could be interesting to show the way in which I try to face this challenge. My system is far from being the best, but I think it can inspire others to try to work on their own approach.
In Last Crown Warriors it is necessary to manage collisions in the following list of situations:
- Collision of the hero with background
- Collision of the enemies with the background
- Collision of the hero's weapon with the enemies
- Collision of the hero's special weapon with the enemies
- Collision of the hero with the enemies
- Collision of the hero with interactive elements (such as the health heart)
All these collisions occur simultaneously, and it is crucial to minimize slowdowns as much as possible. So the routines must be extremely efficient.
The collisions
previously enumerated are essentially managed through two systems, which
I will explain throughout this entry.
- Collision of a character with another character
- Collision of a character with the background
And although they both manage collisions they have a completely different approach, as you will see below.
Collision of a character with another character
Let's take as an example the collision of the hero with the enemies for this routine. Let's see, to be able to verify if the hero has collided with an specific enemy we would have the following data:
- X and Y coordinate of the hero
- X and Y coordinate of the enemy
- Width and height of the collision area of the hero
- Width and height of the collision area of the enemy
With this information we could shape two areas (the hero's and the enemy's), and check if those two areas overlap. And while it would be a valid solution, it is not by far an acceptable solution. Because although the area of the hero would only be calculated at the beginning
of the routine, the enemy area should be recalculated by each of the
enemy characters.
And what can we do? Let's
see, we know that all enemies share the same size collision area, so
why not generate a single area around the hero that combines the area
lengths of both characters? That is, instead of
checking if two areas overlap, check if the enemy coordinate is within
the combined collision area of the hero.
Purple: Point of character position.
Orange: Character collision area.
Blue: Combined collision area of the hero.
Orange: Character collision area.
Blue: Combined collision area of the hero.
So we would only have to calculate the blue area of the image by adding the dimensions of the collision area of the hero and the enemy's. And once we have it, and with a maximum of four simple comparisons, we check if the enemy's position point is within that area. In this way we minimize the processing to be performed by each of the additional enemies with which we want to check if our hero has collided.
This code shows the core of the check between the enemy character's position point and the combined collision area.
We can see how this routine returns the address in memory of the enemy that we have just checked. So we could place it without problems inside a loop that goes through the list of enemies on which we want to perform the collision check.
The data to keep in mind for this routine is:
Then we need to know the candidate position point to collide. For this we take into account the movement of the character, and we obtain the position of the edge of the collision area closest to colliding. If the character is not moving, we would automatically conclude that he has not collided.
Once we have the candidate position, it is important to check its relative position within the tile. I mean, if the character is aligned with the tile grid (and taking into account its collision area) we will only check the collision of a single tile, while in the rest of the cases it will be necessary to go through more than one tile.
Once we have clear the absolute positions of the tiles we must place them within the map, this is where the width and height of our map come into play.
And after having obtained the value relative to the collisionable tiles, how do we know if these are solid or not? Very simple, for each map we organize the tileset so that the solid tiles are at the end of the list and the non-solid ones at the beginning. Then we have only to specify what will be the position of the list from which the tile will be considered solid.
And this would be the explanation of how Last Crown Warriors collisions work. I hope that it has been interesting and has helped you to understand how a collision system can be set up in a limited hardware.
If you want to know how a particular aspect of the game works, tell me about it and I will try to talk about it in future posts.
Collision of a character with the background
In this case we will always go through the same routine when checking this type of collision. Since only the hero and the enemies can collide with the background, and both share the same dimensions in the collision area.The data to keep in mind for this routine is:
- X and Y coordinate of the character
- Horizontal and vertical movement of the character
- X and Y position of the background
- Width and height of the map
Then we need to know the candidate position point to collide. For this we take into account the movement of the character, and we obtain the position of the edge of the collision area closest to colliding. If the character is not moving, we would automatically conclude that he has not collided.
Once we have the candidate position, it is important to check its relative position within the tile. I mean, if the character is aligned with the tile grid (and taking into account its collision area) we will only check the collision of a single tile, while in the rest of the cases it will be necessary to go through more than one tile.
Purple: Collision candidate position point
Orange: Character collision area
Blue: Collisionable Tiles
Red: Solid tiles
Orange: Character collision area
Blue: Collisionable Tiles
Red: Solid tiles
Once we have clear the absolute positions of the tiles we must place them within the map, this is where the width and height of our map come into play.
And after having obtained the value relative to the collisionable tiles, how do we know if these are solid or not? Very simple, for each map we organize the tileset so that the solid tiles are at the end of the list and the non-solid ones at the beginning. Then we have only to specify what will be the position of the list from which the tile will be considered solid.
And this would be the explanation of how Last Crown Warriors collisions work. I hope that it has been interesting and has helped you to understand how a collision system can be set up in a limited hardware.
If you want to know how a particular aspect of the game works, tell me about it and I will try to talk about it in future posts.
