devtrackers.gg
As someone who's worked with Unity before, upgrading to a new Unity version is absolute hell. My guess from the bugs I've been seeing is that something changed about the render pipeline that's breaking their shaders or something. (I've been seeing two classes of problem: transparent things either being the size of their whole texture, or being almost invisible (targeting and attacking arrows); or things rendering in front of things they should be behind.) It's kind of impossible to upgrade your Unity version without a bunch of stuff breaking, and frankly we're lucky they managed to keep it to visual stuff.
With the sheer number of cosmetics and cards with unique animations, it would take massive amounts of resources to find all the visual bugs, so I can understand why they'd choose to let bug reports take the lead. That said, the fact that targets and which creatures are attacking what planeswalkers are really hard to see is kind of inexcusable, they should've playtested enough to at least catch that. (Unless that's just on some graphics cards? In which case they've entered a special hell and I have nothing but sympathy for their shader devs.)None of this should have anything to do with Sparky, which I'm guessing is some sort of database issue (failing to store the tutorial progress data) at least somewhat akin to the draft token problem from a while back (but in a less mission-critical part of the app).
Ding ding ding! 'twas URP. (And many of the missing visuals do seem to be about at least multi-shader interactions, with some looking card/driver specific, which is Much Fun.)
None of it is inherently tied to fixing Sparky, but the fix to Sparky was waiting behind it in the release pipeline.
Oh dear, multi-shader interactions sound combinatorically nightmarish and really hard to unit/integration test to boot.
I wonder if this is a job for ML, at least in the long run? Train image classifiers on various UI elements (arrows, mana symbols/card text, approximately how various cosmetics ought to look...), then record known-good confidence values for a wide range of gamestates across different battlefields and cosmetic combos; to run tests, load up those gamestates, fuzz across a wide variety of battlefield/cosmetic combos, send a screenshot from each to the classifier, and investigate further if it's not confident enough that it saw the desired UI element. Obviously not going to catch everything, but seems like a good first line of defense?
We're actually working on building out full-cardpool visual diffing tools to catch at least the basic (i.e. non-combinatorial) level of this problem. It caught many, many bugs with this renderer change that we were able to fix before release, and is something we'll continue to build on, likely in some of the ways you describe