Red Post Collection: Dev Blog on Making a More Human Bots, State of Team Builder, Sunfire Cape VU SOON, and more!

Tonight's red post collection features a brand new dev blog by RoamingNumeral on the recent Bot AI improvements, Lyte with a few comments on the State of Team Builder, a heads up that Sunfire Cape will be getting improved VFX in the near future, and more!

Continue reading for more information!

Recent News

Lots of red posts lately! Check these links to make sure you haven't missed anything:

Dev Blog: Making a More Human Bot

Welcome to another League of Legends dev blog entry. This time we’re taking a step away from the Gameplay team in order to talk about bots, which believe it or not inhabit a fair chunk of game time in League of Legends. We recently deployed a series of changes focused on making them more human-like opponents, and thought you might be interested in some of the stories behind the update.

As always, your feedback would be awesome as we build a better dev blog, but in the meantime let’s find out what goes into building a better, more human, bot! Stepping up to the podium we’ve got Design Analyst RoamingNumeral, one of the brains behind our bot update efforts. Onward!

Pwyff

Why did we update bots?

Bot matches make up a decent chunk of games, even among level 30 players. That’s a lot of hours spent with our robotic friends that we thought could be more engaging.

We surveyed both Coop-vs.-AI and PvP players to find out what they thought about bots. One very clear piece of feedback was a desire for more “human” bots: ones that are less predictable and focus on the same game elements that players do, such as last hitting and nailing their combos. Surprisingly, "tougher" bots was a less frequent response by comparison. Based on this data we set our sights on more-human bots as the overarching goal for this update, especially since such changes will make harder bots more interesting down the line.

Players also said that they thought bots didn’t seem to think about strength and danger the same way most players do. As it turns out, they were right.

Improving threat evaluation

Threat evaluation is our name for the systems that bots use to determine how strong they are and how strong their enemies are. These systems underpin all of the bots’ decisions throughout the game.

Our previous systems used a method that is very common in games, especially first-person shooters. The bot looks at how much damage has recently been received and uses that to determine future threat. In an FPS, this makes a lot of sense. If a bot walks around a corner and takes a bunch of damage, it'll probably keep taking that damage if it hangs around, so it’s best to back off.

League of Legends works a bit differently. If Veigar unloads all of his spells on a bot, and the bot survives, that isn’t the time for the bot to run. That’s the time for the bot to destroy that evil little @$!#!. Veigar has almost no damage potential while all his skills are on cooldown, so why not get a few shots, or maybe a lot of shots, in while he’s vulnerable?

Our new systems try to deal with these scenarios by looking not only at health but also how many spells the bot and any nearby enemies have available. Overall, we’ve seen some clear improvements in bot threat evaluation (much to Veigar’s sadness).

That said, improved threat evaluation isn’t a magic bullet for bots. League of Legends was built to be played by humans, not bots, and that comes with some interesting problems. For example, the game doesn’t really know what a spell is going to do before it’s cast. When Morgana’s Soul Shackles is cast, a script begins to run that constantly checks if anyone has broken the leash. When the spell finishes, the script says “Hey, you! You’re stunned and take damage” to everyone who didn’t break the leash. Before Morgana ulted, the game didn’t actually know that Soul Shackles deals damage and stuns.

Now, that may all sound obvious, but only because humans are able to read tooltips and think through scenarios ahead of time. As a result, the system can afford to figure out what a spell does as it executes. However, this is a huge problem for bots because they can’t read and don’t learn from experience.

Because of this, this update has to use some pretty rough estimation for how much damage champions can do. Bots will continue to sometimes go too hard or run from a fight they could win because they couldn’t perfectly calculate the damage involved…just like players :P

Why we didn’t do jungling and wall jumping

This boils down to one simple fact: bots don’t know where walls are or even what they are (really sucks to be a bot right?).

This is essentially the same challenge as spells: League was built to be played by humans. For a human, it’s obvious why a path is all curvy - there’s a wall in the way! A bot, on the other hand, just follows the autopathing it’s given. It doesn’t know where the wall is exactly or how thick the wall is; it doesn't even know that the obstacle is a wall. It could be a pile of minions. Bots just happily go along the shortest path from point to point provided to them by the pathing system.

