A 3D grid based movement system, where the characters re-orient themselves to a new axis everytime they reach the edge of the world's boundaries.
Everytime the player wants to move a column of blocks, they send their character into a dive, where a column of blocks gets slammed on block further down.
For the beacon, and slam particle effects, I aided the artists on a technical level, helping them implement the effects into the game.
After the character's were rigged and animated successfully, I setup a very basic animation controller for the characters. Additionally, I also used some animations to trigger the particle effects.
My main role for this project was the character movement. The characters can move all around the boundary cube, and re-orientate themselves so that they are always flying straight above one of the sides. To check when the character has to re-orientate itself, the movement direction is used to calculate on which axis the character would like to move on. Once we know on which axis the character wants to move, the target position is compared to the two limits for that axis, for example on the x-axis the boundary has an x-min and an x-max. If the target position does not fall between those limits, then the character has to rotate. Otherwise it will just move normally to the target position.
After every move the characters have to be properly aligned to a column of blocks. Therefore the character's movement is based on a 3D grid, where each cell has the same dimensions as a cube. Only once the character has completely moved to the correct position, can it be moved again. This small delay also prevents players from accidentally moving too many times in the current direction, which could waste moves. Also since the character is flying/hovering above the world, no physics or character controllers were used, and the characters don't even make use of colliders.
The game was also made turn-based, as each player has a maximum of 5 moves per turn before their character will automatically dive down. Limiting players to 5 moves per turn added an extra challenge to the players who now have to strategically plan their moves. By making the game turn-based, the camera only has to focus on the active character. If both characters would be active at the same time there could be scenarios where the characters are at opposing sides of the world, which means only one character would be visible to the camera. A solution to this issue could be to make the game splitscreen, but this approach would not fit with our minimalistic style.
To move a column of blocks one down, the character dives down and slams into the chosen column, and I was also responsible for this action. Before the character can even go into a dive, it first checks whether there is an actual column of block below it. If there is a column it will dive down, otherwise it will do nothing and just continue flying. This behaviour is the same for the automatic dives at the end of a turn. Once the character goes into a dive, it end that player's turn.
When a dive has been triggered the character retrieves the co-ordinates of the highest block in the column, to know where to dive to. Then the character begins to dive. Once the character's dive has been initiated the player loses all control over it, and only once the dive has end will the other player be able to continue. When the character reaches the position it had to dive until, it calls a function in the cube manager to move the whole column of cubes one cube down. This landing also triggers the cloud ring particles, and a slam sound, to emphasize the action itself.
Alongside programming, I also aided the artist with the more technical aspects of creating some of the particle systems we used during the project. The particle system used to indicate which column the active character is hovering above, and the cloud particles when the player slams down, are systems I helped create.
Besides the indicator particle system itself, I also implemented it's functionality as well. The indicator always stays below the active character, even when it is moving. After playing a while the surfaces of the sides will no longer be planar, therefore the indicator has to constantly change it's height (relative to the player) after each move the player makes. Using the same function the character uses when it needs to know where to dive to, the indicator uses that position to know where it has to be placed.
In addition the indicator's particle travel distance is based on the distance between itself and the character, making the particles system visible even when in a deep hole. So the further the character is from the indicator, the further the particles will travel. The indicator's color is also based on which charater it belongs to and will only be active once that character is active, for example the red indicator belongs to the red character and will only activate once it is the turn of the red player.
I also made a simple animation controller for the characters during the game jam. The controller makes use of four different animations: Idle, Dive, Landing, and Up. The character most uses the idle animation, but when it goes into a dive, it cycles through the other animations as well. Land is only played once, and starts once the character has reached the top of the column to slam. Near the end of the land animation a function is triggered. This function activates the ring cloud particle system, plays the slam sound, and allows the character to return to it's idle position. At the end of the land animation, the Up animation is played, until the character has reached it's idle position again.