Spread It Out (Global Game Jam 2018)

Videojuego realizado en 48 horas para la Game Jam On 2018 (Global Game Jam) por Imanol Barriuso, Pelayo Martinez y Fernando Olea.

Plataforma: Oculus Rift
Página del juego: https://globalgamejam.org/2018/games/spread-it-out

Last Crown Warriors #3: Collisions

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.

It is not the first time that I perceive interest in reading an entry dedicated to collisions. It is something present in almost any type of game, but a lot has been written about it. So I did not have the impression that I could offer something interesting on the subject.

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.

1. Collision of a character with another character
2. Collision of a character with the background

And although they both manage collisions they have a completely different approach, as you will see below.

As always, I will try to focus on explaining the logical concepts behind the systems. So that they can be understood and applied without having to go through lines of code.

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:

1. X and Y coordinate of the hero
2. X and Y coordinate of the enemy
3. Width and height of the collision area of the hero
4. 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.

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.

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:

1. X and Y coordinate of the character
2. Horizontal and vertical movement of the character
3. X and Y position of the background
4. Width and height of the map

The first thing would be to get the absolute coordinates of the character, that is, the coordinates of the character within the map. For this we add the position of the background to the coordinate of the character.

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

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.

Last Crown Warriors #3: Colisiones

La DEMO de Last Crown Warriors ha sido publicada recientemente. Desde la última entrada de Imanolea's Games dedicada al juego ha pasado algún tiempo, y mucha funcionalidad ha quedado pendiente de ser explicada. Así que decidí preguntar por Twitter por la característica o sistema de Last Crown Warriors que os gustaría que fuera destripado en el 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

En base a este anuncio recibí un mail del compañero Jonas proponiendo escribir sobre las colisiones.

No es la primera vez que percibo interés por ver una entrada dedicada a las colisiones. Es algo con lo que tenemos que lidiar en casi cualquier tipo de juego, pero también algo sobre lo que se ha escrito mucho. Así que no me pareció un tema sobre el cual yo pudiera ofrecer algo interesante.

Ahora bien, también es cierto que esta rutina engloba en ocasiones gran parte del procesamiento de cada uno de los frames. Y al igual que en la época de los microordenadores una buena rutina de scroll podía hacer destacar tu juego de entre los demás, un buen procesamiento de colisiones puede permitirte (también a día de hoy) maximizar el número de enemigos, proyectiles, power ups, y demás objetos interactuables que vemos en pantalla.

Y naturalmente, no es lo mismo gestionar una colisión a nivel de píxel en un motor de videojuegos moderno que intentar plantear la colisión de multiples elementos en un sistema como el de la Game Boy. Así que en última instancia me pareció interesante mostrar la manera en la que yo procuro enfrentar este reto. Que si bien se encuentra lejos de ser la mejor, creo que puede inspirar a otros a probar suerte con su propio enfoque.

Concretamente en Last Crown Warriors vemos necesario gestionar colisiones en la siguiente lista de situaciones:

• Colisión de héroe con fondo
• Colisión de los enemigos con el fondo
• Colisión del arma del héroe con los enemigos
• Colisión del arma especial del héroe con los enemigos
• Colisión del héroe con los enemigos
• Colisión del héroe con elementos interactuables (como el corazón de salud)

Todas estas colisiones se producen simultáneamente, y es crucial minimizar en la medida de lo posible las ralentizaciones. Por lo que las rutinas deben ser extremadamente eficientes.

Las colisiones previamente enumeradas se gestionan en esencia a través de dos sistemas, que son los que explicaré a lo largo de esta entrada.

1. Colisión de personaje con personaje
2. Colisión de personaje con fondo

Y aunque los dos gestionen colisiones tienen un  planteamiento completamente distinto, tal y como veréis a continuación.

Como siempre, procuraré centrarme en explicar los conceptos lógicos detrás de los sistemas. De manera que se puedan entender y aplicar sin necesidad de recorrer líneas de código.

Colisión de personaje con personaje

Vamos a tomar como ejemplo la colisión del héroe con los enemigos para esta rutina. Veamos, para poder comprobar si el héroe ha colisionado con un enemigo concreto dispondríamos de los siguientes datos:

1. Coordenada X e Y del héroe
2. Coordenada X e Y del enemigo
3. Ancho y alto del área de colisión del héroe
4. Ancho y alto del área de colisión del enemigo

Con esta información podríamos conformar dos áreas (la del héroe y la del enemigo), y comprobar si esas dos áreas se superponen. Y si bien sería una solución válida, no es ni de lejos una solución aceptable. Ya que aunque el área del héroe sólo la calcularíamos al principio de la rutina, el área enemiga debería recalcularse por cada uno de los personajes enemigos.

