Caduceus
Project Type: University Studio
Engine: Unity
Language: C#
Role: Enemy Programmer
Caduceus was the first non-student project that I contributed to. I was assigned the role of enemy programmer alongside two others, with the entirety of the project consisting of upwards of 40 people. This project taught me a lot about both the benefits and detriments of working on a larger-scale team, and how to effectively plan and manage a codebase on this scale.
Minotaur Behavior
While I contributed to all three enemies in Caduceus, my focus was largely on the Minotaur. This included its patrol behavior, aggro detection, swing attack, animations, and refinement of its charge attack. The swing attack in particular was an originally unplanned addition that gave the enemy a more cohesive feel.
State Machine Drivers
Each enemy consists of multiple states to determine their behavior, such as peaceful, searching, and pursuing. I was tasked with the implementation of the state machine drivers for each enemy, determining what conditions were necessary to transition between one and another.
Basilisk Patrol Behavior
All enemies were scripted to patrol pseudo-randomly across their platforms. Our second enemy, the basilisk, performed similarly, with the additional ability to hop between different platforms. As well as the general patrol behavior for these enemies, I created a system in which the basilisk would detect valid connections to jump between along its patrol path. This created a more dynamic enemy and a significant differentiation between how the player interacts with the minotaur and the basilisk.
Basilisk attack and retreat pattern
Being a ranged enemy, the basilisk wants to maintain its distance from the player. An attack/retreat pattern was implemented, allowing the enemy to run while launching projectiles should the player come too close.
Determining Patrol Destinations
I implemented the system to determine valid destinations for each enemy during patrol. The enemy would sample the NavMesh to find a valid destination, determined within an angle either towards or away from the player, specified by the user calling the function. Allowing differentiation between player bias, the angle that could be searched within, and the minimum travel distance of the enemy from its current position allowed for each enemy to feel unique while minimizing duplicate code.
Phoenix Attack Pattern
I worked closely with another enemy programmer to implement the attack behavior of the flying phoenix enemy. Once detected, the phoenix circles the player, shooting fireballs and dive bombing periodically. Unfortunately, much of this behavior didn’t make it into the final product and had to be cut due to time constraints. The final iteration of the dive bomb now initiates a self-destruct instead of the above behavior.