Wall jumping with Flash or other abilities is thus extremely difficult for a bot - without knowing how thick a wall is or how to path to a narrow spot, it’s pretty much impossible to automate. A lot of under-the-hood tinkering with our terrain systems would be required to make these behaviors possible in the (far, far) future.

Jungling is a similar story. One of the primary keys to jungling well is choosing routes that are either safe or optimal for reasons other than pure distance. Without additional changes to our pathing and terrain systems we can’t make a jungler bot that would be more than a roaming pile of 300 gold served on a silver platter.

We definitely think both wall jumping and jungling would be awesome behaviors for bots, and in the future we’d like to explore ways to make bots proficient at them. For now though we chose to focus on other behaviors that would help make bots more broadly capable when combating players.

Dodging skill shots

One of the most noticeable differences between players and our previous bots was how they reacted to incoming skill shots. Players will try to dodge skill shots in most situations, but bots would often take incoming skill shots to the face without even flinching. Since this is a fairly non-human behavior, we really wanted to teach bots how to dodge. However, we ran into a pretty significant challenge (bet you can guess!) - just like terrain, bots can’t “see” skill shots.

Luckily for Annie Bot, Riot Case came up with a way to use information already available to bots to help them attempt to dodge skill shots. By keeping track of which way their opponents are facing as well as what skills have recently gone on cooldown, bots can now try to dodge skill shots in some cases.

With this change, bots can now try to dodge skill shots…but it’s certainly not perfect. For instance, Anivia’s Flash Frost doesn’t go on cooldown until it travels full distance or is re-activated, so bots don’t know it’s been cast. Ahri’s Orb of Deception returns, so bots may dodge the orb on the way out but not on the way back. There are other abilities this system can’t quite handle yet, but dodging some skill shots is definitely better than dodging none!

Updating bot combos and builds

Aside from the trickier cases above, there was plenty we could do to humanize bots just by putting in some serious time - in particular, updating spell combos and item builds. Our quality assurance guy, Riot Afic, helped out immensely here with his Diamond-level knowledge, and the updated bots now use much more contemporary combos and build more sensible items.

On a related note, Annie Bot will now Flash-stun-Tibbers. Wear the appropriate undergarments.

More human bots

Unsurprisingly, bots that are trying to track many more variables are quite a bit more computationally intense. Our team’s engineers, RiotAaronMike and RiotWooTang, did a great job optimizing our code so we could ship this update without affecting server load.

A good opportunity for making bots both more efficient and more human-like was to contextually slow down how often they scan the environment and react. Beginner bots now scan at roughly one third the frequency they used to, while Intermediate bots scan anywhere from 50% to 100% as often depending on how threatened they are. None of these settings are what we would call “slow”, but they aren’t quite as fast as they used to be, which helps take a bit of the edge off those unrealistic super-human reactions.

These changes, and a plethora of additional under the-hood changes, have created what we feel are more human-like bots. They’re certainly not Diamond-level (probably not even Silver) - but for now that’s not what we were trying to do. Our next steps are to look for ways to build on the new bots and better tailor a Co-op vs. AI experience for players’ first few games. Look for more information on this next project soon!

"We've made a bunch of under-the-hood improvements to bots with the overall goal of making them more human-like opponents. For example, bots will now factor in whether or not their opponents' spells are on cooldown when assessing threat, and the same information will also allow them to (sometimes) dodge skill shots.

Click here if you'd like to know more about the goals and tech behind these changes.

Improved evaluation of enemy and friendly strength.

Improved understanding of tower mechanics and power.

Improved behaviors while under high threat.

Improved lane rotation decision making.

Improved last hitting with auto-attacks both when farming normally and when pushing.

Lane behaviors (harassing vs. farming, etc) are now more in line with human behaviors.

Bots now attempt to dodge some skill shots.

Beginner bots now build recommended items, while Intermediate bots now make more advanced item choices.

Bots now scan their surroundings at variable rates depending on difficulty setting and in-game threat level."

