The catapult was a part of the core of the game, so I was asked to work on it pretty early in the project.

I worked on the entire system around the catapult, from path prediction to the actual shooting.

Egg loading

The first step to being able to use the catapult was to load an egg into it so it could be used as a projectile. We also wanted to be able to have eggs in a "storage" so the player would not have to load a new one every shot.

The solution I came up with was to use a structure that would hold a reference to an egg and a scene component linked to the catapult. Whenever a player would try to place an egg in the catapult, I would verify that at least one of these egg holders was free and place this egg in the first free one found (prioritizing the arm of the catapult). The scene component was used as an anchor for where the eggs would be placed once loaded in the catapult. I made this anchor system to allow our artists to move the placement of the eggs around as needed. It also was used to move the eggs with the catapult when aiming.

Egg launching

With the egg ready to be launched, the next logical step was to launch it. All that was needed was a way to launch the egg like it was launched by a catapult.

Two methods were considered for this : a pure physics based approach, using spring constraints on the catapult arm, and a simulated physics approach, using Unreal's projectile component. I made a prototype for the pure physics approach, but it was inconsistent and unreliable due to the presence of a lot of uncontrollable variables that could affect the physics. After the prototype, I decided to go with the simulated physics method.

Using this method was not only more reliable but also a lot simpler to do. I added a collision box on the spoon that detected whenever a chicken would fall on it. This triggered the launch logic, which rapidly rotated the catapult's arm upwards and checked if an egg was present in the cup connected to the arm. If there was an egg, it was separated from its anchor point, teleported to a launch position, given a velocity, and activated. Prior to being activated, the egg would just ignore most collisions to avoid accidentally triggering it. After a small cooldown, the arm would go back down if no chicken was blocking its path. Once down, if an egg was present in one of the storage cups, it was moved to the arm.

Path Prediction

Using a catapult is hard since you do not have a sight to aim. This is why I added a projectile path prediction visual. I used Unreal's path prediction function to get accurate physics based points along the path the egg would follow. I then instantiated a spline mesh between these points to create a visual representation of the projectile path for the player. Once this was done, I added a simple sphere at the end of the prediction that scaled with the impact size of the egg so the player can also know the zone that will be affected by his shot. I wanted to avoid updating this on the tick since updating it that often was unnecessary, so I made a looping timer function. This also allowed me to disable the update if no chicken was using the catapult. This was the first iteration of the path prediction.

Once this was done, a major problem occurred. It was the fact that instantiating multiple objects every time the path was calculated was not efficient and even less optimized. To counter this, I used an object pooling technique so the objects would not have to be instantiated during the update. During the game launch, I created spline mesh instances and disabled their rendering. Then, when the player would start to use the catapult, I would use those instances instead of creating new ones. 

Rotation and distance adjustments

The players needed to be able to aim with the catapult. In order to aim with it, we needed to allow them to rotate and adjust the strength (distance) of this catapult. 

At first, I tried to use a similar system to the player controller inputs. When an input was triggered, it would rotate the catapult or adjust the strength variable. It was working when used in a single player condition, but it became unstable, with jittering movement when using it online due to packet loss and latency.

To avoid this kind of problem, I needed to change my approach. I made it so whenever a player would press or release one of the inputs to move the catapult, it would call a reliable server function to start or stop adjusting the catapult. Using a timer, the catapult would modify a replicated "wanted rotation/strength" variable, and in the catapult's update, those variables would be used with a lerp to apply the appropriate modifications. Using this system, any minor problems with both latency and packet loss didn't affect the game.

As a part of our reactions, we wanted to be able to have an effect on some objects in the environment by setting them on fire. This would cause the object to be destroyed and open up a faster path for the foxes. I was tasked with the destruction and reconstruction of those objects.

Object destruction

For the destruction of the object, I created a destructible class that took a dissolving material Nathan Hemez did as a variable. I then implemented the flammable interface on this object. Whenever something called the interface, I would start a countdown and the dissolving of the material. The dissolve speed was dependent on the countdown so both would be synchronized. Once the countdown was finished, the object's collision was disabled to allow the foxes to take the new path.

Object reconstruction

With the object's destruction now working, the next step was to allow the player to reconstruct it. 

For the actual reconstruction part, it was only a matter of re-enabling the collisions, reverting the dissolve of the material, and disabling the selectable path for the foxes. The problems came from how the player could reconstruct the objects.

We already had an interaction system in place, so using it to allow the player to reconstruct the objects was a logical choice. However, the system was made with the interaction of small objects in mind (mostly for the eggs and the shop) and its max range was checked using the chicken's centre and the interactable object's centre. The destructible objects were a little too big for the base range of the interaction, so I had to create a component that raised the max range of the interaction while the player was close to the destroyed object. I also used this to give a visual feedback of the price it would cost to reconstruct it when the player was close enough.

The player was now capable of detecting the object correctly, but it was also possible to soft lock the game by reconstructing the object on top of a player or a fox. To counter that, I added a collision that would detect if something was in the way of the reconstruction. With this, I also added another material that would give a visual feedback to the player, telling them if it was currently possible to trigger the reconstruction or not.