What you were expecting to happen, and what actually happened:
My mouse cursor clearly goes from the red gem to the purple gem on the right, yet the purple gem from above is the one that gets swapped.
I will admit that the motion of my cursor is at least as much “up” as “to the right,” but my cursor NEVER touches the purple gem above the red. It should have swapped right, not up.
Showed this to a Unity dev whose theory is that the game is using flick prediction which should be mobile only, but is being used on PC. The theory is that the game is predicting which box you want by which ever way you “flicked”. Flicking only makes sense on touch devices though.
I tested that out on PC myself and sure enough, I can duplicate this bug every time. Going to add my own video for the devs then. To do this every time, keep your cursor in the same box but flick towards another without ever touching that box.
@beeflog, this happened to you because you flicked the cursor up, even though you didn’t touch that box.
Hopefully turning off flick prediction is easy, but who knows.
I can add that in recent times, on mobile, there have been a few cases where a mis-swipe (aka fat/clumsy fingers) has momentarily made me think an Extra Turn should or shouldn’t have occurred when it didn’t/did, and made me wonder if that along with fast animation speeds might contribute to the ‘No Extra Turn on 4-match’ or ‘Extra Turn on 3-match’ reports.
Thank you so much for the video @beeflog ! And thank you @Snooj fir the gif!
I’ve been talking to the team about this, and have some information for you.
Our code base uses a drag tolerance, and once the drag has past the tolerance distance then it checks whether the x or y is larger and attempts the gem switch in that direction. There is no “flick prediction”, it’s the predominant direction of the swipe. It’s hard to tell in the video when the mouse button was released, however, there clearly is a slight up then diagonal movement of the mouse, so it appears when the tolerance has been passed, the Y must have been greater (and it only has to be a fraction) than the X.
This isn’t technically a bug, but in the future our team will have a further look into this and see if it can be improved. However, since this would be a change that involves gem matching and is a fundamental part of the game, we have to be very careful and it will take some time.
I don’t really care to argue semantics of whether or not this is a “bug,” or if it’s called “flick prediction” or “drag tolerance.” None of that matters to me! If the code is “working as intended,” it is a very bad design. I don’t want my match-3 game to guess what gems I want to swap based on a few pixels of movement, I want it to wait for me to select two gems, and swap those.
I understand that this is a fundamental part of the game. I humbly propose that an “alternative” gem swapping mechanic be developed where only unambiguous inputs are accepted as valid, and let the players choose (or chose lol) between the two in the settings. I think the current system leads to a lot of frustration, and I would absolutely prefer the game be stricter about my input if it led to elimination of this type of behavior.
edit: At a minimum, I would hope that any predictive swapping would be over-ridden in the case where my mouse actually crosses from one gem to another, and they are a valid swap. No matter what path I take within the first gem’s box, if I go from gem A to gem B, I don’t want gem C to be involved in the swap!
edit2: I saw you asked about where I released my mouse click. I think based on my typical movement, I wouldn’t have released it until somewhere long after the follow-through, far off to the right in my last screenshot image.
You know, I said this, but now I’m going to disagree with myself, since you edited the title of my post. It’s asinine to call this “not a bug,” where a gem was swapped that my mouse never even went close to, on my path toward the gem I intended to swap. This is absolutely a “bug,” in the sense that it is NOT THE INTENDED BEHAVIOR. I think this should live on the bug tracker until fixed. KNOWN ISSUE: THE GAME WILL SWAP GEMS YOU DON’T SELECT, IF YOU MOVE TOWARD THEM BEFORE MOVING TOWARD THE INTENDED GEM.
It takes some pretty serious mental gymnastics in a match-3 game to call that “not a bug,” just because it’s working the way you coded it to.
Maybe a hint, maybe not → could the team test, if gem grid is displayed correctly to match those “drag tolerances”. Or maybe there’s a need to increase the tolerance distance so that it would check for the x and y even further from square center?
I’ve often wondered what just happened there when I moved gems, especially horizontal and vertical alignments, that can make 5 or 7. Instead of there being 5 or 7 gems matched, 3 have been matched. I’ve always put it down to my mouse moving skills, but it’s happened 100s of times over the years and it’s just been shrugged off by me as moving the mouse wrong. I’ve often thought, no I definitely swiped that right, but soon forget it. However I got to the point on day 6 of the last Guild Wars of putting 2 hands on the mouse to make such moves on my final 2-3 battles on the last day.
Similar to @xolid99, I always thought those instances were due to my hands trembling and mouse shaking, so I didn’t pay much attention, except for - I need to be more careful in the future. Now it turns out it was the game doing weird stuff, after all.
It would be nice to come to a point where matched gems are the ones I had matched not the ones the game thought I had matched just because they were next to each other.
I have explained that the team does want to look into this even if it is working the way it was intended. However, it will be a longer issue as it requires a significant amount of time invested to make sure more issues aren’t caused. This is the core of our game, and we need to be delicate when making any potential changes.
