Kenechukwu Umelo
Technical Designer
AI Programmer
Project Mr. Static!
Role: Solo Developer
Duration: August 2025 - December 2025
Genre: Action-Adventure
Engine/Tools:
-
Unity3D/C#
-
Behavior Designer (Behavior Trees)
About:
What started as a solo project to practice AI and boss design evolved into a 5-month project, where I brought in two of my best friends to collaborate and turn it into 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 as well.
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.
Pre-Production and Prototyping Stage
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 three 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.
-
-
Player-Driven Customized Difficulty*
-
With the three types of attacks for the boss, players will be able to turn off any or all attacks during bot encounters to create the kind of challenge they want overall.
-
These pillars were tied to the goal of delivering a boss fight that offers a unique player experience in how they choose to engage Mr. Static. I didn't aim to design something completely new, which is why I mainly looked to 3D platformers for reference on the simplest yet most challenging boss fights in a 3D space.
Ideal Iteration Stage
Player Movement, Camera & Combat
To start off strong, I implemented a player controller 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. For combat, I aimed for a straightforward "left-right" punch, drawing on 3D third-person platformers such as Astro Bot and Ratchet & Clank. With this choice, I was able to control the scope I wanted to maintain, although I did get a little ambitious at times, given the extra player abilities I prototyped that were ultimately cut, as I felt it was bad to introduce too many mechanics with little time in a demo for players to learn.
The trade-off was a Hit Interactable System that triggers a reaction (sound, animation, or VFX) when the player hits an object. The next challenge was to design the boss and enemies to support this.
Basic Movement and Combat for Player alongside Hit Interactable Objects
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 Mr. Static Boss Fight
During the first prototyping stage, I first imagined that it would be more of a "small player vs flying boss". Given how Mr. Static was initially designed as an enemy in spaceship at the time.
1st Iteration of the Boss Battle
I designed this encounter as if it were part of a story mission. It featured several systems to help deliver a proper introduction to the boss, including:
-
The checkpoint system at the start of the game.
-
Opening cutscene created via Unity's Timeline.
-
Static Towers to power Mr. Static's ship
-
Camera system to help keep the player and Mr. Static in view at all times during ground and off-ground sets.
The first iteration focused on a pattern in which players had to take down "Static Towers" to disrupt Mr. Static's ship, after which he would leave himself vulnerable for players to strike. He did come with a barrage of attacks he could unleash randomly. He had two states that helped detect whether he was on or above the ground.
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 tree for the Boss AI in the 4th iteration of assembling the behavior tree.
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
Feedback from Ideal Iteration
Problems from Feedback:
-
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.
-
-
Nothing stops the player from 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 readability and telegraphs 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 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, both technical and design-wise:
-
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
-
To 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
-
This change to the AI architecture for the boss helped me account for transitions between states, each of which holds logic for specific behaviors to execute. No more struggling with executing behaviors based on 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.
-
I spent time actually writing documentation and paper concepts for what I wanted in this new iteration. This led to a design document that outlined the entire flow and phases for this iteration of the Mr. Static boss battle. By the time November 2025 ended, I was able to execute this brand new prototype:
Second Iteration of Boss Fight
Finalized Stage
From Behavior Trees to State Machines:
Working with behavior trees during the first iteration was helpful for learning 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
I had already coded Finite State Machines in past projects, so I immediately began defining their behaviors and states. I aimed to ensure that all behavior logic was set within its own state.
Boss AI Combat:
I updated the boss fight to ensure Mr. Static's combat in a way that kinda mimics a boss fight from Jak 3, where Jak faces off against Errol
In this fight, Errol travels through three distinct stop zones to strike the Jak (Player) with bombs and enemies. The design here, with the boss, is straightforward and introduces tension (via additional wave bombs) and pressure (via platforms that fall after each phase) as it drops.
For Mr. Static, I followed the same formula, except with an even level ground with unique attacks for each stop zone, or in this case, "weapon station". I implemented the following, and how they evolve throughout the phases:
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)
-
Enemy Bot Classes:
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
-
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 from Ideal Iteration
Problems from Feedback:
-
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:
Final Verison Gameplay
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 and 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 changes my perspective going forward
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.
-
-
Learning Behavior Trees
-
Despite moving away from Behavior Trees for Mr. Static, I was pleased to have learned how to assemble a tree of sequenced behaviors that runs dynamically at runtime. More importantly, conducting research on best practices for their use was beneficial to my learning and future projects.
-
-
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?
-
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.
-
Going forward, I don't think I will be returning to this project, as I already feel very much accomplished with this one. I plan to transition to Unreal Engine because I have always wanted to learn it alongside C++, as most of my favorite memorable boss battles I've played were created with it. I will apply the fundamentals of boss design I have gained here to that engine to achieve even better results.
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.
-