PRE-GOLD

Being the final sprint of Caduceus’ development, my primary goal was to polish any content that was already in the game over implementing anything new. That said, having already reduced the scope of the project drastically, the enemies pod wanted to prevent the loss of any more planned content. While we were unable to make previously planned enemy variants or a boss enemy, we felt that it was crucial to the quality of the game to have three solid enemies implemented. The first half of the sprint was used for just that – finalizing the implementation of the flier enemy (along with some smaller tasks), leaving the latter half to focus on playtesting and polish.

Going into Pre-Gold, the flier lacked any sort of attack. Another member of the pod and I worked together to correct this. The flier has two attacks: a ranged, similar to the shooter enemy, and a dive bomb. It was determined that the best way to handle this was through a secondary attack driver for the flier that called the respective shooting/diving scripts. I created the driver, utilizing the ShooterAttack script for the ranged attack (finally, some modularity!) and worked on integrating the attack patterns with the circling movement of the flier that had previously been implemented. As was the case all too often during this project’s development, the attacking and movement scripts did not cooperate nicely together. The movement script had to be significantly altered to accommodate the new attacks, creating an unfortunate dependency between the two.

I also spent a good amount of time debugging the flier’s “twitchy” movement (an error caused by the radius and height of its circling pattern being updated too frequently), binding it within an area near its spawn point (or near the player while aggressive), and creating a fully functional prefab. I was unaware at the time that another member of my pod had been working on other changes to the flier’s movement. This resulted in my first merge conflict. The next day, I met with this programmer and the programming lead to work out the details of our script changes and to determine how to integrate them together. While the prospect of additional work on an already tight schedule was stressful, ultimately, I developed a better understanding of how to resolve such conflicts and ways to prevent them going forward.

Flier enemy attacking

The flier enemy attacks and dive bombs toward the player (prior to graphical implementation)

Most of my remaining work went into the charger enemy. While functional, the charger’s movement patterns and animations left a lot to be desired. Many changes were made to give this enemy a better feel overall. The charger now stops between patrol locations for a set time and turns before moving to a new one, as opposed to awkwardly moonwalking while rotating during its direction change. Shooting the charger now changes it to an aggressive state, removing the ability to attack it from a distance with no repercussions. While choosing a new direction to patrol, bias towards the player was removed completely, replaced with a random bias of turning left or right from its chosen direction if that direction is not valid. This was done to prevent “clumping” of chargers, where they tended to move in the same general direction throughout the map. Animations in general also underwent a large overhaul. Triggers were moved, added, and deleted at appropriate locations, a new idle animation was added, the charge telegraph animation was changed, and transitions/speeds of animations were altered where necessary.

The most significant (non-visual) change was the addition of a secondary attack when the charge attack is on cooldown. Previously, between charges, the enemy would pursue the player, but not interact with them if it got close and its charge was on cooldown. I added a swing attack for these situations by enabling/disabling a collider on the charger’s weapon when one of two randomly chosen animations are played. The charge attack is also never activated when the player is within melee range, the hammer swing of the charge now occurs before player collision, and the time between charges was also reduced. This addition makes the charger feel threatening and engaging, and together with the other changes forms a much more cohesive enemy.

Charger aggroing from damage and performing new swing attack

Charger with new animations and behavior, aggroing from taking damage, and performing its new swing attack

Other tasks this sprint included adding tooltips to serialized variables in every enemy script for ease of use, fixing collisions between player attacks and enemies, adding events for flier animation triggers, and helping with some of the known shooter issues. Specifically on that front, I changed the look rotation of the shooter from “snapping” to certain locations to slerping between them, helped to fix incorrectly triggered animations, and streamlined the shooter’s movement speed across states, rather than having it move slowly while running and move quickly while walking in many cases.

While the enemies are not in a perfect state as of this post, they do feel much better overall, and I am proud of what I was able to accomplish in the allotted time. Looking back at this project, we ran into many issues that could have been prevented with better organization, planning, and coordination. Our early goal of modularity slowly morphed into a mass of highly dependent scripts, which is unfortunate. But given that we are all students with an immense amount of work on our plates outside of WolverineSoft Studio, I believe cutting corners in some of these cases was inevitable. I’ve now experienced firsthand how quickly making exceptions to code quality and control can devolve into unsafe and difficulty to work with code, and I’ll take what I’ve learned here to prevent similar problems on future projects.


Time breakdown:

Weekly studio meetings – 2.5 hours
Additional enemy pod meetings – 2 hours
Flier attack, integration, and debugging – 8 hours
Merge conflict – 1 hour
Charger polish – 8 hours
Charger second attack and charge tweaks – 4 hours
Tooltips, projectile collisions, and flier animations – 3 hours
Shooter tweaks – 6 hours
Total time spent: 34.5 hours

Next
Next

PRE-BETA II