¿Y qué podemos hacer? A ver, sabemos que todos los enemigos comparten el mismo tamaño de área de colisión, así que, ¿por qué no generar una única área alrededor del héroe que combine las longitudes de área de ambos personajes? Es decir, en lugar de comprobar si dos áreas se superponen, comprobar si la coordenada enemiga se encuentra dentro del área de colisión combinada del héroe.

Morado: Punto de posición de personaje.

Naranja: Área de colisión de personaje.

Azul: Área de colisión combinada del héroe.

Así sólo tendríamos que calcular el área azul de la imagen sumando las dimensiones del área de colisión del héroe y de un enemigo. Y una vez la tengamos, y con un máximo de cuatro comparaciones simples, comprobamos si el punto de posición del enemigo se encuentra dentro de dicha área. De esta forma minimizamos el procesamiento a realizar por cada uno de los enemigos adicionales con los que queramos comprobar si ha colisionado nuestro héroe.

Este extracto de código muestra el núcleo de la comprobación entre el punto de posición del personaje enemigo y el área de colisión combinada.

Podemos ver como esta rutina nos devuelve la dirección en memoria del enemigo sobre el que acabamos de realizar la comprobación. Así que podríamos ubicarla sin problemas dentro de un bucle que recorra la lista de enemigos sobre los que queremos realizar la comprobación de colisión.

Colisión de personaje con fondo 

En este caso pasaremos siempre por la misma rutina a la hora de comprobar este tipo de colisión. Ya que únicamente el héroe y los enemigos pueden colisionar con el fondo, y ambos comparten las mismas dimensiones en el área de colisión.

Los datos a tener en cuenta para esta rutina son:

1. Coordenada X e Y del personaje
2. Desplazamiento horizontal y vertical del personaje
3. Posición X e Y del fondo
4. Ancho y alto del mapa

Lo primero sería conseguir las coordenadas absolutas del personaje, es decir, las coordenadas del personaje dentro del mapa. Para ello sumamos la posición del fondo a la coordenada del personaje.

Luego necesitamos saber el punto de posición candidato a colisionar. Para ello tenemos en cuenta el desplazamiento del personaje, y obtenemos la posición del extremo del área de colisión más próximo a colisionar. Si el personaje no se está desplazando, interpretaríamos automáticamente que no ha colisionado.

Una vez tenemos la posición candidata, es importante comprobar qué posición relativa ocupa dentro del tile. Me explico, si el personaje se encuentra alineado con la rejilla de tiles (y teniendo en cuenta su área de colisión) verificaremos únicamente la colisión de un tile, mientras que en el resto de casos será necesario pasar por más de uno.

Morado: Punto de posición candidato a colisión

Naranja: Aréa de colisión del personaje

Azul: Tiles colisionables

Rojo: Tiles sólidos

Pues una vez tenemos claras las posiciones absolutas de los tiles debemos ubicarlas dentro del mapa, aquí es donde entra en juego el ancho y el alto de nuestro mapeado.

Y tras haber obtenido el valor relativo a los tiles colisionables, ¿cómo sabemos si estos son sólidos o no? Muy sencillo, para cada mapa organizamos el tileset de manera que los tiles sólidos quedan al final de la lista y los no sólidos al principio. Luego no tenemos más que especificar cuál será la posición de la lista a partir del cuál se considerará que el tile es solido.


Hasta aquí la explicación de cómo funcionan las colisiones de Last Crown Warriors. Espero que os haya resultado interesante y os haya servido para entender cómo se puede plantear un sistema de colisiones en un hardware como el de la Game Boy.

Si queréis saber cómo funciona algún aspecto concreto de juego, comentádmelo e intentaré hablar sobre él en próximas entradas.

Last Crown Warriors #2: Selection screen

Yesterday Light Games published a new development of Last Crown Warriors, in which the character and scenario selection screen was shown.

Character and scenario selection screen of #LastCrownWarriors.#gameboy #musou #pixelart #gamedev #screenshotsaturday #indiedev pic.twitter.com/oZb11eSrM5

— Light Games (@lightgamesgb) 7 de octubre de 2017

In the video we can see how the movement of two backgrounds occurs simultaneously (the selection bar and the map at the top). And we can also see a non-linear movement, with accelerations and decelerations.

At logic level, achieving these features in a program should not be a big challenge. Although in the case of the Game Boy, given the limitations of the system, a little prior planning is necessary. So leaving aside the technicalities and focusing on the logical design I'll explain the key elements of this selection screen.

 

