Greetings! I’m Cliff “Riot 1kFeathers” Zhu and I’m here to talk about Mel. If you watched Season 2 of Arcane, you’ll likely remember a scene where a certain backstabbing enforcer has Caitlyn on her knees. As Ambessa watches, Maddie pulls the trigger but… the bullet is reflected. Mel saves Caitlyn’s life, defies her mother, and takes down Maddie, all in one moment.
With this scene in mind, as we were gearing up to bring Mel into the game, we knew her W (Rebuttal) would be a key part of her kit. But as any game designer will tell you, reflection is complicated. We had technical difficulties to overcome, tons of different projectiles the ability needed to interact with, and considerations around balancing, clarity, and damage. I was the Tech Captain on Mel but I’m writing this on behalf of our team (credits at the bottom) as we all worked together to create this ability.
So, if you’re a Mel main, a missile enthusiast, or just interested in the tech behind a reflection ability, this article is for you.
The Start of Reflection
Back in 2022, we knew we were going to work with Fortiche to bring original Arcane characters like Mel and Ambessa into the game when Season 2 of Arcane came out in 2024. At the same time, we knew we wanted to explore a reflection ability so I was chatting with Myles “Riot Emizery” Salholm, the Champion Designer for Mel, about what that could look like.
At that time, we knew Mel was some sort of mage with the power to manipulate missiles and spells. We already had a playable version of an ability that we called “Offensive tech”--the ability to capture a spell for an enemy and throw it back later, think Sylas and his ability to steal an ultimate from an enemy Champion.
But the other side of this coin was “defensive tech,” something we hadn’t done before due to the technical limitations of reflecting missiles in real time. I became very interested in the idea since:
It more closely resembles Mel’s ability in the show
It was a design space that League of Legends had never explored but was a popular part of other games (e.g. Genji’s deflect in Overwatch or Fox’s shine in Super Smash Bros.)
Instant reflection brings a really satisfying kind of skill expression
So I created a prototype of the instant reflection and we playtested it. People liked it, so we decided to move forward with it, even though we knew at that time this was going to be a big undertaking and one of the most complex champion abilities in the game, along the lines of Sylas, Viego, and Neeko.
So, how does it work?
What are Missiles?
To really understand how reflecting a missile works, we need to first know what a missile is. A missile is a medium that moves a spell around. If you happened to have read this article about how the missile system was refactored 10 years ago, you will know that missiles have these key components:
For regular missiles:
Movement: Missiles go places.
Collision: Missiles hit things.
Target tracking: Missiles go towards things that can move.
Script interacting: Missiles need designers to tell them what to do.
Visibility: Missiles get seen by some things but not others.
VFX and sound: Missiles need to be seen and heard.
Thanks to the refactors that componentized everything based on functionality, we can simply tell each component what to do if a missile is to be reflected.
For reflected missiles:
Movement: Clears the current target, and starts moving towards a new target position/unit.
Collision: Instead of colliding with the units on Mel’s team, it should collide with units on the casters’ team since Mel now hijacks the missile.
Target tracking: If the missile was targeting a unit that moves, it should keep targeting a different unit that moves (often times the caster themselves).
Script interacting: Reflected missiles should inherit everything that was specified by the original missile in scripts. So for example, a reflected bubble from Zoe’s E should still make targets drowsy.
Visibility: Similar to collision, we will need to reverse the visibility rules on the reflected missile since it’s now considered on Mel’s team.
VFX and sound: Proper VFX and SFX should be played at the relevant locations for the reflected missiles.
Area Triggers
We also needed something that could interact with missiles upon touching them and turn them back towards the caster. Sounds familiar right?
Yasuo’s Windwall blocks missiles from continuing on their path, essentially looking for missiles in an area and destroying all of them. For missile reflection, we took it to the next level and extended it so that it doesn’t destroy the projectiles, but modifies them and sends them back.
The First Prototype
Now that we understand what missiles are and how to interact with them via area triggers, the stars are all aligned and we’re ready to make our first prototype of the missile reflection system. This is what me from three years ago came up with:
I used Area Trigger to handle missile collision detection + reflection logic.
The OnMissileReflect logic is defined generically in the shape class so we can extend this to any shape as long as it implements the corresponding functions.
I reinitialized the missile VFX so it will restart its lifetime and will be played to the proper orientation.
I used the “Berserk” system (created for Renata Glasc’s ultimate) to handle Mel as the new owner of the spell.
Mel will be credited as the damage dealer of the missile and all of its extended effects (E.g. Zoe’s E is a missile and the bubble is an extended effect). The damage will be calculated according to the stats of the caster.
If you happen to have read Jeff Doering’s Berserk tech blog, you will be familiar with BerserkInstigatorID. In Mel’s case, we are berserking spells instead of the auto attacks that the Chem Baroness took advantage of. We are setting Mel as the BerserkInstigator so that when damage/kill credits are calculated, she is considered the damage dealer and gets all the credits.
Missiles can be divided into two major categories: targeted and non-targeted. Targeted missiles have a fixed target and don't have real collisions (think Annie’s Q). Non-targeted missiles are skillshots that could hit anything on their path or miss entirely (think Ezreal’s Q).
For targeted spells like Catilyn’s R, the reflection will check the caster of the spell and always return the spell to the caster.
For non-targeted spells like Ezreal’s Q, the reflection will return the spell towards the position of the original caster.
Missile Recreation
So we are done, right? Well, not quite. One of the things that the prototype did not handle well were missiles with other movement types, specifically non-linear missiles like Diana’s Q, Yuumi’s Q, and Qiyana’s R. These missiles have complicated movement types we didn’t account for initially:
Qiyana’s R follows the wall.
Yuumi’s Q follows the player's cursor.
Diana’s Q is a spline missile following a smooth curve.
While it is certainly possible to take advantage of inheritance and implement separate functions for these, I took a step back to think about how to create a new missile from the ground up and pass in a target position/unit. Instead of handling the target tracking ourselves, the missile initialization process will automatically figure out how to reflect new missiles.
With that framing in mind, we decided to destroy the incoming missile and recreate a new one based on the information of the incoming missile.
This brings us multiple benefits:
This fixes other movement type missiles, such as spline missiles, as we are recreating the new missile instead of restarting its movement component, so we do not need to implement per-movement type logic.
This resolves a lot of the VFX issues where the reflected missile spawns in incorrect orientations. This will be extra helpful in the long run since we don’t need to worry about VFX bugs depending on their setups. Since every missile is burned to the ashes and spawned from scratch, the solution is highly robust and sustainable.
This unlocks the ability to delay spawning of reflected missiles, which is a lever that helps to balance the ability.
Missile Hijacking
We wanted the reflected damage to scale with AP (magic damage) and be adjustable, so Mel casts the new spell, similar to Sylas. But instead of stealing the entire spell, (including cast animation, mana consumption, etc), she only captures the parts tied to the missile. Any effects triggered by the missile’s travel or impact are inherited by Mel.
This fixes reflecting ally heals and shields, Mel will be casting the heal and shield to allies and additional work will be needed to fix those spells (think Senna’s R, Nami’s W, etc).
This unlocks the ability for the reflector to modify the damage output of the missiles.
This makes the reflector inherit the rest of the missile spell, which solves the Recast Missiles issues (think Lee Sin’s Q, Akali’s E, Vex’s R, etc).
The original caster will not be able to recast because their spell flow ended.
Mel will be able to recast if the spell’s recast conditions are met.
Damage Re-calculations
So up until this point, we used an AreaTrigger to detect missiles, destroy the original missile and then re-create a new missile cast by Mel.
One problem with this setup is that since the new missile is technically cast by Mel, according to the spellcast system (if you’d like to learn more about it, check out the spellcast article on Hwei), Mel’s stats will be used to calculate damage. So imagine level 1 Mel reflecting a level 18 full AD Aphelios auto, the reflected auto is going to tickle since Mel has really low AD. This is not the effect we want to see since, according to design, the stronger the enemy, the stronger her spells should be. So what are we missing?
We needed to use caster’s stats (AD/AP) on spell damage calculations even though Mel was the caster of the spells.
To implement this, we created a dictionary to store reflected skill shots, their corresponding casters, and their level when the spell was reflected. Let’s use everyone’s favorite Yordle Teemo as an example: If Teemo uses E and tries to poison Mel, when the E missile hits the reflection shield, we store the character reference to Teemo himself and Teemo’s level. When the poison flies back to Teemo and starts to hurt him, we check the dictionary and look up Teemo’s level and stats, and use that to figure out how much damage the poison should deal to Teemo.
Side note: Sylas solves this problem differently, using his own stats and converting AD damage ratios into AP damage ratios since he is an AP Assassin. The difference between Sylas Ultimate and Mel’s Rebuttal is that Sylas casts the spells as his own, so it makes sense the spells are based off of his stats. But since Mel is reflecting projectiles back to the original caster, it made sense that the reflected projectiles would inherit the caster's stats instead.
Missile Recoloring
One gameplay risk we knew from the start of development was that reflected abilities would be difficult to identify during a heated team fight. We considered using additive particles to indicate when an ability had been reflected. Instead, we decided that recoloring reflected projectiles would be more noticeable, while also conveying the feeling that Mel has taken control of the missile.
The League of Legends engine could not already arbitrarily recolor objects like this, so we collaborated with Adriana “Riot Mewdini” Solano, an engineer on our engine graphics team, to implement it. I’ll let her take it from here:
Howdy! Riot Mewdini here to break down some of our approaches and challenges from implementing Mel’s recoloring tech.
Our first approach worked by cloning all the reflected projectiles’ materials on the fly and then adding the recoloring macros to those duplicated materials. This approach caused a hitch at the moment of reflection, but it worked well enough as a proof of concept. Soon after, I added support for recoloring ramps, which gave artists the freedom to map the luminance values of the projectile to a color range, giving skin designers much more freedom when creating new skins for Mel.
Another similar approach we implemented created these recoloring-enabled materials for relevant projectiles at load time. The main issue with this approach is it caused our worst-case memory usage to rise to unacceptably high levels. For example, if one of the skins in the game was Elementalist Lux, League’s memory usage would rise by about 35 megabytes. While this number might not sound too high, League’s minimum specification supports systems with 2 gigabytes of RAM. It was clear I needed to try another solution.
We also eventually realized we would like to avoid using ifdef macros in our shaders for this feature, as utilizing those causes twice as many affected shaders to be built and shipped. At first, this did not seem like a big deal, but as the number of shaders needing to support recoloring grew (thanks to several edge cases I will describe later), every particle shader–and an Uber shader that handles minions–would need to have their number of shader variants doubled.
The approach we ended up shipping was much simpler. We simply added recoloring instructions that were always on to the affected shaders. When recoloring should not happen, we pass an alpha value of zero, leaving the original color unchanged.
This approach fixed some bugs we encountered early on, such as Jinx’s mines not getting recolored (because they were secretly being treated as minions). Other bugs would have to be fixed separately, and more bugs would only be discovered later by an extensive QA process. These included:
Recoloring not being inherited by child particles because of abstraction in our proxy particle system (visible in complicated VFX like Renata’s Ultimate).
Aphelios’s turret being reflected would cause a crash when it tried to shoot at Aphelios, due to the turret’s projectile not having access to the color ramp data.
A similar bug with Aurora, whose recalled projectiles would be invisible due to ownership confusion.
Untargeted abilities sometimes causing a division by zero error (thank you, Talon).
Legacy particles not passing down properties known as Keywords, which used to define how particle effects would conditionally apply to different skins. This could be seen with some of Rumble’s original skins.
And many more.
Balancing
Thanks Riot Mewdini! I’m Riot 1kFeathers back again and I’ll take us to the finish line. At this point we solved most of the issues for the missile reflection system and people were getting the taste of their signature spell reflected by Mel in playtests. And, unsurprisingly, they weren’t stoked about that. So we had to address the serious topic: How do we balance this ability?
Riot Emizery requested some levers we could use to parametrize the spell and add different power level outputs. There are two major asks that he brought up:
Ability to adjust the damage/CC of the reflected missiles
This was done simply using a listener event on the reflect logic. Whenever Mel is going to deal damage to a champion using the reflection, we calculate the damage, and then apply a percentage mitigation towards the final damage. In the game, the more you level up the W, the higher the percentage is.
Ability to control the delay of when a missile is headed back to its caster
We added a timer in the missile reflection system. This is not being used in-game currently, but we have ways to control how early the missile flies towards the reflection target.
Future-proofing
Passives
Similar to Sylas’ R, we needed to give Mel context of Champions passives as they are encapsulated in their own object, not part of the spell. Unfortunately, a lot of the spells in League are scripted in a way that assumes that the Champion will always be present. For example, Annie’s Q is scripted in a way that assumes that Annie is always the Champion casting it and thus looks for her passive. However, that wouldn’t work for Mel’s case since Mel will be casting Annie’s Q but does not have Annie’s passive. As a result, we moved a lot of the spells into a shared place so that the dependency on the Champion itself is removed. This leads to better encapsulation of our spell catalog and opens up more possibilities for future Champions, some potentially really interesting game modes, and a bunch of just nice flexibility for the future.
The Future of Hextech
In Hextech, our name for our proprietary engine and tools, we refactored and upgraded a bunch of Champions’ scripts to modern standards of data lookup, stats handling, and damage application, so they can be compatible with the missile reflection system. This sets the game up for success in the long run.
Missile reflection tech opened the door to more possibilities. We now have a way to modify missiles and transfer ownership of missiles/spells.
Credits
Mel has been an incredibly hard project in lots of different aspects. I want to give a shoutout to Myles “Riot Emizery” Salholm, our designer; Peter “Riot The Loki” Simpson, a QA Engineer; and Matteo “Riot Chibattabun” Mannino, the Tech Lead on the Champions Team. Tons of other Riot engineers like Riot Entquine, Luke “Riot Quasmic” Li, Nancy Iskander, Riot ydoj, Riot Crasong, Riot AHoppingBunny also worked really hard on different features for the missile reflection system and fixed various bugs.
