The_Easy_Target

Hiho. I just checked our version control system, and the fixes for pyke and kench are indeed in our "main" branch. However, it looks like they didn't land there in time for the 3.09 cut :(. My apologies.

According to version control both are in the 3.10 cut.

It is. We optimized how we load "systemic VFX", so we can add more content and new mechanics without leaving players on low-end devices behind. Unfortunately this broke how some cards override those systemic VFX. We are testing a likely fix for Kench and hope to be able to ship it with 3.9.

Hello there. As part of our testing in developing these updates, we saw there were a few challenges with the existing "passed banners". Chief among them:

• Passive visibility: Much to our surprise, a ton of players (both new and seasoned) actually "didn't see" the banners. They were neat, but for [most] players, they weren't actually serving the purpose they were supposed to.
• Consistency: The banners were available in "normal mode" but not "stack mode". There are several reasons for that, but one of them is that they would obscure combat cards.

Replacing them with gems in the button:

• Allowed us to use them to visualize the "handshake between players" for both modes
• Helped folks actually see them, because the were looking at the button already, and
• Allowed us to add in a call to action (your gem is blinking if you started/modified a stack and need to commit for the game to move on).

As for the specifi...

Hello. I am one of the engineers that worked on the UX changes in the core game, so maybe I can provide some context on this.

Our main observation is that while LoR is a fun game, a lot of players newer to the genre feel overwhelmed, and they give up before they can "find the fun".

Observing and talking to those players, one particularly challenging aspect for them is that LoR has and always had two "phases" or "modes":

• The "normal" mode, where one can summon units, start a stack, or end the round
• The "stack" mode, where we have actions that haven't taken effect, yet, and one can add more actions (block attackers, or add more spells), until it all resolves eventually.

However, those two modes looked very similar to the untrained eye. Once we added a more clear (visual) separation between those two modes, a lot of the things that are obvious to a seasoned player, also start to make more sense for the rest of us.

In the c...

Hi. I am one of the engineers that worked on the sprite system. Maybe I can shed some light on this behavior.

First of all congratulations on finding a way to use an internal system to flavor deck names :).

To save RAM (and bandwidth, diskspace, and battery consumption), the individual sprites are packed into a small number of sprite atlas assets. The packing needs to:

• Not leak (temporary) sprites for future sets,
• avoid wasting "empty space", and
• be easy to use for the artists.

Internally the sprites are individual assets with a filename, e.g. Demacia.png. Artists maintain lists of which sprite goes into which atlas. Then an automatic process builds the sprite atlas assets from the lists.
To keep the number of assets low we move the sprites for new sets into the "main list" once a set has been released, and regenerate the atlas assets. As the sprites are ordered alphabetically the position of the sprites changes......

Hi. I am one of the Engineers working on the Premonition system. Thank you for the report. Especially the comment about fearsome was helpful to understand what was going on:

In LoR we overlap as many animations as possible, so that the game "feels smooth". The amount of overlap is limited by a set of rules that enforce correctness. For example:

• Image there are two spells that damage the same unit, the first one with a very long animation before the damage, and the second one with a very short animation before the actual damage.
• If they'd start at the same time, the second spell would update the unit-health first, and when the first spell finally finishes its animation it would override the already updated unit-health with its change. This would animate confusingly, and result in incorrect unit-health.

To avoid this we have a rule that enforces health updates in the correct order for a given unit (The animations can still overlap, but th...

Hi. I am the engineer who worked on "Premonition" (the cracked-card system), so I can give some (lengthy) context on what is going on with HexCoreUpgrade.

HexCoreUpgrade is using a random effect. Those are hard to deal with in "predictions" (OracleEye and Premonition), as we need to be very careful to not leak information:

• Imagine playing Ebb (Deal 2 randomly to an enemy...). If the cracks reveal which unit will be damaged, the opponent will know which unit they need to protect. This knowledge would change gameplay pretty significantly.
• I am not sure a situation exists currently where giving Victor a random keyword would result in any unit dying or not depending on which keyword he will get. Unfortunately the system dealing with "predictions" is not able to distinguish between "different kinds of randomness". It just sees "random" and bails.
• Making that system smarter in a general way is exc...

Thanks for the report. Fix going out with 2.18.

Thank you. There is a "Disable Motion" option in the settings already. We should be able to teach it about some of those shakes :).

Unfortunately "screen shake" is a surprisingly large family of effects, with many differences in strength, timing, movement-axis, and implementation. Some are very integrated, e.g. in an animation like Darius Levelup pulling the camera closer and thus harder to "turn off"...
Would you mind calling out some situations where you find screenshake particularly objectionable?

Good point, and yes. The proposed change makes this "Click Action" behavior opt-in, and even if you opt-in, it will only be in effect in a labs game mode. If it helps more than it harms, the next step would be to make it opt-in for all game modes.

It is rather grainy, but here is an example of the prototype in action: https://media.giphy.com/media/X6Wc2FhHo8C9Y7E1Ip/giphy.gif

Hello. Congrats on your new controller, and thank you for the insight into the challenges of using "hold-to-drag"!
I am an engineer on LoR, and "click-to-hold" will be a bit more challenging for us to implement, but I wonder how well the following would work on PC:

• left-click on a card to play it
• left-click on a backrow card to attack with it (if you can attack)
• left-click on a backrow card to block the first attacker it can block
• left-click on a blocker to block the next attacker, or return to the backrow when there are no attackers to its right

This might be a bit more cumbersome than "click-to-hold" but is (close to) functionality we have internally for automated tests, so we'd just need to tweak and expose it, which we might be able to do for 2.10 :fingerscrossed: :-)

Hi! I am one of the LoR engineers working on quality / performance / battery life. Thank you for playing LoR.

Battery life is pretty device and usage dependent. One of the biggest factors is screen brightness, but video quality does impact it quite a bit, too. Let me explain what the settings currently do, and try some rough estimates for play time on your Pixel 4 XL; sorry if it gets a bit long :)

• Starting from the top, "Ultra" is the highest quality setting: Native resolution, MSAA, and cinematic bloom on certain animations. This looks great, especially on tablets with larger screens, but is rather expensive. Luckily tablets tend to have big batteries to compensate for the battery draw to some extent.
• On "High" there is no MSAA, slightly less post processing effects, and the resolution is capped at 1080p. This tends to look pretty crisp on most phones, but especially text can feel a bit blurry on larger tablet screens. Battery consumption scales c...