Sinusoidal movement

In order to achieve greater dynamism, it has been decided to apply a sinusoidal movement in the shifts of the bar, the top map, the arrows, and the selectable characters. Calculating the sine of a number would be an overly expensive task for a Game Boy, so a little part of the memory has been sacrificed and these shifts have been stored in data tables.

By going throught the values of a table like this, we can apply to the elements the proper movement in each iteration. This table represents the top map shift when leaving the screen.

 

Scene composition

The logic of this screen uses some of the properties of the Game Boy system, such as hardware scroll or sprites. In this image the components are differentiated by color.

In red: sprites; in blue: the main background; in purple: the secondary background or window.

As you can see, moving the top scenario is as simple as applying the Game Boy hardware scroll on the main background. Of course, you have to keep in mind that this map must be redrawn. In this case there is only one selectable scenario, but in the case of having more than one, it would be necessary to reprint the background with each selection change. In the following image we see the evolution of the main background during that change.

This is the Game Boy main background, the red box being the visible area of the screen during the scenario change. Through one limit of the visible area we first remove the current map and later we print the new one.

The window have a disadvantage. It is not possible to reduce its horizontal coordinate below zero, which would be the natural way to make it enter the left limit of the screen. So as you can see, we use an auxiliary sprite during the movement that joins the bar.

Graphical update

In addition to the shifts there are also times when we have to reload the graphics of the backgrounds. The most obvious (and costly) of these reloads is the update of the window once the selection shift ends and all the icons alter their order.

The solution is to have a strict control of the VBlank interruption, and to optimize the graphic reprint. This routine is the responsible for reloading the window, and already has the list of values to copy ready. The formula in this case is the same as the one used in the Last Crown Warriors scroll, which I explain in this entry.

Now it's time to develop the game system of Last Crown Warriors. Any functionality that deserves to be explained, will be the focus of the next blog entries.

Last Crown Warriors #2: Pantalla de selección

Ayer mismo publicaba Light Games un nuevo avance de Last Crown Warriors en el que se mostraba la pantalla de selección de personaje y escenario.

Character and scenario selection screen of #LastCrownWarriors.#gameboy #musou #pixelart #gamedev #screenshotsaturday #indiedev pic.twitter.com/oZb11eSrM5

— Light Games (@lightgamesgb) 7 de octubre de 2017

En el vídeo podemos ver cómo se produce el desplazamiento de dos fondos de manera simultánea (el de la barra de selección y el del mapa de la parte superior). Y también se puede apreciar un movimiento no lineal, con aceleraciones y deceleraciones.

A nivel lógico, conseguir plasmar estas características en un programa no debería suponer un gran reto. Aunque en el caso de la Game Boy, dadas las limitaciones del sistema, se hace necesaria una pequeña planificación previa. Así que dejando a un lado los tecnicismos y centrándome en el diseño lógico, paso a exlicaros las claves funcionales de esta pantalla de selección.

 

Movimiento sinusoidal

De cara a lograr un mayor dinamismo se ha optado por aplicar un movimiento sinusoidal en los desplazamientos de la barra, del escenario del fondo superior, de las flechas, y de los personajes seleccionables. Calcular el seno de un número sería una tarea excesivamente costosa para una Game Boy, por lo que se ha sacrificado un poco de memoria y se han almacenado estos desplazamientos en tablas de datos.

Así, recorriendo los valores de una tabla como esta, podemos aplicar al elemento el desplazamiento indicado en cada iteración. Esta tabla representa el desplazamiento del mapa superior al abandonar la pantalla.

 

Composición de la escena 

La lógica de esta pantalla se sirve de alguna de las propiedades del sistema de la Game Boy, como es el scroll por hardware o los sprites. En esta imagen están diferenciados por color los distintpos componentes en acción.

En rojo: sprites; en azul: el fondo principal; en morado: el fondo secundario o ventana.

Como veis, desplazar el escenario de la parte superior es tan sencillo como aplicar el scroll por hardware de Game Boy en el fondo principal. Eso sí, hay que tener en cuenta que dicho mapa debe ser redibujado. Ya que en este caso sólo hay un escenario seleccionable, pero en el caso de haber más sería necesario reimprimir el fondo con cada cambio de selección. En la siguiente imagen vemos la evolución del fondo principal durante dicho cambio.

Este es fondo principal de Game Boy, siendo el recuadro rojo la zona visible de la pantalla durante el cambio de escenario. Por un lateral de la zona visible eliminamos primero el mapa actual para más tarde imprimir el nuevo.

