Gameplay Programmer with AI Expertise and Team Leadership Experience
Skytail
Lead Programmer, Additional Design
Released 26/03/2026 for Meta Quest 2 & Meta Quest 3
Skytail is a VR game in which you use telekinesis to fight enemies, defeat intimidating bosses and explore islands in the sky together with your bird-dragon companion. As you progress you enter trials which give you new telekinetic abilities to master, building on your skills and creating rewarding and physical gameplay.
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.
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
From the very beginning of Skytail I was heavily involved with the creative process - I even came up with the original pitch and underlying core mechanic of the game; telekinesis in VR. This was the concept I chose to pitch based on the VR games I had enjoyed the most, those being Super Hot VR and Beat Saber. When analysing what I enjoyed about these games, I realised it was the physicality and the fact both experiences simply can’t be replicated outside of VR. To this end, I aimed to pitch a VR game that truly made use of the hardware and justified being available on this platform. Thus, telekinesis.
Throughout the project I put forward many artistic and tonal suggestions. I was also working closely with the designers to help them problem solve solutions, give new perspectives and rapidly prototype ideas to help us find the fun and determine if a proposal was feasible. I recognise in some studios this is a very rare opportunity, so I am very grateful that I was able to use and hone my design skills but I am able to recognise when to step back and focus on my primary role of programmer.
Unreleased Skytail Predecessor
Between Jurassic World ending and Skytail as (it was released) beginning, there was an unreleased game which is technically considered part of the Skytail project. It was once again a VR title, though significantly more ambitious than both Skytail and JW. On this project I was once again heavily involved with enemy AI and gained further experience with best practice, prototyping multiple different types of potential enemy and of course animation implementation. I became comfortable with Object Oriented design and generally gained a much stronger understanding of game programming fundamentals. My 3D maths improved, my physics improved, and I had a lot of fun trying out new systems patterns and seeing their benefits and draw backs. My exposure to underlying systems also started here, providing a solid enough understanding for me to know which direction to take them in for Skytail as lead programmer.
Furthermore, I had begun to take a more active role and gained confidence with voicing my thoughts on the overall experience of the game and potential issues. It’s this confidence that I took into Skytail that allowed me to become lead and so heavily shape the game. It was the failures of this project both as a project and as a product which allowed Skytail to run so successfully and to be such a solid player experience despite the incredibly tough circumstances of it’s development.
Tools Team
During this period I also spent some time on Coatsink’s Tool Team - a small group of programmers that created and maintained packages and tools meant to be used on all of our Unity projects. I had the responsibility of creating a unified animation system that would be an alternative to Unity’s Mechanim. At which point I pointed out that would be ridiculous, why on earth would a studio of 80 people do that. I verified my conclusion with several senior programmers, and so I instead spent my time on the team working on our system for adding SFX, VFX and other events to animation clips. I was proactive in giving myself work and improving the tool, though ultimately I left the team because of this lack of direction while I needed to learn and develop my skills after being limited to raptor AI with ECS.
Jurassic World Aftermath
Intermediate Programmer on Dinosaur Team
Released Part 1 17/12/2020, Part 2 30/9/2021 for Meta Quest & Meta Quest 2
Jurassic World: Aftermath is a game in which the player ventures to an abandoned Jurassic World facility on Isla Nublar, and must complete various tasks all while evading a group of 4 raptors and various other dinosaurs and threats.
ECS / Data Oriented Design
A unique challenge of this project is that it was built using Unity’s ECS package as it was being written. We had to learn the new way of working with scripts and systems and apply it to the designs given to us to implement, as well as communicate with Unity to give feedback and adapt to the rapidly evolving package. All in all it was a challenge, but it was a fascinating insight on how libraries and packages are developed. Now, I have a great love for systems that mimic the data oriented design approach as I believe it to be very elegant and versatile especially during fast paced development.
Raptor AI
The raptor AI was the largest chunk of work that was undertaken for our team on this project. Initially, as per “Alien Isolation did it”, Utility AI was implemented in an attempt to make the raptors a compelling and fun enemy to play against. However, as anyone who has actually worked with such a system knows, it is a very poor choice of AI algorithm for the vast majority of circumstances. The result was a black box where the raptors were not predictable nor understandable, so even though their internal logic was sound, they appeared erratic and unintelligent. They lacked intentionality and most importantly, were simply not fun to play against and success felt random rather than as though you could outsmart them. Therefore we adopted a more traditional state machine, which was significantly more fun to play against in large part due to how the designers were able to tune the system.
The raptor work also included extensive animation implementation to ensure everything blended smoothly and there were no obvious errors such as jerking or foot sliding. This is where I gained a lot of experience with Unity’s Mechanim but also general animation principles.
Additional Programming
Although my main role on the project was raptor AI, I also aided various teams with bug fixes, creating hacking minigames and rewriting the T-Rex code from Object Oriented to ECS and further refined the system with animation implementation and general smoothing and playtesting feedback.
AI Director
As I had experience with AI Directors due to my dissertation and the original game design was quite different from the eventual linear experience, myself and the team explored the possibility of introducing an AI Director into the game. Unfortunately due to time constraints and the linear path, the resulting AI Director ended up drastically reduced from it’s original design and ended up not resembling a true AI Director as it did not make a judgement on the player but rather controlled the abstract idea of tension which then had the output of the ambience system. It is rare that an AI Director is applicable to a game, so I am glad that myself and the team decided to reduce it down and focus on the more important aspects of the game such as the raptors.