Today's red post collection includes a new edition of Ask Riot, a reminder that Definitely Not Dominion will be available in the Rotating Game Mode Queue on Friday, Meddler with context on a few of the recent PBE changes, Reav3 discussing skin splash art updates, an engineering dev blog on the software architecture of the League Client update, Taliyah's price reduction, and more!
- Red Post Collection: May Bundles & 2 for 1 Rune Pages, Taliyah Buffs to Live, Merch Store Hoodie Promotion, & more
- 5/25 PBE Update: Taliyah Balance changes & more
- Champion and Skin Sale 5/27 - 5/30
- Super Galaxy Fizz, Kindred, and Shyvana now available!
Table of Contents
- Let’s talk Smurfs, Snow, and Bans in Ask Riot
- RGMQ - Definitely Not Dominion on Friday & Updated Schedule
- Meddler Grab Bag
- Reav3 on updated Skin Splash Arts
- Deep Dive: The Architecture of the League Client Update
- Taliyah Price Reduction
Let’s talk Smurfs, Snow, and Bans in Ask Riot
The second edition of ASK RIOT is out, including discussion on smurf accounts, champion select bans, and Summoner's Rift map skins
"Welcome to Ask Riot.
This is a space where we focus on your questions and give you answers.
You’ll find three existing questions and answers below and can expect to find new questions answered each week. Please feel free to hit us up in the comments. Each of the Rioters who answered will do their best to engage in a conversation with you. We want this to feel like it’s offering a deeper insight into our work.
Have a question (or two) yourself? Go to ask.leagueoflegends.com and sign into your League account. Read the Do’s and Don’ts and then ask us something. We’ll be adding a repository of the answers to the web once we’ve accumulated a few of them.
We’re committed to reading every question but can’t guarantee we’ll answer every one. Why not?
Some questions will be answered elsewhere or won’t be right for this space. (We won’t be launching new products here or taking away from existing conversations.) Even if your question isn’t the one being answered, we’re listening and we’ll be sharing with the Rioters who are working directly on the things you’re curious about.
(This week’s version features questions taken from existing player conversations on the web.)
Is smurfing okay? Why don’t you have better solutions in place for this?
(Note: This question generated a lot of interesting internal dialogue. So we wanted to include two Rioters in an edited conversation for this question, to highlight that we don’t always have all the answers.)
It’s complicated.
WookieeCookie: We don’t endorse smurfing, but tackling it is a very difficult issue because of our player population size and the ease of account creation. We agree that smurfing can really ruin the game, such as when a smurf stomps lower-tier players. However; from past attempts we've learned that it's a real uphill battle to create powerful restrictions on alt-accounts without inadvertently affecting the majority of our players who don't smurf at all.
Instead of cumbersome systems to blanket restrict smurfing we're looking for targeted answers that attack specific pain points. For example, if we find a player is using a smurf to actively hurt the game and other players we’ll take direct action on that account, and in some cases their main account as well.
Ghostcrawler: Sometimes players are smurfing because they are trying to accomplish something that League isn’t offering - in other words, the need is unmet. For example, playing with a friend with a different skill set is a noble pursuit that League doesn’t support very well. Other players might make a smurf account because they want a sense of rapid progression that they experienced when leveling from 1-30 or maybe even climbing through Bronze and Silver.
So we should be careful not to paint all smurfs with broad strokes and assume that they are trying to grief actual new players. They may have other intentions. That said, taken on the whole, I’m not a fan of smurfing and worry the potential harm to other players outweighs the benefits to those players with unmet needs.
WookieeCookie: Agreed! That’s why we can’t endorse it. Instead of trying to restrict or prevent smurfs, various teams across Riot try to minimize issues caused by smurfing. For example, one of the teams that works on meta-game systems developed pretty good detection methods that quickly separate new players from experienced smurf accounts in the early levels. Within a few matches, smurf accounts only end up playing against other smurf accounts.
Since we are having more and more champions, are we thinking to redesign the amount of bans in champ select?
We don’t think the number of bans needs to scale linearly with the number of champions. If you take that to an absurd conclusion, we might end up with so many bans that champion select gets really bogged down.
If we increased bans, it would be because we thought we could promote team diversity or produce some more interesting comps. Player agency is an important part of the "how many bans?" discussion. Too few bans and you can't deal with frustrating champions. Too many bans, and you might never get to play the champions you want to play.
One idea that we're beating around internally is whether one ban per player (meaning 5 per team or 10 total) makes sense. That increases ban number slightly, but more importantly, it gives everyone a chance to make a choice about who they don't want to see on the opposing team. We have no idea when or if we would make this change - we’re just trying to give you a glimpse into how we are thinking about the issue.
(BONUS ANSWER!) Reading between the lines, there seems to be concern about how many champions LoL can support. There probably is a finite number, but at the rate we release new champions these days, it will be many years before we really have to worry about having too many. - Ghostcrawler
Why don’t we get a winter-themed Summoner’s Rift skin for Snowdown anymore?
One of the outcomes of the Summoner’s Rift Update was a need to completely rehaul how we would reskin the map. When updating Summoner's Rift, we wanted to deliver a unique, timeless art style that remains relatable years after its creation. We also wanted to do all of this while increasing the visual quality, gameplay clarity and thematic cohesion AND while still running the same or better on our min spec. This was quite a challenge and required developing Summoner's Rift in a totally unique way. We took the talents available on our team and decided to take a hand-painted approach. This means every pixel on the map is unique, no shared textures, no programmatic lighting, no tiling. We achieved stylistic lighting and gorgeous textures, without the performance cost, in a way that won't degrade over time as technology improves. We essentially created a giant painting and overlayed that on the rift.
So what does this mean for a winter-themed map? The con of our approach to building SR is that making any changes or modifications to it requires significant work. It's like trying add snow to a summer landscape painting – it's impossible – you have to repaint the whole thing from scratch. These changes also mean we have to repatch data over multiple patch cycles, causing pain for those of you who have data caps and extra costs, which add another layer of complications with changes to the new map. I’m sure some of you have seen the winter-themed custom map skins made by some players and have asked, if they can do it, why can’t Riot? Most of these maps are made by running a programmatic filter across all of the textures and simply put, we want players to feel like the map is of the highest quality. . It would be like slapping some snow on top of Orianna and calling her Winter Wonder Orianna. That may have been fine 5 years ago, but nowadays we consider the things I mentioned above; gameplay clarity, thematic cohesion, and visual quality, which means it’s not a simple undertaking.
Does that mean we'll never have a winter-themed skin? No, not at all, just that we have to invest in updating the rendering technology on LoL before we can deliver features like Map Skins without risking game stability. It's a lot of work and needs to be prioritized against the other opportunities we have, such as Rotating Game Modes that offer alternative game modes not just changes to the map, but doing that will allow us to create a sustainable pipeline to deliver content like winter SR and more ;) – Riot JxE
Here are a few links that touch on our approach to the Update to Summoner's Rift if you want more info:
http://na.leagueoflegends.com/en/news/game-updates/features/dev-blog-defining-rifts-visual-style
http://na.leagueoflegends.com/en/news/game-updates/gameplay/dev-blog-optimizing-rift"Be sure to submit your questions at [https://ask.leagueoflegends.com/hc/en-us/requests/new]!
RGMQ - Definitely Not Dominion on Friday & Updated Schedule
The updated rotating game mode schedule is also out! Following DND this weekend, we have Legend of the Poro King coming up June 3rd - 5th, Hexakill: Twisted Treeline from June 10th through 12th, and One for All returning June 17th through 19th!
"From the original clone-tastic One For All to the sand-strewn battlefield of Ascension, featured game modes provide unique spins on the classic League formula. It’s time to kick things off with the next game mode in the rotation: Definitely Not Dominion is now live!
Welcome to the newest mode to join the rotating roster.
We've given the old Dominion some fairly heavy surgery. Originally designed to be a long-term engagement experience as a permanent queue, we've shifted into a short-term experience more befitting a rotating game mode. While this isn't the same as original Dominion (definitely not), it still holds the essence of 'capture and hold' gameplay Dominion was iconic for, but with a lot more punch! Let's get into the new stuff.
Changed map:
We've removed the bottom two towers from play, making a total of 3 capture points around the map. Relegating two players to an eternal 1v1 while a 4v4 kinda happens across the rest of the map wasn't working. We sealed a wedge along the bottom behind walls and a fountain-style laser will zap you if you go near those points. This means each team will ALWAYS hold at least 1 point for minion spawning. The new map layout looks something like this:
Storm Altar:
The center Storm Runes have been replaced with an altar you can capture for a temporary combat buff. The Nimbus Storm buff gives you 3 charges that do 4/5/6% max HP true damage on any spell or attack. While controlling the altar, all allied team members also generate a free charge of the Storm Nimbus every 4 sec while in combat. Great for siege breaking and uprooting enemy teams that are dug-in on a point.
Ultra Minion Relics:
Near the sealed bottom two points are two Ultra Minion Relics, one for each team. Capturing the enemy team's Ultra Minion Relic will summon an Ultra Minion for your team in the next minion wave. These are serious minions. They capture much faster than any 1 champion, definitely deal out punishment and are extremely tanky.
Backdooring to capture these still feels good if successful, but the defending team doesn't need to go through the “chore” of “recapping” anything now. These Ultra Minion relics are capture and forget, respawning again a short time later.
Trinket change:
All players now have a Seer Stone trinket which provides a short range burst of vision. On the Crystal Scar with so many bushes and face-checks, this can be very handy for scouting Ultra Minion relics or staying safe as a squishier champions.
Minion spawn & pathing changes:
Minions used to disappear after capturing a point and it could feel really bad to spend your time pushing a big wave up to a point for capture, only to have it disappear afterwards and not continue on. Minions now spawn from ONLY the bottom 2 points, and walk clockwise or anti-clockwise respectively around the map. If they capture a point, they will KEEP ON GOING to the next point. This tug-of-war wave style for minions feels more satisfying for wave pushers and captures.
As in any rotating queue game mode, we’ve specially tuned Champion Mastery so you can earn points in the mode. You’ll also be able to earn keys for your wins and loot chests for your (or your premade’s) S-, S, and S+ games.
Definitely Not Dominion is now available and lasts through the evening on Sunday (we’ll shut it down very early Monday morning--usually between 1:00 AM and 3:00 AM).
We’ll be trying out different things with the rotating game mode queue over the next few months, such as potentially turning it on longer depending on how popular it is, changing the mode cadence or what modes are available. We’re looking for your feedback as we go, so let us know. GLHF!"
Meddler Grab Bag
Next up we have a set of responses from Meddler on various topics, including context on Zed and Azir PBE nerfs, thoughts on post rework Cassiopeia and PBE Vel'Koz changes!
"Zed: We've pulled the ult nerf from patch 6.11 after a lot of debate on the team as to how hard the Q changes will or won't hit Zed. Still sitting on it as an option for a later patch, we want to assess what impact those other changes have first though.
Azir: One of the issues we're looking to address with the reduced duration on Azir's ult is how hard it shuts down melee, fighters in particular who can't just disengage from the fight for a while. 5/6/7 seconds is a really long time to wait in a team fight for it to go down, meaning Azir's presence makes it really hard to play many melee champions usefully unless they've got really high slipperiness (leave fight then return), a way to cross his wall (blink or flanking ability) or really long fight times (tanky, or great with a tanky build). The other issue is just the raw power of the ability, as both a strong AOE knockback and a persistent wall. The knockback generates a lot of interesting plays/counterplays. We concluded as a result that, given we felt we needed to take power out of the ability, it was better to hit the persistent wall, which tied in well with the above concerns on effect on melee champs.
In terms of overall power both Zed and Azir are too strong. Azir's particularly out of line when played by a really experienced Azir player (experienced players should perform much better, there's still a limit though). I suspect we'll have to hit both of them again at some point in the next few patches, that's a personal guess though rather than currently planned work. We'll see how these changes go first. "
"Quote:
I know riot put of a survey recently asking if she is unique. I just want to know if riot thinks she is in a good spot now?
Still evaluating. Initial feedback was extremely power focused, which was very understandable given how weak she was. That's delayed our ability to see how the mechanics changes (giving her the Grounded effect, decoupling E CD from poison state etc) affect her playstyle and game health.
Regarding the survey that's something we run for every new champion and champion update after they get released, plus we'll occasionally gather sentiment on the rest of the champion roster as well."Meddler also replied to someone asking if Yasuo could use his R while he is grounded from Cassiopeia's W:
"If Yasuo is standing in Cass's W then he won't be able to activate his ult, even if an ally of his knocks up a nearby enemy champion. Cass W works the same way as a root, so any spell that can't be cast while rooted should also be blocked by Miasma."
"We concluded the changes weren't, overall, delivering a better kit as hoped. We're looking at putting some degree of passive stacking contribution back on the ult as a result to try and address that.
As a side note trying to have a conversation about possible reversions like this can feel pretty unproductive if the dialogue starts off with phrases like "looks to me like you guys have no idea what the hell you're doing". We'll definitely be wrong sometimes and certainly think it's extremely appropriate for you folks to call us out on that if you think that's the case, whether or not we agree. Being able to talk about what issues there are/aren't, why we might or might not revert changes/do other follow up work etc, is, I think, really valuable. Conversations that feel like they're trying to call out failure for the sake of calling people bad, rather than talking about actual problems with changes or the process behind them, can be pretty off putting by contrast."
Reav3 on updated Skin Splash Arts
Following Trundle in patch 6.9 and Tristana in patch 6.10. patch 6.11 will include five updated Nidalee skin splash arts!
"Didn't make them, just the producer on them. Most were done by different artist with the exception of Snow Bunny and Pharoah which were mostly worked on by the same artist. Pharoah was started by one artist but finished by the same artist that did Snow Bunny."When asked about updated Sion's splashes, Reav3 noted:
"Yup, We have actually started early work on Sion splashes."
[Ququroon also confirmed Sion's splash set should be next over on twitter.]
As for when the next set will be released, Reav3 commented:
"Quote:
Do you know when twitch splashes will be updated? After Ryze and Yorick I'd think but any eta?It's hard to say when these will be released as they are lower priority then anything else Champion Update is making. For example, we wanted to get these out before Taric, but we weren't quite there and had to put them on hold to get Taric and the Mage Update out, then when that settled down we got back to the Trundle/Trist/Nidalee splashes. We are currently focused on Ryze and all his splashes though we have started really early ideation on Sion Splashes. Sion and Twitch's will for sure be after Ryze but I can't say how long after. The good thing is that Yorick has very few skins so that should give us a bit of bandwidth after Ryze. Warwick has A LOT of skins as well though so there will be a point we have to start to focus on that.
There are also a few more 1 off splashes that we have at 70-90% complete that we didn't get to in the last round of random 1 offs (Olaf, PAX sivir for example) So I would to expect to see a few more random 1 offs here and there too."
When asked if Karma has new splashes in the works, Reav3 commented:
"Karma is currently on the list but not next on the list, sorry."[For reference, here's a list of the champions Reav3 previously mentioned as being up for new skin splash arts after not receiving them during their champion updates: "Nidalee, Trundle, Tristana, Sion, Miss Fortune, Alistar, Kassadin, Gangplank, Twitch, Fiora, Karthas, Maokai, Karma, Garen, Morgana, Sivir, Sona, Annie, Renekton, Nasus & Heimerdinger"]
Deep Dive: The Architecture of the League Client Update
Here's Andrew McVeigh with a Riot Engineering Dev blog on the software architecture for the upcoming League Client Update, which recently went into alpha!
"Greetings! My name is Andrew McVeigh, and I'm a software architect at Riot.
We're in the latter stages of re-engineering the League of Legends client. We're calling this the League client update. In this post, I’ll outline the software architecture of this update and provide some background to the choices we made by pointing out some of the limitations of the current (original) client. The journey to our final architecture has been technically fascinating, and I’m excited to be able to share it with you!
WHY REPLACE THE CLIENT?
We built our client in 2008 on a front-end technology called Adobe AIR, which uses an RTMP session-based networking protocol to talk to our servers. This platform served us well: it offered a rich multi-media runtime with animation and effects that just weren’t possible with HTML at the time. Additionally, it was cross platform and made building screens easy for a team that was light on artists and designers.
Fast forward seven years to 2015 and three particular issues with the AIR client have become very stark. These are the issues that our new architecture solves for, amongst other things.
Issue #1 - HTML5 is a standardized, widely adopted platform
Pure HTML5 and JavaScript have become viable desktop client technologies. This brings many advantages including standardized workflows and development tools, along with a large pool of talented developers. We really want to fully harness this platform and the media integrations it allows.
Issue #2 - Players want to stay connected in and out of game
You wouldn’t want to leave the AIR client running constantly due to its high resource usage even when it is in the background, yet expectations around online connectedness have radically changed in the last few years. Players want to be connected to their friends in and out of game—no one should miss a game invite just because they aren’t currently in front of their PC with the client open (something we're also working to solve with our mobile app).
Issue #3 - Riot dev teams want to work in harmony
League (and also Riot) has grown hugely since 2008 and we could never have guessed that we’d end up with so many teams wanting to add so many features to the client. The original codebase was structured around a small, highly cohesive team and didn’t give the required level of autonomy and independence as the number of features teams grew.
This problem of dev teams colliding with each other wasn’t going away—it was getting worse over time as we added new features. In addition, we aspire to be a multi-game studio, which brings many other challenges and opportunities.
INCREMENTING TOWARDS AN AWESOME ARCHITECTURE
There are a number of ways to solve for the above issues—for instance, we spent some serious time reorganizing the existing AIR code with the intention of staying on the (outdated) AIR browser. However, while exploring this option in depth, we realized that we could solve the above issues in a more powerful and sustainable way by changing our platform. We decided to do this despite being completely aware of the dangers of rewrites, because we believe the benefits to the player will outweigh the risks in the long-run.
As such, we chose to start again and build around Chromium Embedded Framework (CEF) as our front-end. This gives us a super strong HTML5 browser component that we can easily customize.
Let me now explain how we found our way to our final architecture.
Step A: JavaScript is the king of the world!
Our initial idea was to do all the work in JavaScript.
Since we were planning on building the UI using HTML and JavaScript, initially we felt that putting all the business and communications logic in JavaScript also would simplify the architecture and keep it uniform. (The impulse for this type of uniformity between UI and services lies at the heart of platforms like node.js.)
As such, we developed a simple and minimal C++ library allowing JavaScript to invoke remote calls via RTMP and handle asynchronous responses. We kept RTMP because it works well for our current scale, and because we didn’t want to change the communications protocol at the same time as changing the client.
Based on some internal prototyping, we decided to use ember.js as our single page application framework, and ember-orbit as our data layer.
What could possibly go wrong with something so straightforward? Well, quite a bit as it turned out.
Our JavaScript code became extremely complex due to the fact that we were handling all the asynchronicity in the web tier. Further, player state was being kept in JavaScript also, meaning that we couldn’t easily minimize down to a low memory footprint.
So, this architecture solved issue #1, but did nothing for issues #2 or #3. An internal developer satisfaction survey found that developing in this way was less productive than the AIR client. Ouch.
Step B: We rediscovered web apps (but on the desktop)!
Our next step was to provide microservices in C++, presenting the async game protocol as a set of REST resources.
We started thinking about how normal web applications are designed, and we realized we were missing a middle tier. We built a microservice layer (still running on the player’s desktop) to present the RTMP protocol as REST resources, to insulate the JavaScript from so much async. We used websockets to handle events back to the UI. We called this microservices layer the ”foundation.”
Below is a picture showing the Swagger UI for some of the foundation patcher resources. This arrangement greatly simplified the JavaScript code, and the devs were now able to use standard web techniques.
We also discovered an additional benefit of this architecture: when we minimized the client, we were able to kill the CEF UI (and all JavaScript VMs), leaving just the foundation. This was only possible because the foundation keeps canonical state—the entire UI can be reconstituted using GETs. The foundation only takes up around 20mb in memory, which is roughly the size of a few internet cat pictures. No one should ever need to kill the client again after getting in-game (as some players currently do to save memory).
This allowed us to start building towards the vision of an "always available" client, which addresses issue #2. The foundation can bring up a system tray notification, even in the background, to indicate a game invite or a friend request.
Step C: Still stepping on toes…
The next evolution was to add an extensibility architecture.
As teams started developing microservices and features, a new problem arose. These teams were often updating the same code, and colliding with each other.
Let me use an analogy to make the point about extensibility. Imagine if ten people were asked to write a single book. Suppose we asked them all to work on each chapter together (e.g. chapter two: “Playing League as a beginner”). It would be a nightmare because they would literally all be trying to change one another's sentences. Instead, it makes sense to give them each a single chapter to write (e.g. chapter five: “Masteries” and chapter six: “Runes”), allowing them to work independently on the same book. Of course, the challenge now is to make the book read cohesively.
We faced a similar challenge on the client update. Teams were adding their features, but too often they had to adjust shared code and frameworks. We needed an architectural pattern to keep them as independent as possible.
I’ve spent a lot of time working on extensibility architectures and I know how nicely they solve the developer collision problem. To keep our architecture simple we chose a variant on a tried and tested extensibility approach called plugins. A plugin is an independent unit of ownership, development, testing, and deployment. Each plugin respects semver and must indicate which other plugins and versions it depends on, which keeps the architecture explicit. We augmented this style with a fully explicit dependency graph, indicating how all the plugins were connected.
So, a UI screen or feature goes into what we call a front-end (FE) plugin, and C++ communications logic goes into a (somewhat confusingly named) back-end (BE) plugin. Note that both types of plugin live inside the new client - we used the terms front and back-end because the architecture mimics a typical client-server architecture, even if it is inside a single desktop process.
We then allow the set of plugins chosen for a player to be based on what entitlements that player has. Entitlements are used to control regional-specific features, and will also be used to give access to new games.
In the process of moving to this architecture, we had to unpack our monolithic JavaScript data layer. We were using ember-orbit to maintain a single connected graph of objects, representing our REST resources. This was a big source of headaches for us, as it still meant that other teams were able to access each other’s data via object links rather than service calls. This was way too much coupling.
So, we retired our use of Orbit and used a simple resource cache owned by each front-end plugin. Doing all this retired a metric shedload of complexity.
Step D: Ask N JavaScript developers for their favorite MVC framework. Get N+1 answers.
We allowed each feature team to choose their own JavaScript framework.
We now had a much more productive architecture and teams were able to make screens and services quickly, with clear separation of responsibilities.
However, we had a developer problem. Some of the teams really didn’t like Ember.js and wanted to use web components directly. Other teams already had their own web apps written in a variety of frameworks that they wished to host inside our new client.
At this point we were still reluctant to relax the "Ember.js for all” rule just for developer preference. Removing the assumptions related to Ember as the single embedded framework was going to take some serious work.
The turning point came when we realized that a client platform for a company the size of Riot cannot even force everyone onto the same version of Ember. It was painful, but we ended up architecting the client to allow each plugin to potentially have its own framework—the JavaScript framework became part of the domain of each front-end plugin.
Note that the key word above is potentially. We still use Ember for the majority of our features for consistency purposes, but this is no longer technically required.
The final architecture
The target architecture for the updated client now addresses our three original issues well. It’s an engine which allows multiple teams to independently deliver HTML5-based features without unnecessary dependencies, using supporting communications infrastructure to allow players to remain connected. It’s effectively a hosting engine for C++ microservices and JavaScript web apps, where the choice of plugins is personalized and dynamic, based on a player’s entitlements.
We repeated the developer satisfaction survey mentioned above, and found that the situation had improved by around 15% and was rising quickly. Nice!
One of the developers commented that we’d made a "datacenter in a desktop." From another perspective, I realized we'd created the game client equivalent of Atom, Github’s CEF-based extensible text editor based on the Electron framework. Interesting stuff, and I would never have guessed that we'd end up here at the start.
There are a lot of questions that this post hasn’t explicitly addressed, such as how we can ensure that features interact seamlessly and don't look stitched together, how we get game quality effects using HTML5, and how we allow for the independent deployment of features. These are fascinating areas in their own right, and we're happy to talk more about some of these things if there's a lot of interest. Hit us up in the comments!"Be sure to check out the League Client Update site for the latest news, dev blogs, and alpha sign ups!
/ALL Chat | First Time Jimmy: Lee Sin
We also have a new episode of /ALL CHAT!"This week, ALL Chat makes Jimmy play Lee Sin for the very first time! He attempts to do so without Tier 3 runes, a proper skin, or a basic understanding of Lee Sin’s mechanics. And Summoner Showcase has cancelled League champions and Kalista before she was a ghost!"
Taliyah Price Reduction
It's been a week since Taliyah's release and her price has been reduced to 6300 IP!
No comments
Post a Comment