Second group project I was part of at Futuregames (This was worked on in 2025 and was made in Unity)
The team was 20 people total and I was one of four programmers.
The theme we had for this project was "DaggerBlade" (A fictional dagger that a setting revolves around)
The way we went about was this:
You as the player uses the intelligent DaggerBlade to teleport kill enemies in a speed run fashion.
I worked on some of the main systems of this game.
Those being player movement, AI and audio managers using FMOD.
I also did VFX implementation for both enemies and the player.
I did a lot of smaller things as well, like the camera shake, FOV changing while sprinting, the speed lines that appears when running implementation, the particle hit effect implementation.

I did a lot of work during this project. So much that the team got worried about me quite often. But I had really good programmers as teammates, so I felt that I had the support when I needed it.
But as a team, there was a lot of conflicting info in the GDD and other miscommunications plus over-scoping. Some things got cut because of it.
My takeaways:
Keep balance between hyper focus work and rest time. Also that even if you create something complex and powerful, don't expect it to be
utilised correctly or reach it's full potential. Like the wall running bug which I accidentally added in.

This is the core script for my AI system. I got inspired when I looked up GOAP and utility AI, with a little bit of behaviour trees. It uses scriptable Objects to hold the decision information. I use a float score to determined if a decision has higher priority. How it creates that score is dependant on the decision itself.
Child decisions has priority, so in comparison to behaviour trees, the whole chain do not need to be true, only that at least one child decision is true.
Will explain more in the other scripts which are part of this system


Here are some pictures from our Miro board.
I created these notes while I was initially creating the design for this AI.
The movement for the AI uses unity navmesh.

This scriptable object both stores and handles FMOD sounds.
This allowed me to just insert it to whatever object I wanted to and keep it modularized, since I can have a library for player sounds, enemy sounds, music etc.
It has all the necessary functions which we needed to handle all the sounds for our game.

Here I store many separate structs which are used by decisions. Each enemy has their own blackboard instance.
Each struct can be looked at or updated independently.
Here is the abstract base for all decisions. It is a scriptable object and has three abstract methods.
GetConditionScore(): Returns the current decision score for this decision.
DoDecision(): Activates the functionality of this decision.
UpdateGizmos(): This sends updates to the AI_Gizmos script.
The script also holds the minimum score float, child decisions array, decision delay (Is handled in AI_Core update), and scoreGainModifier, which changes how much score a decision generates.
This handles all debug visual for the AI system.
You can change colour on all the different visual elements, like max detection distance (which is shown as a sphere) or raycasts.

Here is one decision type. I created all scriptable Object decisions in such a way that they can be used for different, but similar types of decisions. Like to move towards patrol point or towards player.
It will affect the navmesh component, since I'm inputting in the AI_core which holds the navmesh reference.


Here is the decision which handles how enemies shot projectiles towards a point.
You can decide what it will shot, how fast and how much damage it will deal. You can also allow it to move and shot at the same time.
This one handles all the music. The music itself is stored in a scriptable object called SoundLibrarySO (Will explain it later in this page) which also stores functions which this script calls upon.
It also handles how the combat music intensity based on how many enemies are left. It uses a coroutine function to check how many enemies are currently alive.
This class stores an array of structs called PathGroups. The struct holds both enemies and transforms which are used to create a patrol path for those enemies. Both are arrays.
It also draws the patrol points using Gizmos rendering, were you set the colour in the inspector. Making it easier for the designers.
Our movement uses both the new input system and the character Controller unity component.
It uses a state machine for the jumping and the character Controller Move function to cause movement.

This script is attached to the main camera and handles the mouse input from the new input system.
It also stores an array of CameraShakeTypes, so you can have different types of camera shakes based on what action the player does. It stores them into an dictionary, so that you can easily trigger shakes whenever an action is performed.
The camera shake itself is performed through a coroutine.


This handles our text based cutscene segments of our game.
You can set the colour of the text and when it should start/end.
The line structs are stored in an array and uses TextMeshProUGUI to display the text. The struct itself stores the text, colour, start time and end time. (The start and end times are only for the text displaying!)
It will also switch scene after it has gone through all voice lines.
The sound are of course stored in a SoundLibrarySO.