Technical Game Designer
Gameplay Systems · Game AI · Tools
Kenechukwu Umelo
Project Mr. Static!
Role: Technical Designer | AI Programmer (Solo)
Duration: August 2025 - December 2025
Genre: Boss Battle
Engine: Unity
About:
What started as a solo project to fundementals of boss design evolved into a 5-month project, where it became a narrative-driven boss encounter.
My goal was to understand the elements of boss design to create a balance of tension, escalation, and engagement for players. Technically, I wanted to explore using AI architectures such as Behavior Trees & State Machines with enemies and the boss to improve my AI scripting skills..
As 2025 came to a close, I wanted to complete an AI design project in Unity before shifting my focus to learning Unreal Engine.
Highlights:
-
Implemented responsive player movement, camera, and combat systems.
-
Designed the initial boss AI using Behavior Trees and five custom combat action tasks.
-
Rebuilt the boss AI as a Finite State Machine for greater control and readability, implementing eight distinct states with tailored logic.
-
Developed five enemy bot classes with unique attacks using Behavior Trees.
-
Built feedback systems (hit reactions, barks, combat signals) to improve clarity and player understanding during the boss encounter.
Player Controller & Combat
Player Controller + Hit Interactable Objects
Building the Controller:
To start strong, I implemented a player controller that focused on responsiveness and simplicity. I started with that clear goal, so the code would be scalable if I wanted to add more abilities for the player later. The controller handles all movement, camera control, animations, and input.
Combat:
I aimed for a straightforward "left-right" punch combat, drawing on 3D third-person platformers such as Astro Bot and Ratchet & Clank.
With this choice, it left a lot of room to experiment with other potential abilities. I did get a little ambitious and complex at times, given that they were ultimately cut, as I felt it was unfair to introduce too many abilities in a demo for players to learn, and also, it would defeat my goal of maintaining a more responsive and simple feel.
The trade-off was a Hit Interactable System that triggers a reaction (sound, animation, or VFX) when the player hits an object. This meant that objects can be designed to how they respond when the player strikes them, whether it be a box, an explosive, or an enemy.
Me throwing punches before boss arrives in Astro Bot
View Scrapped Player Abilities
Pick Up and Throw
At the earliest, I experimented with players being able to pick up and throw crates (and explosives) as well. My intention in the original iteration was to identify opportunities for players to counter Mr. Static's Ship while it was airborne. Throwing things seems like a good solution.
Why was it cut?
Due to the change of iteration from the ideal prototype, this feature was deemed pointless if Mr. Static was always grounded.
Suction Blaster
Replaying the latest Ratchet & Clank sparked the idea of implementing a weapon to counter Mr. Static's ship bullet projectiles while airborne, featuring an aim sight and trajectory visual. I intended to identify ways players could counter MR. Static in his ship at the time, which led me quickly to develop this concept.
Why was it cut?
With the camera systems in place for the boss fight, the blaster and aim UI interfered with base movement and inputs. For time and scope, I removed it to continue improving base movement and combat.
First Iteration of Boss Fight
Design Pillars:
Right off the bat, when I began working on this project, I did tons of research into different types of boss fights and what I wanted to accomplish for this boss encounter. Going into this project, I kept two core design pillars in mind:
-
Clear Structured Encounter
-
The boss needs a clear, concise strategy at all times to leverage the arena and apply constant pressure to the player in each phase.
-
-
Readability and Anticaption
-
Players should understand the signals that indicate when a boss is about to strike and learn to study anticipation and execution at any point.
-
Prototyping:
For the first iteration stage, the core loop for the boss battle was as follows:
-
Players identify and destroy Static Towers to force Mr. Static's ship into a vulnerable state.
-
Once grounded, players capitalize on his cooldown window to deal damage before this ship recovers and re-enters a protected phase.
1st Iteration of the Boss Battle
This encounter was built as if it were a scripted mission, combining gameplay and presentation systems to guide player understanding of the boss mechanics. Additionally, I put together several boss behaviors and systems in place to execute this encounter.
For more detailed descriptions of work on these systems, expand the tabs below:
Behavior Tree Implementation
To manage all those behaviors and attacks, I used a plugin called Behavior Designer, which is essentially Behavior Trees for Unity. I used it only to execute attacks, but based on either phase or its ground check.
Iterations of Mr. Static's Behavior Tree during 1st Iteration of the Battle
It was cool to finally be able to put together a behavior and even write custom tasks & conditions to support the boss's behaviors, but the drawback was that it took multiple iterations to assemble correctly, and it was buggy at times when transitioning between current ground or phase conditions.
Eventually, I was able to assemble a functional behavior tree for the Boss AI on the 4th iteration.
Feedback:
Following the first playtest, which I hosted with friends and colleagues, here were the results and what happened next:
What Went Well
What Went Wrong
-
Player (Bot-man)'s abilities felt overloaded.
-
Since throwing and shooting were implemented in this iteration, I realized that forcing players to learn too many abilities in a short time didn't benefit them during fights, as both throwing and shooting were rarely used.
-
-
Lack of challenge or pressure on the player while hitting the "Static Towers."
-
Players felt unchallenged, and the boss spent more time in the air traveling along the nav mesh rather than attacking the player. They would focus on the enemy bots chasing them until the camera system reinforces their memory that the boss still exists.
-
-
Lack of consistency with attacks from the boss
-
Aside from a few attacks, players reported being unable to read the enemy or phases, which led to their deaths early on. Someone told me they couldn't tell if they could even hit the boss due to no indication of the ship being hittable until I told them.
-
-
Design-wise, this DIDN'T feel like a boss; it felt more like a special enemy.
-
With no change in escalation, slow attack speeds, and no clear visuals showing the boss's current state, it all felt like a special enemy next to an actual boss.
-
Why I went back to the drawing board after this iteration
Given that I'd been working on this boss fight for three months and had playtested it once, I considered not only the design feedback but also the technical side and realized how much code couldn't scale to incorporate it. I could easily see I was reaching out-of-scope territory there.
I took a turn and decided to change direction for the design of this fight. One that focuses more on story and impact than innovative mechanics. Here are a couple of changes I made to make this possible:
-
More grounded boss encounter - to reduce the scope, I focus on making this a more grounded fight, where players can physically see the boss moving around.
-
Revamp Mr. Static's combat completely and reduce player abilities - ensure players are not being overwhelmed with a tutorial-less demo and a horde of attacks from the boss when the fight starts.
-
Finite State Machines >>>>> Behavior Trees - accounts for proper transitions between states. No more struggling with executing attacks and cooldowns based on sudden state changes.
-
Reduced the arena size - with the boss no longer having a "ship", there was no need for players to wander around a large empty arena.
CODE SNIPPETS
Player State Controller
Code below contains functionality for player controller
Hit Interactable
Code below contains functionality for GameObjects that are hit by the player
Final Iteration of Boss Fight
Prototyping:
For the second iteration, I structured the boss fight to be more grounded and leveled so that players can see the visual threat ahead of them, along with its attacks. For this version, I wanted a clear, readable loop that players can follow and understand while providing a steady, difficult increase curve.
This is where I turned back to my collection of third-person platformer games to analyze boss patterns and loops. One that stuck out to me was a fight that took place in Jak 3, where Jak battles Cyber Errol in a war factory.
The boss loop in that battle stood out to me due to how focused it centered on Cyber Errol utilizing his mechanical abilities to launch enemies and projectiles, then launching timed missile bots for the players to deflect to damage him while at certain stations.
The difficulty curve came with damage increases to the projectiles tossed along with the number of robots spawned to charge the player as the battle continued, ultimately beginning to take out floor panels, adding another layer of pressure to not fall off.
Highlights of My Playthrough of Jak vs. Cyber Errol in Jak 3
Almost mimicking that gameplay loop, I changed how Mr. Static operated against the player, so rather than flying a ship, he controlled several weapon stations that fired off different types of attacks while summoning bots to strike the player. I mapped out the loop as follows:
-
Mr. Static summons bots and moves between weapon pods to attack the player
-
Players clear bots to safely engage with Static Towers, which power the weapon stations
-
Destroying a tower disables its corresponding weapon, reducing encounter pressure
-
If all towers are destroyed while Mr. Static is outside a pod, he resets by summoning bots
-
If all towers are destroyed while Mr. Static is inside a weapon station, he is forced into a vulnerable state
With that outlined, I was able to put together the new iteration of the boss encounter shown below, showcasing this new loop.
Second Prototyped Iteration of Boss Fight
This iteration significantly improved the encounter by leveraging the Hit Interactable system across all gameplay elements. Shifting to a grounded design made the boss more readable and engaging, allowing players to better understand and respond to its behavior states appropriately.
These changes scaled across multiple systems, requiring updates and new solutions for problems that appeared. Detailed breakdowns of these updates are provided below:
Behavior Trees to Finite State Machines
Working with behavior trees during the first iteration helped learn how they worked, but that doesn't mean it was the right solution for this particular boss fight.
I stumbled upon a GDC Talk titled "AI Arborist: Proper Cultivation and Care for Your Behavior Trees." During this presentation, Bobby Anguelov (Programmer @ Valve) mentioned to "Stop building large monolithic trees with multiple responsibilities." (37:16) He then recommended State Machines for Boss Battles, as making one in Behavior Trees would be a "nightmare" due to the weakness of bad transitioning. Well, I've known well-crafted boss fights using BTs, but in this case, given how true his statement was for me at that moment, I didn't hesitate to move away from Behavior Trees.
State Machine Flowchart
Boss Attacks (Weapon Stations)
Weapon Station: Turret
Mr. Static fires rounds inside his turret and deals low damage to the player.
-
Phase 1
-
5-round interval burst
-
Timing: 5 bursts → mini cooldown (0.5f)
-
-
Phase 2
-
5-round interval burst
-
Timing: 5 bursts → mini cooldown (0.2f)
-
-
Phase 3
-
5-round interval burst (w/ shotgun round possibility)
-
Timing: 5 bursts → mini cooldown (0.5f)
-
Weapon Station: Cannon Wave Bomb
Mr. Static throws bombs at the Players' pinpointed exact location. Deals medium-high damage to the player.
-
Phase 1
-
10 throws
-
Timing: 1 throw → bomb lands via animation curve timing
-
-
Phase 2
-
10 throws (possibility with static wave on land)
-
Timing: 1 throw → bomb lands via animation curve timing
-
-
Phase 3
-
10 throws (possibility with static wave on land)
-
Timing: 1 throw → bomb lands via animation curve timing
-
Weapon Station: Lighting Strike
Mr. Static summons lightning strikes around the Player's radius. Deals serious damage to the player.
-
Phase 1
-
Five strikes
-
Timing: 1 strike → cooldown (2.0f)
-
-
Phase 2
-
Five strikes
-
Timing: 1 strike → cooldown (2.0f)
-
-
Phase 3
-
Five strikes
-
Timing: 5 strikes → cooldown (2.0f)
-
AI Enemy Bots
For the enemy classes, I wanted to create several that the Player would encounter, each with different combat methods. To create a more systemic feel to the game, I implement an Explosive Stimulus to signal that bots (or any object with it) can explode and harm the player.
Player attacking earlier verison of the Explosive Bot
I also implemented the following enemy classes and the spawn rates that appears throughout the boss battle:
-
Explosive Bot
-
Spawn Chance: 50%
-
Combat: has to reach a proximity distance to the player to self-destruct
-
Weakness: can be destroyed with one punch
-
-
Laser Bot
-
Spawn Chance: 20%
-
Combat: fires lasers in 4 directions when the player is within range, while traveling in random directions
-
Weakness: can be destroyed with three punches
-
-
Static Wave Bot
-
Spawn Chance: 5%
-
Combat: charges up a wave bomb once it turns fully yellow
-
Weakness: can be destroyed with five hits to the battery (located in the back of the bot)
-
-
Turret Bot
-
Spawn Chance: 25%
-
Combat: fires projectiles if the player comes within the distance range during
-
Weakness: can be destroyed with one punch
-
Boss Phases
Third Phase:
Phases during the fight change based on the health status of Mr. Static. I designed the boss's health so that phase changes were obvious, and how the weapon stations were powered.
Phase 3 introduces a backup Generator System that shields all the static towers, adding an extra layer for the player to overcome. Players had to destroy the generator to remove the shields during bot encounters, and Mr. Static's weapon usage was still present.
Generator introduced in the third phase of the battle
Feedback:
Following the first playtest, which I hosted with friends and colleagues, here were the results and what happened next:
What Went Well
What Went Wrong
-
With Cannon Wave Bombs and Static Wave Bot Made together, the boss became difficult.
-
To address this, I updated the Cannon Weapon Station and removed the wave bomb mechanic on bomb launches. I replaced the static ball with explosive crates, which produced a cool, cartoon-like bounce before the crates exploded.
-
-
Players thought that respawning the bots was a bug when all the towers were down, and the boss was outside of a weapon station.
-
To address this, I implemented a bark system and bark scriptable objects to convey Mr. Static's states during the fight, keeping the player informed and preventing periods of silence.
-
-
Bug with Turret Bot and Tracking POV on BT Tree
-
To solve this, I implemented a custom decorator for my BT, where FOV became a part of the tree rather than a condition to watch on a separate script.
-
Additional Updates to Iteration:
In the 5th month of this project, and with most mechanics in place. I updated the model and animations for Mr. Static, along with the weapon stations, to move this prototype out of a "testing" phase and into a final look. I brought in my best friend to help deliver VO lines for Mr. Static as he is constantly talking to the player.
By the time December ended, I wrapped up the project, and I was proud to have brought it through despite the design change I made midway through. This is how the final version looked:
CODE SNIPPETS
Bark Controller
Code below contains functionality for how Mr. Static communicates during the boss battle
Takeaways & Lessons
Looking at this project, my first boss battle-focused project, its timeline, and the design pillars, I can say I am quite proud of what I was able to bring in 5 months. I can reflect on the good and bad in terms of how this project changed my perspective going forward, as it brought me to the results below.
Final Verison Gameplay
What went well?
-
Discipline
-
Working on this game for months was ultimately a rewarding and challenging learning experience. Maintaining motivation throughout was instrumental to this result.
-
-
Constant Prototyping & Adapting
-
Working on this project taught me new skills, including Cinemachine, Timelines, and the required plugins.
-
-
Adapting to a New Direction
-
In game design, things are always changing, and sometimes there are things that just don't work out. I learned that after testing this project with the 1st iteration of the boss fight and realizing how unfun and unclear it was, it needed a reroute that required extra time and work. I took it on nonetheless and remained driven by the new (and current) iteration of the fight.
-
What went wrong?
-
Misuse of a Behavior Tree
-
I used the Behavior Tree incorrectly during the first iteration by forcing it to manage random attack selection and transitions. Learning how selectors prioritize from left to right explains why this approach was incorrect.
-
-
Lack of Respect for Time-frame
-
Working on a personal project for 5 months was never my intention. When I started, I set out for a month of development, but I soon realized how ambitious I was, to the point that I didn't honor the deadlines I had set.
-
-
Not playtesting soon enough
-
Given how brutal the feedback was for the 1st iteration after 3 months of development, safe to say not playtesting the game early enough cost me months of work, which I discarded in favor of a new prototype to address issues and change direction, ultimately leading to the scrapping of the 1st prototype in favor of this new one.
-
Special Thanks to:
-
My 2 Best Friends
-
Jumping on the project to help with narrative, scripting, and voice acting.
-
-
Game Industry Mentors
-
Pushed me actually to FINISH a side project.
-
-
Co-workers at Testronic Labs
-
Playtesting the game during their free time.
-
STRONG feedback for the first build of the game.
-