Y en cuanto a la ventana tenemos una desventaja. No es posible reducir su posición horizontal por debajo de cero, que sería la forma natural de introducirla por el límite izquierdo de la pantalla. Así que como se puede observar, nos servimos de un sprite auxiliar durante el desplazamiento que parece mimetizarse con la barra.

Actualización gráfica

Además de los desplazamientos también hay momentos en los que se deben recargar los gráficos de los fondos. La más evidente (y costosa) de estas recargas es la relativa a la actualización de la ventana una vez el cambio de selección termina, donde todos los iconos que la componen ven alterado su orden.

La solución pasa por tener un control estricto de la interrupción de VBlank, y en optimizar al máximo la reimpresión gráfica. Esta rutina es la encargada de recargar la ventana, la cual ya cuenta con la lista de valores a copiar. La fórmula en este caso respecto a la actualización gráfica es la misma que la usada en el scroll de Last Crown Warriors, la cual explico en esta entrada.

A partir de ahora toca empezar a desarrollar y profundizar en el sistema de juego de Last Crown Warriors. Cualquier funcionalidad que merezca ser explicada, será protagonista de las próximas entradas.

Sheep Kaboom (BitBitJam4)

Game Boy game made during a week by Light Games for #BitBitJam4

Hold A to charge the shoot. Release it to launch the sheep.
Aim to the target and avoid the spikes.

Design and programming: Imanolea
Graphics: Seiyouh
System: Game Boy

GAME PAGE

Last Crown Warriors #1: Building the scroll system

In the April 1 screenshotsaturday I posted a short video in which the Last Crown Warriors scrolling and collision system could be seen in action.

Testing the #LastCrownWarriors scroll and collision system at MAXIMUM SPEED #GameBoy #ScreenshotSaturday #gamedev pic.twitter.com/Cj9iYMg0cd

— Imanol Barriuso (@Imanolea) 3 de abril de 2017

In the video we can see Lilian moving at a speed of 7 pixels per frame along a stage of 512 by 512 pixels. In this post I will explain the logic behind the scroll system, which as you will see below, allows a scrolling of up to 8 pixels per frame.

The first thing to understand when it comes to setting up a scrolling system for Game Boy is that, in this console, any graphical update that is performed with the LCD switched on must occur during the VBlank interrupt (also during the HBlank interrupt, although is not considered for the scroll). And this interrupt marks the beginning of a period of time in which the system is not using the video ram, period in which therefore we have available that memory in order to modify it.

This interruption occurs 59.7 times per second (one for each frame of the game) in a Game Boy. This graph represents the duration of the interrupt (4,560 clock cycles) with respect to the total time of the frame (70,224 clock cycles).

Based on this graph we can conclude that the graphical update must be highly optimized.

And the second thing we need to understand is how the background scrolling works in this system. The scrolling of the background works at a hardware level, that is, changing the value of a register can alter the position of the background we have loaded into memory. But the size of this background is limited, 256 by 256 pixels, so for maps that exceed those dimensions it will need to be modified.

The base of the scroll system will then be the redrawing of the background. And taking into account that the graphic modification should be as optimum as possible, it only remains to decide which part of the background should be updated during the interruption. In Last Crown Warriors, we update the visible column and row of the part of the background to which we are going. For example, if you go up, left, or up and left, we will update the background bar highlighted in the next image. The blue box represents the visible background.

For the rest of directions we will update the corresponding bar following the same principle: update the row and column closest to being visible. This full modification of column and row allows us to scroll the background up to 8 pixels per iteration.

Once we are clear about what tiles need to be replaced, it remains to answer the question of how to do it. As we have seen, the time available to modify the video memory is very limited. So in Last Crown Warriors we prepare a data structure with the following information, in order to minimize the time it takes to replace the tiles of the background:

• byte 0: low byte of the address of the tile to be replaced;
• byte 1: high byte of the address of the tile to be replaced;
• byte 2: new tile value.

This structure is repeated for each of the tiles that we have to update, 41 in total. Thus, during the interruption of VBlank we must only execute the following code, pointing to the beginning of the previously prepared data structure.

We use REPT so that the indicated code is repeated for each of the tiles. Discarding a possible loop, which would consume additional processing.

Also it is important that in case we use other Game Boy interrupts we execute "ei" (enable interrupts) at the start of them. So we make sure that the VBlank interrupt is called at the right time and that no part of it will ever run outside the VBlank period.

And this would be a conceptual explanation of how the scrolling system works in this game. In future posts I will try to cover other aspects of the development. For these posts it will not be necessary to have an advanced knowledge of the system in order to understand the exposed ideas.