Between the Lanes: Unbreaking A Bomb
Introducing Between the Lanes, a new blog feature where we let members of our development team walk through some of the challenges, bugfixes, and occasional happy accidents we encounter while working on a game as unique as Dota.Every Dota update gives us a chance to introduce new heroes, items, and abilities into the game — not to mention tweak countless old ones. This keeps Dota evolving as a game, but it also introduces an incalculable number of potential interactions. While this means there’s always something new to experience in every match, it also increases the likelihood that some of our changes introduce the occasional bug or two. Or twenty.
Fortunately, the Dota community is constantly experimenting and exploring, and is quick to discover hidden advantages, new meta, and outright game-breaking bugs that catch even us by surprise.
The Techies’ Sticky Bomb bug is a perfect example of this. The roots of the bug were introduced as far back as the Techies update last year, when we unveiled a rework of their abilities and playstyle. This rework created a bug where Techies’ Sticky Bombs didn't expire, and in some cases became controllable by the casting player. But interestingly, because of the parameters of the game at the time, there were no circumstances where the bug could actually occur in a match. So it laid dormant until the Twin Gates appeared with The New Frontiers 7.33 Update this past spring.
Suddenly, Techies players were able to create guided Sticky Bombs they could move around the map, raining down unlimited lethal explosives on enemy players. This was... a bit of an advantage. So it wasn't long before we started hearing rumblings on our github.
A common pattern in gameplay programming generally, and especially in Dota, is to create something new (that doesn’t break the game) by finding something similar that already exists (and works and is not game-breaking) and using it as a starting point to evolve changes. Sticky Bombs were based on the classic Techies’ Remote Mines. They’re implemented as a summon of a "npc_dota_techies_remote_mine" — the same base NPC type as the old Remote Mine NPC.
Techies’ Sticky Bombs utilize a “toss”/”chase”/”countdown to explode” sequence that is managed by a series of server-side modifiers (buffs) on the NPC to handle the unit motion and behavior of each step in the sequence. The "chase" and "countdown" modifiers prevented player orders via state flags in the modifier itself. The "toss" modifier prevented many types of player commands as a result of being a motion controller, along with the nature of the npc_dota_techies_remote_mine itself (specifically, that the NPC has AttackCapability DOTA_UNIT_CAP_NO_ATTACK).
Because Remote Mines could be manually detonated by Techies using an ability on the mine itself, the Remote Mine NPC was permitted to use abilities. This means it was flagged as both owned by the casting player (for kill credit) and as controllable by the casting player. Right-clicking on a Twin Gate (or any channelable map entity) mechanically functions by converting an attack click into an ability cast on the channel target (you're "casting" on the Twin Gate while channeling). Other map entities require a hero to do the channeling. However, because Roshan can use the Twin Gates, non-hero units are permitted to channel them.
Which brings us to the Sticky Bomb bug: during the very short duration that a Sticky Bomb is in the air after being tossed, if a player clicked on a Twin Gate with both Techies and the Bomb selected with unified unit orders, the Bomb would also channel the Twin Gate. This put the Sticky Bomb in a channeling state that ended the “toss” and broke the sequence of modifiers, resulting in unintended behavior.
The solution, once all this was understood, was pretty simple. The Sticky Bomb does not ever need to be controllable by the casting player. Removing this flag from the Bomb meant that the expected sequence of modifiers always executed as they were supposed to, leading to an eventual detonation.
As with so many bugs, 99% of the time spent fixing it is usually in trying to track it down. The actual solution usually boils down to changing a single line of code — possibly the same line of code you wrote to fix a previous bug. (This is why it’s often said that debugging code is like trying to solve a murder where you’re both the murderer and the detective.)
So: That’s how the Sticky Bomb bug was accidentally brought into existence; the brief chaos it created; and how it was brought to our attention by the community and fixed. What happens next? Well, now we sit and wait to discover whatever new bug we created by deleting that line of code to fix the original bug. If you stumble on it, we’ll see you over on GitHub.
