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.

I tend to design the gameplay to a very detailed level. But the downside is, it requires a large number of parameters. As a result, the goal of design becomes very vague. To address this, I created a few situations that need to be satisfied. And the goal would be finding a parameter set that satisfies all the situations. For example, in this game, I want the player to climb a 3 by 1 slope with the requirement of drawing 1-2 circles per second so that it is very possible but requires a little bit of effort. At the same time, after falling from a 1 by 3 slope I want the player to be able to stop in 3 - 4 flat tiles length so that player has to really try and always worry of not stopping in time. At the end, after many trials of play testing, I found the parameter set to satisfy both situations and fit the goal of my gameplay design.

Regarding this type of game, I always think that the player can't do anything after a mistake is unfair. The different outcome only depends on the position of the mistake being made. Therefore, I want to design the level so that after making a mistake. Though some progress will be lost but the amount of progress loss depends on players actions. However, it is very difficult to design such levels. So I first sketch the platforming idea part of the section. Then link the section to the previous section and consider the potential failure and their outcome. Next, add appropriate potential save to the previous section or the current section. Lastly, repeat between play testing the level and fine tuning the level until I am satisfied with the result. At the end, I provide a challenging and sometimes frustrating but always fair experience to the players.

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.

During the design process of this game, there are a few aspects that I try to achieve. Those are rewarding resources management, minimum downtime boredom and providing game progression.

To reward players that manage the spirits on screen well, there is an elemental weakness system. The enemy has an elemental type. As well as the 4 spells that cost 2 of the same element. Which deals 150%, 100%, 50% and 0% damage respectively regarding enemy elemental type. In this case, the most optimal strategy would be to always focus on enemy weaknesses. However, the spirit on the screen may not always be ideal. Therefore, there are also two spells that cost 3 spirit which alway deal 100% damage. Furthermore, spells with 3 or 4 different types of spirit would spawn 3 or in the latter case, 5 onto the screen. As a result, players have more control over the battle and minimize the effect of luck to achieve rewarding game play.

Secondly, if there is no downtime for the player, it may be too chaotic and stressful for the player. However, if there is too much downtime without anything to do, it also affects the fluency of the game play. To address that, enabling the player to swap around the spirit is just perfect for the downtime. During the down time, the enemy is still waiting to be spawned. At that time, no stress would be added onto the player. But the player can manage around the spirit, increasing their advantage for the next fight. Therefore, providing a resting time without causing boredom of the player.

Lastly, I would like to provide a sense of progression to the player, even if this is a small arcade game. As a result, spells are designed to be unlocked in the library after the player has casted the spell once. Enable players to improve by learning more knowledge of the spells and providing a discovery kind of game play experience.

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.

During the designing process of this game, I would like the 3 classes to counter each other like rock paper scissors. However, the advantage of the counter relationship should not be too significant. As strategy and prediction should be the most important component in the game play. Therefore, my aim is to design an advantage for each class against the counter class. But still able to turn the table if the prediction of the player is correct and precise.

Regarding the relationship between archer and knight, archers move distances further than knight. So, an archer can kite the knight. However, archers would need to reload after an attack which it cannot move when reloading. Therefore, despite the advantage to the archers, knights can win against archers if they can catch archers during the reload.

As for the relationship between knight and scout, knights have significantly higher health than scout, plus, if knight blocks an scout attack, scout cannot damage another pawn with the same attack. Knight can win scouts by trading hits easily. However, if scouts are able to catch the knight off guard and attack from behind, it is possible that a scout will defeat the knight.

Finally, the relationship between scout and archer, as scouts can move very far. They can punish a reloading archer easily. However, since archers, especially a reloading one, are such a good target for scouts. The action of the scout can be easily predicted and punished by another pawn.

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.