Kenechukwu Umelo
Technical Game Designer
Botman vs. Mr Static
Area of Focus: Boss Design
Time of Development: 1 Month
Goals:
-
Understand elements of boss design to create a balance of tension, escalation, and engagement for players.
-
Craft simple and effective combat for the player controller.
-
Mimic a boss encounter mission similar to most third-person platformers.
What started as a very short solo project on the fundamentals of boss design evolved into a 1-month project, in which I aimed to create an engaging boss battle, similar to some of my favorite third-person action and platforming games, such as Jak and Daxter, Astro's Bot, and Ratchet & Clank. I ultimately scripted the boss battle as if it were part of a mission encounter for a third-person platforming game, including phases, enemies, interactables, and even voice acting & barks to bring Mr. Static to life.
Combat Design and 3Cs
To start strong, I played some of my previous third-person action and platformer games, specifically Astro's Bot and Ratchet & Clank Rift Apart, to study their player controls and combat systems in terms of what makes them feel great and addictive at times. Being that Astro's Bot combat relies on a simple two-hit animation, with everything else from objects to enemies having a reaction to being hit, along with how the 3C's are executed in Ratchet & Clank Rift Apart, especially the smooth camera rotation and grounded movement for traversal, helped me come up with a clear goal for what the player controller's 3C design should be focused on: responsiveness and simplicity.
Building Botman's Controller
Character, Camera, Controls:
With a clear goal in mind, I developed a custom third-person controller that features swing punch combat, utilizing Unity's Cinemachine Camera and the latest Input System for support. I kept the implementation straightforward and flexible, allowing for potential expansions in player abilities or power-ups in the future, similar to the approach taken by Astro's Bots. I wanted the controller to have a sandbox feel when traversing and getting into action seamlessly. Thanks to Unity's animator for allowing for generic animation keys to be tweaked, the controller allows the player to swing punches while running or walking at any time.
Player Controller + Hit Interactable Objects
Problem:
This design allowed for experimentation with various potential abilities. At times, I became overly ambitious and complex, which led to the decision to cut some features. I felt it would be unfair to introduce too many abilities in a demo, as this might overwhelm players and contradict my goal of providing a more responsive and simple experience. I needed a way to ensure that combat remained simplistic while preventing players from becoming bored or feeling a sense of repetition.
Solution:
The solution was a Hit Interactable System that triggers a reaction, such as a sound, animation, or visual effects (VFX) when the player strikes an object. This system means that objects can be designed to respond differently when hit by the player, whether they are boxes, explosives, or enemies. Reflecting on how Astro's Bots' combat design allowed players to naturally experiment with hitting objects and observing their reactions, I realized that by implementing this system, I could ensure every object or enemy has unique responses to the player's punches.
In the video above, I showcased this system with simple boxes, levers, and a punching bag to demonstrate the impact of this system in terms of giving a different feel to each object that is struck.
Scrapped Botman Abilities
Pick Up and Throw Mechanic
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 always leveled in a ship.
Suction Blaster Weapon
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.
Boss Battle Design
Having never worked on a boss battle before, I will admit that this was a struggle for me, especially during my first iteration prototype. I envisioned a wide-scaled arena with a more "Eggman from Sonic" style boss battle, where Mr. Static was traversing in a ship powered by static towers for the player to take out, leaving Mr. Static vulnerable and open to opportunities for attacks. I got carried away with implementing attacks and patterns without an idea of how the player would be able to engage (or counter) with any of it.
1st Iteration of the Boss Battle
Following the first playtest, which I hosted with friends and colleagues, here were the results and what happened next:
Problems from Feedback and Solution
Problems:
-
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.
-
Solution:
I went back to the drawing board after 2 weeks and decided to change the direction of this fight. One that focuses more on story and player impact than on innovative boss attacks and mechanics. A couple of actions I took to make this possible:
-
Aimed for a 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.
-
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.
-
Play other existing boss fights and find resources - with most third-person games, they feature tons of boss fights and techniques they use to create engaging and memorable encounters. Better to build or improve upon a good blueprint than to establish a unique one in just a month.
Finding the Core Loop:
Going back, I played several boss fights from my past favorite third-person platforming games to critically analyze those fights for the loop and player actions. I wasn't looking for any melee or hand-to-hand combat bosses, but I was looking for bosses in which players go through a phase to get the boss vulnerable and open for free-will attacks. This brought me to this boss fight that I replayed from Jak 3, where Jak faced Cyber Errol in enclosed skyscraper.
What stood out to me here was the loop with this boss fight, being that Cyber Errol strictly stands on top of the ledge, runs to 1 of 3 spots, then launches attacks from enemies and bomb projectiles. I liked seeing how, even though he doesn't have many attacks, the difficulty spike comes from the intensity of enemies and deadlier versions of his attacks, making the player more aware of their surroundings while avoiding attacks. For the scope and direction of this project, I followed that design and put a heavier focus on how the player interacts with the arena, and changed the difficulty of their boss battle playthrough.
Prototyping the Second Iteration:
In the second iteration, it consisted of a more circular arena with Mr. Static now going into three weapon stations, which are powered by individual static towers that the players take out to disable that weapon station. When players disable all static towers WHILE Mr. Static is in a weapon station, he is thrown immediately to the center of the arena, leaving him vulnerable to attacks (basically, his cooldown state).
Second Prototyped Iteration of Boss Fight
This iteration placed a strong emphasis on utilizing the Hit Interactable System for all gameplay objects. By transitioning to a grounded boss battle format, I aimed to make Mr. Static's behaviors and attacks for the player to grasp and react to more effectively.
These adjustments impacted multiple systems, necessitating updates and new solutions to emerging challenges. A detailed breakdown of these updates is provided below:
Mr. Static's Finite-State Machine
Problem:
When I first prototyped the fight, I was working with behavior trees (thanks to Unity's Behavior Designer Plugin) to help handle attacks and transitions. Except, not being too knowledgeable on how BTs ACTUALLY WORKED, and their common usage at the time, hurt the boss fight and created problems, especially with manager scripts. This helped me understand that some AI systems aren't the right solution for this particular boss fight.
Solution:
I came across a GDC Talk titled "AI Arborist: Proper Cultivation and Care for Your Behavior Trees" In this talk, Bobby Anguelov, a programmer at Valve, advised, "Stop building large monolithic trees with multiple responsibilities" (37:16). He recommended using state machines for boss battles, noting that implementing a state machine within behavior trees could be a "nightmare" due to the challenges associated with poor transitioning. Although I was aware of well-crafted boss fights using behavior trees, I realized that his advice was relevant to my problem, and I made the decision to abandon behavior trees for Finite State Machines for this project.
State Machine Flowchart
With each state having rules of transition from one another, it made the implementation and flow of the boss battle clearer and easier to work with. I had previous experience putting together state machines, so it wasn't hard to wire up and get working with Mr. Static.
Enemy Bots
I created several enemy classes that the player, as Botman, can encounter during the boss fight. These classes utilize a smaller, scalable Finite State Machine, which allows me to define their movement patterns and combat behaviors. In addition to the Hit Interaction System, I also implemented an Explosive Stimulus to enhance the game's systemic feel. This feature signals that bots or any object possessing it can explode, posing a danger to the player and any other objects with the script attached.
Player attacking earlier verison of the Explosive Bot
Here is a quick overview of all the enemy classes:
-
EXPOLSIVE
-
Health: 10
-
Combat: has to reach a proximity distance to the player to self-destruct
-
Weakness: can be destroyed with one punch
-
-
LASER
-
Health: 30
-
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
-
Battery Health: 25
-
Health: 50
-
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
-
Health: 15
-
Combat: fires projectiles if the player comes within the distance range during
-
Weakness: can be destroyed with one punch
-
Problem:
With the stimulus script attached, it created chains of explosions when every bot would be destroyed; however, players did find that the Static Wave's attack (a circular wave) has a very high damage scale, along with issues that enemies get trapped within the Nav Mesh Surfaces due to blocked pathways.
Solution:
I reduced the damage scales for Static Wave Bots and updated the pathing logic by increasing the search time for finding a suitable Nav Mesh Sample point on the available areas of the Nav Mesh Surface. This change creates opportunities for players to engage and allows them to anticipate when the Static Wave Bot is about to launch an attack.
Weapon Station Pods and Generator
Weapon Pods in the battle are stations that Mr. Static uses to attack the player. After each use, he runs in a different one and repeats the same attack that the pod offers. The static towers are linked and color-coded to the corresponding weapon pod that can be taken out, effectively disabling the weapon, which will cause Mr. Static to run to a different one. Here is an outline of how each boss phase increases the intensity:
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 Strikes
Mr. Static summons lightning strikes around the Player's radius. Deals serious damage to the player.
-
Phase 1
-
5 strikes
-
Timing: 1 strike → cooldown (2.0f)
-
-
Phase 2
-
5 strikes
-
Timing: 1 strike → cooldown (2.0f)
-
-
Phase 3
-
5 strikes
-
Timing: 5 strikes → cooldown (2.0f)
-
The phases of the boss battle are scripted to increase the intensity of attacks over time. For the 3rd phase of the fight, I implemented a "generator" game object that adds a shield to weapon stations, adding an extra layer of difficulty for the player, as they have to destroy the towers with before treating the phase normally.
Generator introduced in the third phase of the battle
Problem:
With the addition of players dealing with enemy bots and how I implemented a simple randomization spawn script, BALANCING was rough. For example, during a small playtesting session I held, a player found that dealing with static wave bots while Mr. Static was in at the lighting strike station was super frustrating, especially when the wave and lighting strikes felt they hit at the same time. There were other possible unfair combinations of attacks between bots and weapon stations.
Solution:
I implemented a proper encounter manager, which helped manage not only how many enemies spawn on a nav mesh surface, but also how often they do so. The value numbers are automatically adjusted, given the phase and how often Mr. Static uses a weapon pod, meaning that if he is about to spawn enemies, the system will reference his next station before tweaking the spawn possibility values for each enemy type. Meaning if he goes to the turret station, then you will be less likely to experience turret bots spawning.
This system made the battle much fairer in how enemies are distributed while also providing a potential difficulty spike for players to overcome at times.
Bringing Mr. Static To Life
Mr. Static required a level of communication with the player to help them understand his state machine and incoming attack patterns, as I didn't want players to blindly figure out what was going on and what he was going to do next. I took this as an opportunity to practice up on my technical dialogue and narrative scripting by implementing a bark class, bark system, and dialogue reader to keep the player immersed and informed during the battle.
FUN FACT: He is voiced by one of my best friends.
Early implementation of bark systems and dialogue reader
The implementation was scalable, and with the help of Unity's Scriptable Objects, it enabled the delivery of specific dialogue lines during various events, such as when the player dies, switches to another weapon pod, or spawns enemy bots. The dialogue reader captures and displays the subtitles corresponding to the spoken lines. The implementation was simple, drag and drop towards several reference points on Mr. Static's FSM component. While it isn't a fully automated text-to-speech system, it comes close to achieving that functionality.
Problem:
There were several issues where certain Barks were being cut off or overlapped during gameplay, especially during important parts where Mr. Static was introducing himself, or the cut-off where the scene would refresh after the player's death, before Mr. Static even finished his victory lines.
Solution:
The design approach I took was a bark controller system to help not only manage when barks get called, but also IF they can be called. I needed to factor in what Botman (the player) is doing, as well as what state Mr. Static is in, before allowing him to send a bark. The bark system simply goes through conditional checks with certain barks and checks if they are interruptible, meaning no cut-offs unless the bark scriptable object itself allows it. I also attached events to it to ensure the entire bark audio is played through before anything else, including the scene reload upon the player's death.
Code Samples
Preview of some of my scripts, view more on Github
HitInteractable.cs
Code below contains functionality for how objects react to being hit by the player, along with game feel elements.
BotEncounter.cs
Code below contains functionality for how Mr. Static summons his bots (basically a nav mesh surface position spawner)
BarkController.cs
Code below contains functionality for how Mr. Static communicates during the boss battle
Post Mortum
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 Behavior Trees
-
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.
-
-
Not playtesting soon enough
-
Given how brutal the feedback was for the 1st iteration after 3 weeks of development, safe to say that not playtesting the game early enough cost me time. I discarded previous systems and managers in favor of a new iteration to address issues and change direction.
-
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 Games
-
Playtesting the game during their free time.
-
STRONG feedback for the first build of the game.
-