Lorem ipsum dolor sit amet, elit eget consectetuer adipiscing aenean dolor

[Not a bug] Game speed changes to normal by clicking on a troop or settings

win 7 ultimate sp1
game ver. 4.9.0r20535
steam client

hi everyone
there is an issue with game speed above normal like 4x, when casting spell animation or matching gems is still in progress if i click on a troop or settings menu the game speed decreases to normal (or even slower) and after closing menu, game speed goes where it was again.

This has been discussed - it’s purposeful. Something about it being necessary to prevent cheating or something?

oh i didn’t see that.
how game speed and cheats are related anyway
there are some annoying things in this game they never fix for no clear reason. really disappointed.

So here’s a theory how it’s related to “cheats”. I figure every now and then I should post something that’s not a rant.

I’m normally an app dev, and app development is kind of “comfy” compared to game dev in some ways. If I want to start an animation and I need to make sure I don’t do things until it finishes, that’s more or less how I write my code. “Start the animation and tell me when it finishes” is how I talk to the computer. That’s because apps are event-driven and don’t tend to do a lot of rendering work unless the user’s done something like pushed a button. So if there’s something I don’t want to happen while the animation’s running, I can note “hey the animation is going” somewhere, then wait to get rid of that note until it finishes, and the thing can check if the animation is running before it starts. The bigger the app, the more things like that, but in general smart app devs design their system so it’s easy to understand which things care about which other things.

Game dev is loop-driven and has to render every frame whether there is input or not. That puts more pressure on the devs to avoid practices app devs consider smart. A lot more information about what’s going on in the entire game needs to be available to all of the code. This makes me cringe as an app dev but to some extent it’s a fact of game dev.

The loop-driven nature makes animations more complex too. They can’t say “do this and tell me when it’s done” because there’s no concept of “waiting”. Every frame happens, and all of the calculations need to be done. Unity has a feature called “coroutines” that helps deal with some of this complexity. It lets you write your animation in a way that’s kind of like, “Do this for 90 frames, then update this variable, then do this for 80 frames, then update that variable.” But that feature adds a different kind of complexity: it separates each animation’s code from the others, so it’s harder to understand which animations interact.

Now, the way a game typically implements a faster speed is called “frame skipping”. Normally, the game loop works like this:

for every frame:
    Process the user input.
    Do all the AI things.
    Render the frame.

To “frame skip”, you pretend like multiple frames happen every 1 frame. So a 4x game loop would look like:

for every frame:
    Do this 4 times:
        Process the user input.
        Do all the AI things.
    Now do this 1 time:
        Render the frame.

This is where stuff starts to break. Imagine we have an animation that goes something like this:

    If this frame is number 60:
        Set the "don't let the user tap an ally" flag.
    Or if this frame is number 240:
        Let the user tap an ally again.

We know something bad happens if the user taps an ally in between frames 60 and 240. So we try to tell the UI to disable tapping allies. But the code to do that might be part of “Render the frame” since it has to do with UI:

if "don't let the user tap an ally" is true:
    Disable tap events for allies.
    Enable tap events for allies.

Bam. This is a bug at 4x speed. Suppose the very first frame of a 4x set tries to set that flag. There’s a bit of time between when that happens and when the rendering code tries to disable tap events. If you tap during that small window, the game is going to queue up a tap for the next “process user input” step. If that step believes “the UI will disable taps if they aren’t allowed”, it’s going to act as if the tap was legal. So now bad stuff happens.

When I’m talking about one measly animation and one measly problem with if a user taps at the wrong time, it seems so easy to keep it all straight. But in a game like GoW, there’s dozens of different animation routines, dozens of different “should this be allowed” flags, and dozens of variables that affect other aspects of the system. No human can possibly keep track of how they all interact. It’s possible if they fix this problem, it creates a worse problem. It seems obvious to “disable tap events” instead of just setting a flag, but I can think of at least five technical reasons why that might be “impossible” or “worse”.

That’s why, in app development, I work hard to compartmentalize code to make relationships obvious. But I get a luxurious 250ms per “frame”, in some cases the user might not do anything that causes me to render for a whole 10-15 seconds, and if I’m really worried I can show a “Processing…” indicator to tell the user to hold up! Gems of War has 16.7ms per frame or else it stutters. That causes you to cut corners, and cut corners are sharper than normal corners.


I’m not a programmer at all so I’ll provide the layman’s explanation, for people like me, to accompany Slyp’s well thought out technical explanation :slight_smile:

Basically, with the way the speed settings and animations are implemented for the game in Unity (our game engine), Unity cannot support continuing to run the game at 4x speed while you have a card selected. So it must slow back down in the background while you have a troop selected.

We’ve had players who also happen to be programmers tell us we could fix this and to let them fix it for us if we’re not competent enough (ouch). This one line Slyp said summarises why we don’t always do something just because it can be done:

Game speed interacts completely with our core gameplay. The foundation the entire game sits on. It’s not worth messing around with for a minor quality of life pay off.

I don’t disagree with you, what you’re suggesting might be a nice feature of the game (this is without even touching on whether this is actually an improvement or a nerf to player experience due to visual communication issues it could potentially create), but it’s just not worth the risk vs reward - not even close to being worth it at this time. It has nothing to do with competence levels.

Replace “scientists” with “programmers” here:

PS. I wish I’d come up with this response during the original discussion. Ah, my slow brain.


(You should update to W10 yesterday)

1 Like

If this was a “bug” that favored players as opposed to slowing us down, you bet you’re ass that no amount of “potential problems” or “legacy code” would stop the devs from fixing it.

Personally, I would rather be told the truth and deal with a decision made by the devs that I didnt like, than flat out lied to. Excuses are lazy. Honesty is difficult.

If you don’t like my dev answer refer to the one made by a player directly above it which explains in more detail.

It was implemented this way from the start, we knew how it worked then and we know how it works now, it’s not a bug or a change, it’s not legacy code, it’s just something that has been raised in this thread for looking at now. The animation speed was implemented years ago. We don’t tend to develop by committee running every line of code or pros and cons of ways of implementing feature past the player base before it’s implemented, nothing would ever get done that way.

You seem on edge with your recent posts today Sassy, we’re not out to get you and I don’t get any joy at of lying about anything in life, I have the opposite issue: I tend to be honest to the point my honesty causes issues. I hope you enjoy your weekend :slight_smile:


Wonder why lol.

I’m sure this is true. Not me specifically because let’s face it, I’m just not that damn important lol. But playing favorites is playing favorites just the same.

1 Like

OK thanks everyone for detailed answers
actually im really confused i thought it could be an easy fix for them to deal with but it seems things are more complicated, like many variables, priorities, codes executions stuffs like that. i don’t know much about programming. Hope they find a way to get it fixed soon
@Live thx for advise ill do it soon

1 Like

It would be nice to be able to queue my next action while the computer is doing its turn, then the screen would simply go away and the 1x speed wouldn’t matter anymore.

sure its a good idea
or even a skip button