RoamingNumeral also popped up on the community beta to discuss the dev blog a bit!

When asked about changes that allow bots to hop over walls, he commented:

"This would be a solid start to a wall-jumping system.

The sheer number of coordinates that would be relevant is a bit scary, especially since it would depend on what ability you were trying to use. That said, this would get bots jumping over walls in at least some cases.

The hard part comes when you're trying to decide if it's a good idea to make the jump. If a player decides to jump a wall, they often then make clever decisions about an alternate escape route. Figuring out those escape routes and which are safe vs. not is pretty much the same problem space as getting jungling bots up and running. Once you're in the jungle, pathing becomes much, much more complicated. Shortest paths are often not best, whether to run away or try to join up with friendly champions...the list goes much longer and with each one the potential for derpy plays gets bigger and bigger.

Players are able to learn these decisions over many games, and eventually build mental check-lists that make reasonable decisions. Emulating this for bots is very challenging, so we decided to focus on places where we could get more done more quickly."

"This is a good summary of the initial work we'd need to do to get jungling going, but it's not the end of the story.

Humans are good at playing mind games, learning patterns and deciding how to adapt. Adapting to enemy team play is extremely important for a jungler, and that's very challenging for bots.

For example, if we scripted that bots should do Blue->Wolves->Red->Wraiths etc, collapsing on that bot on their way to Red is very easy; a player would learn from this, making a bot learn this is very challenging.

Another example: if bots gank extended lanes, setting traps etc becomes very easy. Again, players would learn, but bots would have trouble.

Because of this, a jungler bot would be super fun for a few games while players figured out the patterns, but after that the predictability would be a bit of a buzz kill.

It is POSSIBLE to create jungle bots that are compelling and adaptable, but as you pointed out, it's a lot of (very fun) work. We had to make a call where to focus, and we decided to focus on solid behaviors in broader areas. That said, the team has had many conversations about wishing for jungle bots :P."

State of Team Builder

Lyte swung by reddit to drop off a few comments on the current status of Team Builder, saying:

"It's a pretty common misunderstanding that if everyone played Team Builder, queue times wouldn't be an issue.

Queue times are a complex beast, that are impacted by a great variety of things. Although number of players playing Team Builder can impact queue times, most servers have enough players playing Team Builder that having even more players would be a negligible improvement. Right now, up to 95% of players tend to have queue times of just a few minutes (regardless of being a Captain or Solo), but there are pockets of time and pockets of players that struggle to get games in Team Builder.
The actual reason behind queue time issues are two fold: - One, sometimes there are too many Captains looking for players to fill their teams, and not enough Solos to actually fill those teams. - Two, right now, high (and low) MMR players are having trouble finding games because they have to wait 15 minutes or more to get into games--this is actually a problem that's always existed in Normal and Ranked modes, but is more evident in Team Builder.

The above problems can interact and be exacerbated by things like off-peak time ranges, other featured game modes like URF being popular for a period of time, etc.

We're actively working on a few features to improve queue times, and agree queue times are the #1 problem in Team Builder today (followed closely by match quality as the #2 problem). For example, we're working on a way for Solo players to see what roles are currently in demand, so they can easily fill for teams. We're also working on adding a matchmaking fix for high/low MMR players that should drastically reduce their queue times.

Finally, we're also working on a feature where Team Builder suggests players to be a Captain or Solo depending on what's currently more in demand from a system perspective.

I hope you give Team Builder some time and stick around to try out the changes--we brought the system up fairly early after beta because the majority of players are having fun with the system, but that means there will be a few bumps in the road as we smooth out and improve the experience."

As for more menu options once you've started Team Builder, he commented:

"We're definitely aware that it sucks to "go backwards" in Team Builder right now. Whether it's inviting a friend that just logged on, or swapping options you are searching for during a Team Builder lobby, it's not ideal.

There's a lot of complexity to the system to change it mid-flight, but we're thinking about it and seeing if there's any easy wins we can pull off."

When asked about the lack of certain roles playing into queue times, Lyte commented:

