Skytail

EnemY AI

Enemies in Skytail include both waves of small enemies which are fought via telekinesis powers as you soar through the clouds, and a boss which you must strategically destroy at the end of each combat section.

• Enemy Wave Coordinator - The largest part of work for this project was implementing the waves, ensuring that the rules outlined by designers were enforced as enemies were killed and new ones spawned. There were different types of waves, so I made use of Scriptable Objects and Interfaces so that generic functions such as “SpawnEnemy” could be used for each wave type to internally calculate which enemy to spawn, for example. This kept the executing code clean and readable.

• Enemy Stage - The enemy stage determined the placement of enemies using a curved grid. Enemies could favour particular parts of the stage, but had to be placed somewhere their internal movement pattern would fit.

• Boss - The boss had tendrils which extend outwards from it’s centre, and multiple phases during the combat. The main challenge with this was how often the design changed and the code had to be adapted, coupled with the time restrictions. However, the result is exactly as envisioned despite the numerous changes.

Lead

My time as lead programmer on the project essentially began in January of 2024. My responsibilities included creating a project timeline, allocating tasks to the growing team, flagging early when either additional resources or a scope reduction were needed to meet deadlines and communication with other departments for features and timelines. Feedback from other departments regarding my programming team’s performance also went through me, and I

The timeline was incredibly unforgiving, and even with consistent scope reductions I had to very carefully monitor the rate at which tasks were completed compared to where we needed to be. If at any point I felt we were not on track or the work took longer than anticipated, it was up to me to resolve that issue until the timeline was realistic again with suitable buffer room for unexpected issues.

I largely achieved this through use of a spreadsheet in which each task was tracked, as I unfortunately found Jira insufficient for the level of oversight I needed due to the time restriction. One key issue was priority conflicts; asset implementation may be high priority for one department but it may not be high priority for code, but with a separate spreadsheet I was able to represent this. It provided an excellent overview of each month of work assigned to programmers, provided an easy reference to see who had previously worked on a feature and was invaluable for planning work for each programmer. There were drawbacks, particularly the maintenance, and I would not implement such a system again unless absolutely necessary. However for the case of this particular project I saw an issue and I solved it by creating a powerful tool that ended up being invaluable for every department.

Design Contributions