: Winter Summoner's Rift coming soon PBE!
Out of curiosity, is it technically possible for you guys to change the camera angle to 0 FoV orthographic projection, or is the game engine entirely constrained to prevent such a modification as part of the map?
: Shadow Performance Improvements
What is the most ridiculous thing your team has found out about the code since starting on the cleanup project?
: The Sustainability Initiative is focused on the long-term sustainability of League of Legends. As we continue to scale League, adding more content, making more changes, the game becomes exponentially harder to manage. We get more bugs, work slows down, it becomes harder to innovate. The current challenges we are trying to overcome are related to the way we test the game, the way we make content for the game and the way we build and deploy the game. The hardest part about working on such a large game that is live is that any changes we make have a lot more risk involved. We're building the plane as it's flying, not an easy undertaking. The most interesting challenge for me has been related to adapting what I know from making boxed games to how we make a live game like League. It's a very different experience and challenge and it's been a blast exploring that space. Let me know if you have more questions!
Question: when can we see the game engine preload all assets for systems with excess RAM?
Rioter Comments
: You mentioned the pros, but not the cons :) I'm not sure actually, I think it's what someone picked a while ago as a standard isometric camera view and we've never had a need to question it, but I could be very wrong there, I haven't spent a lot of time thinking about that or asking others about that.
Disadvantage of orthographic camera -- the foreground and background will appear to be the same distance from the viewer, which means that if the background has a lot of clutter, you can no longer use perspective to tell apart the foreground objects and the background. On the flip side, however, if the background is visually well-optimized to increase contrast of the foreground objects, this orthographic view actually **increases** visibility of the objects since they won't be dwarfed by the environmental objects like in DotA 2. And about the angle, if it's any hint at all, it's roughly equal to arctan(16:10) ~ 57.995
: 1. Not yet, we've had a few discussions here and there about what that might look like, but nothing concrete. We're laying the foundation we can build on right now, so we're focusing on that before making a massive roadmap as that's the first and most important step. 2. I don't have a strong opinion here honestly, what do you think are the pros and cons with a 0 FOV camera?
Well, the biggest advantage is that of being able to judge distances/ranges determinantly. But even more important is the fact that it solves a long-running visual problem with League -- terrain height interfering with skillshot hitbox judgement. Lux ult is one of the biggest offenders, along with Sona ult, but one thing that I personally feel is most impactful that is not necessarily the most visible is how missile indicators are displayed. Lots of people have complained in the past demanding to have the hit boxes fixed, but really the problem is with the perspective camera, it will all be fixed in one fell swoop if orthographic camera is used. (P.S: quick question: what is special about the angle 56 degrees that we view the Summoner's Rift at currently?
: Death Screen Performance Tweaks
1. Besides cleaning up the codebase, do you have a roadmap for gradual supplantation of the engine as hardware moves on? 2. Visual Clarity. In the SR visual update, you chose to move the camera farther away/decreased the FOV to reduce perspective distortion. What are your opinions on straight-up 0 FOV orthographic camera positions?
: Hey everythingllbeOK, All the spell input stuff goes through the same flow, but it's in a totally separate section from the movement, attack move, attack, etc. commands. You're probably right that those concepts could be grouped, but presently that's not how things are structured, hence the inconsistency. That said, have you looked into AttackMoveClick, which is essentially the QuickCast version of AttackMove? James
Dear James, Thank you for your answer! I have long been struggling to find the best way of incorporating Attack Move Click into my control scheme, however as you say due to the way these inputs are structured, there is always some unnecessary conflict in the control scheme that ends up requiring very strange finger combinations. The best scheme I have come up with is binding evtPlayerMoveClick=[Button 2],[Shift][Button 2] evtAttackMoveClick=[Shift][Button 1]. (This should definitely be the default, by the way -- the whole point of Attack Move Click is to remove the need for keypress synchronization by preempting the command with a state change; the default of binding it to [Shift][Button 2] defeats the whole purpose as you now have to be very precise in timing your Shift presses, providing no advantage over A-clicking) Yet this scheme gives a problem for me specifically, as I have QWER for quick- and Shift+QWER for normal-cast, this means that if I hold down Shift at some point, there is collision of the spell confirmation command with evtAttackMoveClick which is now bound to [Shift][Button 1]. It also present a problem for those who use the regular Shift+QWER for quickcast scheme if they were to play, say, Viktor, where one would activate (but not yet confirming with MB1) his vector-cast Laser, then hold down Shift to preempt quickcast of W, only to find that pressing MB1 now cancels instead of casting the spell thanks to [Shift][Button 1] being bound to evtAttackMoveClick. And, obviously, evtAttackMoveClick=[Button 1] prevents you from confirming any spell entirely. I have also done a tone of experiments with evtChampionOnly and evtAttackOnlyClick, but all of them being severely limited by the incoherent organization of the input flow in the game. My personal wish for input controls would be to be able to hold down [Button 1] to preemptively confirm spell casts/attack commands, i.e. hold left-click to activate "quick-cast mode" for all inputs. I have been thinking long and hard about what a reworked, flexible input scheme engine should be like, the basic idea is that the keybinds should make distinction between command types, i.e. held, pressed, two-step (like vector quickcast), stateful, on-press, on-release, etc, and assign the binding restrictions based on the overlap of their usage. It's a shame that if I were to write a treatise about it, there would be no platform to post it, since the entirety of the Gameplay Boards seem to be only concerned with a champions being OP or not. But I digress. In any case, I am extremely grateful of your attention, I hope the continued renovation of the game engine will make the game more and more healthy in the long term! P.S. May I ask what aspect of the game would you be responsible for? My interest is not limited to just control schemes, as you may tell.
: I actually don't know the answer to most of your questions as I'm not an engineer or designer, but I'll see if I can get some people in here who might have the answer! Aso, Have you checked out our engineering blog? I think it's more geared towards what you're looking for! https://engineering.riotgames.com/
Thank you for the reply! You are very kind in being so diligent! I am indeed quite a big fan of the technical blog, and enthusiastically reads up every article when it drops occasionally. It's just that since it is a relatively one-way platform, the engineers are doing the guesswork on which topic are the ones that audience are dying to know about. If it were a two-way platform with room for questions and inputs, this could give the writers inspiration on topics which might not have occurred to them as being worth writing up about. Thanks once again for your presence!
: Death Screen Performance Tweaks
It is great news to hear that Riot does indeed have a long-term plan in gradually updating the game engine in general. I have been asking for ages about what plans Riot have in store for a procedural upgrade. I believe that this is the first time you guys have properly communicated the existence of such an initiative, aside from a slight ambiguous hint in the projectile update that did not make it clear whether it would be a one-off thing or not. May I ask how the game client/engine is partitioned in terms of functionality? As in, how independent are each modules (HUD component, User input component, Server logic component, Rendering/VFX component) such that one might overhaul one part without impacting the others? As in, would you guys encounter the situation where if you rework the minions, the minimap would stop functioning because the HUD element was somehow coded as minions? Personally, I feel that right now User Input is in serious need of changes, a lot of the modes of input are quite archaic and inconsistent. One example of this is the significantly inconsistent behaviour of Attack Move when compared to Spell Casts. Both are casting-like inputs, but for their normal-cast versions, Spell Casts can confirm the input **on release** of [Button 1] in addition to **on click**, while Attack Move can only be confirmed **on click**. This makes it (needlessly) critical to time your mouse click **exactly** after the keypress for the attack command. Beside this, with you guys pushing Quick-Cast On Release as the recommended input mode for new players, it is incredibly strange that you do not have the same option available for Attack Move. There is no reason for these kinds of discrepancies to exist when both are casting-like inputs. Another example is Camera Control. I had my hopes up when you guys first released the Semi-Locked Camera option, seeming to indicate the possibility of tweaks in this component of the game engine. I previously wrote a [short treatise](http://boards.na.leagueoflegends.com/en/c/gameplay-balance/wBgZiaNI-the-ergonomics-of-camera-panning-and-proposal-for-an-alternative-mode-edge-pushing) on camera control reasoning that there is no reason to dogmatically continue with the outdated mode of camera control inherited from 2D isometric RTSes which were originally created due to a limitation of technology. It is just much more natural to control the camera based on how far you move your mouse beyond the edge, rather than depending on some preset velocity. Also, League could really benefit from F5-F8 camera positions assigned to your wards, so that we could also get some of Starcraft's [multitasking glamour](https://www.youtube.com/watch?v=RR7CU3CJ7iU) in our gameplay for those who want it, without necessarily disadvantaging those who don't use it. Finally, all of these is nice and dandy, but I feel that there needs to be much more transparency communicating in the technical inner-workings of the game. There should be a platform for discussion where you guys can communicate to us how it works, and the more technically-minded players can communicate potential insights that might have otherwise been overlooked thanks to being drowned out by Memes&Games posts. Thank you so much for gracing us with your presence on the rare bit of technical information in the game, by the way.


Level 30 (PBE)
Lifetime Upvotes
Create a Discussion