Introduction & Development Objective
My goal for this piece was to create a culmination of all that I have learned during my education. Through playtesting and feedback, I put my best effort into making this piece not only work for the sake of being a good portfolio piece, but to be a genuinely fun boss battle.
Summary
-
Solo project
-
Development duration: 5 weeks halftime
-
Focus on scripting the Boss mechanics, Readability and Telegraphing
-
All functionality, design and art was made by myself using Unreal Engine 5 and Blender.​
PLAYTHROUGH
FEATURES
Boss Ability Breakdown
Laser
Description
With the boss being a robot, it felt nothing but right having one attack be lasers. It also brings the robots head down to the level of the player, allowing for a natural moment for the player to damage it.
Considering the time it takes the robot to get into position, I wanted to extend the time that Mr. Bonk stayed there. With this in mind, I decided to split this attack up into two — One being a classic "jump rope-like" continuous sweeping attack, the other being a timing focused attack inviting the player to use their Dash ability in combination with the spawned pick-ups.
Video
Sweeping Pattern
At first I experimented with having a random move sweeping pattern. This resulted in a feeling of frustration with the game whenever it happened to turn in an unfortunate moment, many times leading to the player getting hit without a chance of recovery. Setting this fixed pattern turned out much better, as the player sometimes did get hit, but was able to learn how to avoid it in a timely manner - dodging it became satisfying and the player instead feels skillful.
Blueprint
Missiles
Description
Two types of missiles are fired at the player, starting in a seemingly random flight pattern but slowly homing in on the player. A third type of missile is added from the second phase onwards.
​
The flight path uses Splines which makes use of the tangent so that the missile always faces the direction of travel, it also works perfectly in tandem with a timeline to set when the missile should lock on to the player using an event track.
Missiles!
Video
Missile Types
Type 1: Red Skull Missile
The red skull missile explodes on contact – no matter what it touches.
Type 2: Blue Crosshair Missile
The blue crosshair missile can be redirected – should the player dash into the side of it, it will shoot off in the general direction that the player is facing. This allows the player to redirect it back towards the enemy.
Type 3: Orange Timed Missile
The orange timed missile can be turned dormant – should the player dash into the side of it, the missile will shut off, falling onto the ground without exploding. If touched again by the player, it will explode after a short delay. If the boss smashes it, it will explode.
Blueprint
Bonk
Description
Mr. Bonk's signature attack, Bonk, requires the player to dodge a barrage of his metal fists. In the first phase, the attacks are separated enough in time for the player to simply outrun them, but in the later phases, the player needs to make use of their dash to elude them.
Readability proved to need a lot of iterations on this attack.
I made two telegraphing changes to this attack that showed a significant increase in readability.
The first was moving the hands to above the strike point before moving them down. This gave the player a much needed chance to know not only that the attack was imminent, but also roughly in what area the fist was coming down.
The second change was adding ”drop shadows” to the hands, showing precisely in what area the hand would deal damage. This became something of a technical challenge, as I needed the directional light (sun) to stay in roughly the same direction. The solution is simple but effective, two shadow casting, invisible planes without collision simply mimic the X- and Y axis movements of the hands, while keeping their position in Z space.
Video
Blueprints
Faces & Phases
Faces
Initially, Mr. Bonk was only going to change face when changing phases – following the cartoony style I figured it would make him unique. After creating an early draft of the functionality however, I figured why not use it to convey the different abilities as well? The design of the facial expressions themselves may not have a strong connection to the abilities, but playtesting proved it does not take long for players to recognize which face means which ability.
​
The facial change comes with an added effect of giving Mr. Bonk a very unique personality, strengthening his own identity.
Phases
Overview
It's not a proper boss fight without phases. When shaping the initial design for the battle, I wanted the different attacks to be easily scalable in order to allow for changes over the different phases, and I figured out two variables that allow for the simplest modification while having a major impact in feel and difficulty – Speed and amount.
Speed
The bonk attack starts at 1,4 seconds between attacks in the first phase, ending with a staggering 0,8 seconds between attacks in the third. This gives the player an opportunity to learn how the ability works, and challenging the player significantly later on.
​
The laser attack got the same speed treatment, requiring the player to learn its patterns and functionality to be passed in the later phases.​​​
Amount
Changing the speed at which the missiles were travelling felt unnatural, which left amount the logical factor to change. Thus, the boss adds one additional missile for each phase, starting at three missiles in the first phase and ending with five in the last.
​
The first phase of the laser attack starts out quite short, so having it be longer in the later phases also felt like a fun and natural addition.
Behavior Tree
Utilization
Utilizing the behaviour tree, I divided the boss' states, allowing for easy debugging and iteration. While this tree is not using all of the functionality of Unreal Behavior trees, it outshines enum switches effectively with its readability.
​
The boss has three states: Attacking, Stunned and Dead, conveniently dividing the boss functionality by switching between them as the boss interacts with the player.
Video Visualization
Player
Movement
Early on, I decided that I wanted the focus to be on the boss, and not on the player. That meant keeping the player functionality simple and quick to learn, granted the player is thrown straight into the boss battle - something not generally the case.
Yet, I wanted the player to feel they have agency in almost any scenario, thus I needed to give the player something more than just walking around and jumping. The goal then became figuring out how this ability would be used to interact with the boss.
​
I am very happy with the choice of dash, as it is a clear trope, but I could still modify it to fit within the boss fight – it works completely as intended when used regularly, checks upon release if there is a pickup within close proximity of the landing zone. If there is, it will redirect there, which allows for very satisfying moves.
Attack
The dash also covers another large functionality – it allows the player to deal damage to the boss in two different ways. First and foremost, when the player picks up all of the dash reset pickups, they become charged which allows them to dash into the boss, dealing damage.
​
They can also dash into the blue and orange missiles, using the boss' powers against himself. Dashing into the blue missile will redirect it, and if done in the right direction, it will turn straight for Mr. Bonk. Dashing into the orange missile will shut it off, allowing the player to cleverly make the boss hit it with his fists, detonating it instantly.
developlent process
Feedback &
Functionality Iterations
About halfway through the process of making this piece, I started having regular playtests. It gave invaluable insights into both what was working and what was unclear. It's safe to say not a feature in the whole project survived all trials of playtests – everything had weaknesses of various degrees of severity.
​
Some of the changes made as a direct result of the gameplay testing are:
​
-
The Nintendo shadow under the fists, adding a clear indication of where they will strike.
​ -
The fists blinking before striking.
-
The colors of the missiles, now much more clearly showing if they can be interacted with. The orange missile still could use some testing to see if it should also be blue.
-
The player having lights indicating if the dash is ready for use.
-
The power-up color being purple instead of blue to not hide the blue lights from the change above.
-
The player being invulnerable while dashing (invincibility frames).
-
The floor having texture to more easily see where the player is standing.
​​​​​Given more time, there are many features I still would like to see in this boss battle. A selective few things I would like are:
-
Clarify if the player is within range of the boss to be able to dash to deal damage. This would go a long way in making sure the player does not accidentally fall off the platform, which turned out to be a big thief of joy as it made the failure feel unfair.
-
A better indicator of where the player will end up when they dash in regular situations. Simply showing if they will dash to a pickup or out of the range of fists would further make it feel fair when the player takes damage.
-
A bit of UI, most importantly to indicate when the dash is ready to be used.
-
An evolving arena, changing as the battle progresses. This could be part of the arena being destroyed and becomes smaller as a result, or floors of the building being knocked off, revealing fun floors below. The amount of work this would take, however, is much more than I feel is reasonable.
-
Lastly, I would flesh out the victory sequence even more to really cement that the battle is over, and goes well with the silly theme. Things could include a disco ball, a dance floor, confetti and victory text.
Reflections
Looking back at this project, there are areas that, had I been given another opportunity to make something similar, I had done it slightly differently.
-
Considering how useful they turned out to be, I would start play testing even sooner, saving headaches on trying to build and fix things that in the end was not worth keeping anyway.
-
I would put a little bit more time into the pre-production, as I think some issues could have been found before even starting to prototype.
-
While I enjoy being able to say I have made it all by myself, I recognize that few successful games are made by only one person. With that in mind, I could have asked a fellow graphics student to supply me with nicer background pieces, allowing me to create an even better end result at the cost of almost no extra time.
Emil Bokstam Wilhelm
I am part of The Game Assembly’s internship program. As per the agreement between the Games Industry and The Game Assembly, neither student nor company may be in contact with one another regarding internships before April 23rd. Any internship offers can be made on May 5th, at the earliest.