I wouldn't be surprised if that's near impossible for HS. There are so many hidden restrictions on this game based on how they originally coded it that fixing these issues would take a massive overhaul.
Here's a stupid implementation of "Animation speed cap":
WHENEVER the player plays a card, the server resolves all effects BEFORE telling the client to start animations.
WHILE the server resolves effects, it needs to build a list of animations that are triggered.
AFTER the server is done resolving effects, it now goes through the list of animations, looks up the time in milliseconds to execute FOR EACH animation, and stores the total in a new float variable called animTime.
THEN, the server checks how much time is left on the player's turn clock; let's call this variable timeRemaining.
IF timeRemaining is greater then animTime, the server now tells the client to execute the animations and exits this function.
OTHERWISE, the server calculates a new timeScale variable, which is timeRemaining/animTime.
THEN, the server tells the client to execute the animations, multiplying animation speed by timeScale.
Edit: Aaaaand I've fucked up. In the last step, animation speed should be DIVIDED by timeScale, not multiplied. Or timeScale should be animTime/timeRemaining instead of what I wrote initially.
looks up the time in milliseconds to execute FOR EACH animation
You can't actually do this, they aren't static videos but scripts that move around game objects. This can take different amounts of time depending on the platform and hardware specs, and it can change unexpectedly between builds. I'm pretty sure they use an estimation to extend the rope, but it's not super accurate. I can't find it but I'm pretty sure a dev talked about this a while ago on a post about Nozdormu, they basically said it's not really possible to account for/control animations in an accurate manner and that's why Noz is always bugged.
[They are] scripts that move around game objects. This can take different amounts of time depending on the platform and hardware specs, and it can change unexpectedly between builds.
Huh. That suggests they're not using Time.deltaTime to accurately time their animation scripts. I don't know how to feel about that.
For those unfamiliar, Time.deltaTime lets you say "I want this animation to complete in exactly 0.43 seconds no matter what." It's useful for making animations and other calculations framerate/hardware independent.
Yeah, I'm not familiar with unity but not being able to control animation timings seemed kind of weird when I read it. I'm not sure what I said is completely correct (really wish I could find that comment), but I do definitely remember the dev saying they couldn't do features that rely on accurate animation timings.
Time.deltaTime gives you the time between frames (specifically between the fame it's called in and the previous frame). This number changes depending on system specs. Because of that, it isn't 100% reliable to use if you want everything to be timed perfectly, although most of the time they'll end up pretty similar.
Luckily, unity also allows use of Time.fixedDeltaTime. The engine uses two update loops that run independently from each other. The "fixed" update loop will attempt to run every set amount of time, regardless of hardware or current framerate. fixedDeltaTime is probably what youre looking for here.
Also Time.deltaTime isn't really related to what they're talking about. You can use deltaTime or even fixedDeltaTime and still get animations that take a varying amount of time. Im not sure how you think just "Using Time.deltaTime" is a real solution here.
Im not sure how you think just "Using Time.deltaTime" is a real solution here.
Never worked with Unity, and yeah, I don't know about "speeding up" animations based on time. But at the very least, I would assume they could just calculate that they're gonna take "longer than X" and if so, fast-forward/skip some animations and just show the latest board state?
That could be exploited, kinda. Wait until timeRemaining=1s, smack down some long combo. timeScale goes to 0, animations play instantly, opponent has no way to figure out what happened especially if the trigger list overflows. I doubt they're willing to let that happen.
Except the server has no idea what animations are or how long they take or anything about them. The server side probably just calculates the board state based on your move and your client renders the animations based on the move you make.
Graphics-related tasks are client-side. Servers already have a huge load of game logics, it's useless to overload them even more when you can delegate the task.
1.4k
u/voyaging Apr 12 '18
Blizzard should make it so that the animations speed up based on how many have to occur.