"Role distribution isn't the main problem with Team Builder. Most "Mid" players only have queue times of a few minutes, and in fact, Jungle is the least played role and yet isn't the role most teams are waiting for.

We're finding that a large chunk of the problem is due to high/low MMR players having trouble matching onto teams in Team Builder, and some issues with Captain-to-Solo ratios--sometimes, we have too many Captains looking for Solos."

[ Soon ] Sunfire Cape VU

Earlier today Rayven posted an announcement regarding upcoming updates to Sunfire Cape's VFX . Unfortunately, it was quickly taken down but Rayven did commenton it's removal over on reddit:

"Hey folks, we jumped the gun. Our bad on the PBE timing.
This is still happening for all the reasons, but not today. Stay tuned!"

For reference, here was the NOW REMOVED announcement:

"Hey folks, we are revisiting some of our item effects to increase quality and clarify gameplay. First up is the old cape of suns (Sunfire Cape).

As you probably know, Sunfire Cape is an AoE damage aura item, but its current effect looks more like a DoT - similar to Ignite. This rework more clearly aligns Sunfire's visual with its gameplay through a pulsing aoe fire aura.

Try it for yourself in game!"

Kassadin: Burst & Sustained Builds

In response to feedback on current Kassadin PBE changes that have an increase on his W base damage and Ratio, Statikk chatted a bit aboutKassadin's damage post rework and the his roles based on itemization:

"Quote:

As much as I do appreciate buffs to Kassadin (good lord he needs them), buffing the damage on his W is just gonna add to his bursty spell rotation, not his sustained damage. He still won't have anything to do after the rotation is done, and won't be rewarded for getting in close in a healthy way.

The problems that plagued him before the rework will persist, and he will be forced into a UP state because balance wise because of the burst you are going to give his kit again.

Why not add damage to the passive on W, and make it scale? Seriously, it's kinda ridiculous that the passive has a BASE BONUS OF 20 THAT DOESN'T SCALE AND A .1 AP RATIO. It's inconsequential, and seems like a not very well thought out afterthought to his kit. He is just not incentivized to use it effectively, due to it's low impact.

Why not give him a reason to invest in items like Nashors and LB?

You have a chance to genuinely make a cool, AP based MADC/bruiser that counters mages... why are you turning him into a spell-rotation reliant burster like he was before?

Hey Slovakattack,

You certainly bring up legitimate concerns with the buffs.

I don't think that I agree with the fact that giving him substantial burst will make him an unhealthy champion, as long as he has to close into melee to achieve its full potential (even for just a second or 2). Removing the Silence has given us a lot of room to move now that his opponents are not completely locked out of reacting to him.

At the end of the day, Kassadin's burst is still not top-of-the-line in comparison to other assassins / mages, his base damages are among the lowest in class and his AP ratios are sizeable but not insane. A mobile, high burst, but squishy Kassadin with a hit and run combat style is something I believe is core to many Kassadin players. The buff to the W is simply to make it compare more favorably relative to Q / E and give him more reward when he arrives at his target.

We ran into some difficulties when creating a sustained damage Kassadin combat style, primarily due to the Mana itemization that exists in the game. Mana items are inherently very tanky, specifically they have a ton of easy access to Armor. Combine this with the focus we want to put on anti-magic in Kassadin's kit, this becomes a bit problematic because he often quickly becomes extremely resilient to both magic (built into his kit) and physical (Mana itemization) damage. Whenever we give a champion both Tankiness and Mobility, they need to have some pretty severe tradeoffs elsewhere on the kit or they become overbearing to play against. For Kassadin, he has to make real tradeoffs between Tankiness and Damage which is something we need to preserve.

Ultimately, I'd love for both Burst damage Kassadin and Sustained damage Kassadin to have places in the game, but to do so we would need to ensure each has its own strengths and drawbacks. With the current Mana itemization in place, I don't think it's plausible to make a sustained Melee DPS version healthy for the game. Currently, Kassadin can opt-in to a riskier AP focused build where he has significant damage and mobility but is ultimately very squishy, or a Mana-Tank build which is tankier and more controlling at the cost of damage output.