The project's custom kinematic motion logic is used to calculate the movement of the player-controlled ship and the automatically controlled drone ships. The system calculates and handles velocity, acceleration, and jerk for the ships' forward linear motion and left-right rotational motion. 

Since it avoids using mass and forces, the system also relies on small workarounds to simulate player weapon recoil and drone hit knockback. Because the weapon fires along the player's forward direction, recoil is is applied to the ship's linear motion as negative jerk. For knockback, an "apply acceleration over time" task is sent to the affected drone's action list, pushing them away from the point where they were hit.

The player character for the project utilizes a "chain gun"-like weapon that can destroy drones and other NPC entities. In addition to having a "hold fire button to ramp up fire rate" mechanic, the weapon also possesses three different configurations. These include a fast-firing light version, a balanced normal version, and a powerful heavy version. In implementing these archetypes in C# script, I tuned and balanced the specific numeric properties of the weapons.

The starting scene of the project is populated with passive drone ships that continuously travel towards randomly generated target positions. I created these drones by implementing standard steering and following AI behaviors; although, additional work was necessary to handle their other, randomly-variable property. For each new target point, a drone randomly determines whether or not to come to a complete stop at it. To enable them to stop perfectly at their targets, each drone's kinematic trajectory is pre-calculated according to its current physical properties. If these calculations show that the drone will overshoot its target, the drone will slow itself down.

Players are able to activate a variety of time manipulation effects during gameplay, such as the ability to speed up or slow down NPCs. To facilitate these effects, I created a time scale control system that can individually modify time scaling for different objects and systems. This system was especially useful for preventing player and enemy-focused time scale changes from affecting UI and input-related actions.

The project's UI and visual effects systems are primarily implemented though heavy use of action lists. 

With simple transform actions and a modest variety of easing functions, configuring UI animations though the project's overarching UI action list is simple. For example, motion for the project's tutorial pop-up and the boss enemy's title card are handled using only a few translate and scale commands. 

The different types of visual feedback elements are also easy to set up and use. Screen shake effects are utilized whenever defeating or damaging enemies, and text particles are created when attacking NPCs or gaining status effects. Both are handled using a mixture of translate, scale, and fade commands.

The boss entity itself is made up of multiple appendages: its head and neck, its two wings, and its two talons. Each appendage is comprised of individual segment objects, with each segment acting as an object parent for all remaining outer segments. Each appendage can be damaged and destroyed independently of the other, enabling the player to dynamically disable the boss from performing certain behaviors. 

For each of the boss's wings, the individual "feather" segments are arranged into three distinct rows of dependencies. Unlike segments on the other appendages, each feather can be independently destroyed, deforming the shape of its respective wing. Once a certain number of a wing's feathers are destroyed, the rest of the wing is destroyed. 

The central body of the boss is unlike these appendages. Besides having no effect on any combat behaviors, it is only comprised of a single segment. Furthermore, its destruction instantly results in the total destruction of the boss.

The boss utilizes a random set of four attacks to try and harm the player. Its three main attacks are intrinsically tied to its three primary appendages, and each one applies a unique status effect.

• The wing slash attack applies a damage-over-time "burn" effect and covers either the left or right half of the screen.

• The talon grab attack immediately applies the "stuck" effect on a hit, disabling the player's movement. If the player is grabbed, their ship is pulled to the boss for some painful close-range pummeling. Since the "stuck" effect does not disable the ship's weapon, this attack can be an opportunity to land some devastating close-range shots on the boss's body. 

• The head slam attack attempts to target the player's recent position and generates a shockwave that applies the "shutdown" effect. While the player's ship is capable of moving while this effect is active, all control over the ship is temporarily lost.

I felt that this initial set of attacks wouldn't be enough to give the encounter interesting variety, so I decided to create a fourth attack for the boss. However, since I didn't have time to create a new appendage before the project's deadline, I would need to create an attack that somehow took particularly unique advantage of the boss's existing visual elements. The result of my efforts achieved this goal well.

• The laser ricochet attack projects a series of damaging lasers. Signified by the wild rotation and movement of the boss's head and talons, one laser is initially fired between the head and one talon, another between the two talons, and the last from the second talon towards the player. Depending on the number of talons that have already been destroyed, the boss will instead fire an additional number of lasers directly at the player. This attack can be hard to dodge, but it does not apply any status effects.

Each attack uses specific telegraphing geometry to inform the player of where they should move away from to avoid taking damage. Much like the project's UI elements and other visual feedback systems, this geometry is controlled and modified through the use of action lists.

The logic behind the different attacks' telegraph geometry is not uniform. Since the laser ricochet and talon grab must both adjust trajectories based on the player's position, the position and orientation of their geometry must also constantly update during the windup period. However, for the wing slash and head slam, areas-of-effect only need to be shown at a single fixed position. Because of this, the only property of these attack's geometry that needs to be dynamically adjusted is their opacity.