Eldridge Chan

During development, I found that the emoji movement requires some complicated physics calculations. At first, I defined realistic physics from scratch. However, the movement was boring. So, I make the emoji movement controlled by two different methods where the effectiveness of the methods change depending on the barrel's angular velocity. As a result, the movement of emoji becomes ridiculous and funny but at the same time, still realistic enough.

On the other hand, there is a bug where the character sometimes gets stuck inside the tilemap when high in velocity. Sometimes, Unity's physics engine itself is enough to save the situation. However, it is far from consistent. Therefore, I try to move the character to the opposite direction of its velocity to free it when it gets stuck in more than one frame. As the engine may fix it itself. As a result, the bug never showed again. Providing a smooth gameplay experience to the player.

During the development. Determining which spells are cast by the collected spirit was a challenge. The most straightforward way would be checking every spell with every collected spirit for each element. However, this is terrible in time efficiency with O(n^2).Therefore, I came up with two other solutions.

The first one is having an array of 4 integers. As the number of collected spirits for each element. Then loop through the spell list and check for spell cost. This achieves a time efficiency O(n) implementation with an array of 4 integers added into the memory.

The second solution is having a 4 dimension array as a spell list. Each slot of the array would be null or a spell item. Then again, having an array of 4 integers to count the collected spirits. So that, when a player casts the spell, I just need to find the item in the spell list with a time efficiency of O(1). However, the highest cost spell cost 4 spirits of each element. Therefore, a minimum of 256 slots will be allocated in the spell list. Which takes some memory.

In the end, I chose the first solution. As a game for game jam, I did not prepare a lot of spells i.e. 14 spells. Therefore, the majority in the spell list from the second solution would be empty. Which is not worth doing. In addition, for the same reason, in the worst case, n would only be 14 in the first solution. Although the second solution is convenient to show the spell player can be cast with current collected spirits. However, as a game plan for a WebGL build, I do not want to take too much memory. Therefore, the first solution is more suitable for this situation.

Since this game is developed during a game jam, we have very limited time. However, the game idea required enemy AI or multiplayer implementation to work. In which, either of them takes a long time to code, considering we only have 2 days for the game jam. During the game jam, we decided to stick with AI instead of multiplayer considering it is a game jam setting. After the game jam, enemy AI is reworked and multiplayer is implemented.

Before the implementation of the enemy AI, I need to design the architecture of the AI system. For the enemy AI of this game, the requirements are being able to observe the battlefield, including alli and enemy then decide an action of the pawn. Since the AI would need to observe the battlefield from the start for every turn. Therefore, it should be a behaviour tree like structure. However, it is different to a traditional behaviour tree. There will not be a processing return value since the end result is a decision for the turn. It will only return successful or failure, in which returning failure means error occurred. Additionally, an AI like this would need some randomness to be more unpredictable. Plus I also want them to behave like a team. Therefore, an offensiveness variable is added to the AI for each turn. It is determined by level of advantages i.e. number difference of pawns and a random generated number. Some nodes in the tree would return false when the offensiveness is too high or too low.

Implementing enemy AI, I first take note of all the possible actions i.e. end nodes of all three types of pawns would take. Then, take note of all the possible checks i.e. branch nodes. Next, sketch the diagram for all three types of pawns AI. Lastly, simply follow the diagram, and implement their AI. I found this workflow very efficient and free of mistakes. As a result, the first version of the enemy AI system managed to be finished before the game jam deadline.

On the other hand, multiplayer was being implemented after the game jam. In this project, multiplayer is implemented through unity netcode package. However, I did not use the built-in synchronisation functionality although it may decrease some work load. There are a few reasons. First, I would like the player pawns alway start at the same side, increasing the consistency and decreasing confusion. Second, pawns will only move in the action phase. Sending packages between players constantly is redundant. Therefore, I decide to only send packages when needed. At the start of the game, players would send their pawn setup to the server. When the server receives the setup from both players, the game will be started. In addition, pawn moves will be sent to the server at the end of the control phase. Again, once the server receives pawn moves from both players, the server will send back the pawn actions from both players to both players. Lastly, the moves will be translated and inputted into the enemy pawns locally. Performing the same movement to both sides, just mirrored.

As I am the only gameplay programmer for this 4 day game jam,I have very limited time. I aim to finish all the mechanics within the first two days. So that I have sufficient time left for adjusting and debugging. In addition, leaving enough time for our game designer and level designer to work on their part. In short, in 48 hours, I have to implement the frog's basic movements including hopping and jumping. In addition to the main mechanic including shooting tongue out, aim assist and tongue interactions.

First, regarding basic movements. I plan to implement a parabola movement for hopping which is linked to the walking input. Since I am not also the game designer this time. So, the first thing I did is to think about what parameters are needed for game designers to adjust the hopping behaviour easily. As I am implementing parabola movement, I declared 4 parameters including max hop height, hop distance, hop time interval and hop cooldown time for the game designer to control the behaviour. So that they do not need to know programming or mathematics to adjust the values and achieve the targeted behaviour.

During the implementation, I first translated the max hop height and distance to the A and C value of a parabola formula in the form of Ax² + C. The term Bx is not important since the frog can hop at any position and I only need to know the vector from the previous frame to the current frame. Therefore, at the end, I lerp through a timer from 0 to the hop time interval to find the x value of the formula from negative half distance to positive half distance. Then calculate the forward and height value change from the last frame and the current frame. Lastly apply the change with the frog forward direction into the rigibody. So that the chance of going through the wall is minimised.

Second, as for the frog tongue mechanics. Since this is a puzzle game instead of a shooting game. We want the aiming requirement to be as low as possible. That means the player should have no issue consuming the fly after they found it. Therefore, an aim assist system is necessary. The aim assist system I designed contains a number of box colliders queuing outward and increasing in size to represent a cone-shape collider. As I want to enable game designers adjustment. Implementation is flexible to different parameters including tongue max distance, aim assist angle and collider number. Which box colliders are generated based on those variables.

In the implementation, I first generate the target number of box colliders using the add component and store them in a list where a higher number of box colliders means a more precise cone shape. Then calculate the half box distance based on the max tongue distance i.e. max distance divided by collider number divided by 2. So that half box distance * (1 + 2n) where n is the index of the collider would be the position of each box collider. Next, from the position of each box collider, finding their x and y width using tan half aim assist angle. As a result, the aim assist system will auto adjust based on the value in the scriptable objects.