wotc_beastcode

For sure. We use a fair amount of object pooling, both with GameObjects (like cards) to avoid instantiation costs and with Unity-agnostic data types (like Lists) to avoid allocations.

This person knows what's up! We've had a few of the event handler one. :D

DID SOMEONE SAY NERD OUT?!

I can do that. :D

SoneEv is pretty much correct with their explanation.

As a programming team gets more familiar with the problem they are solving, they learn better and better ways to approach it. It's always a careful balance between adding new features and "cleaning up" what you've done in the past. Too much cleanup and you stop making progress. Too little and you start moving too slowly make any progress.

Another manifestation of this is when you start hitting scaling limits. For example, Arena has a lot of rich visual effects and situational graphical elements. We have an elaborate set of rules for which one to play in a given situation. Hand-coding is inefficient because it's hard to maintain and limits the work to only engineers. So we have a flexible data system to specify all the rules. Our first system was fine when we had a few hundred visual assets and a dozen variables that affected them. But now we have thousa...

Awww. Thanks for the kind words and understanding where we are coming from. I will say the "and the rest of the team" part is really where the work came from. Even a small release takes a lot of mobilization. I just looked and numbers and pointed at people and code. Also, a special shout out to Megan O'Malley, who realized she had an HD3000 at home and carted the thing in at significant personal inconvenience so that we could get working on it immediately.

Try now :D

We've identify and implemented a mitigation for that chip and others like it. It's just a matter of getting it to you. Stay tuned.

Lots of Magic players are still on 32-bit windows and we want to be as inclusive as possible. We'd love to provide both, but that's further down the road.

A quick update on our progress on our findings. We have identified a couple of issues that, in conjunction, lead to frequent crashes for some users. We are working on getting a fix to you. As always, I cannot promise a specific timeline, but it's in the works.

[Techy details follow for those who are curious]

Since integrated GPUs don't have any VRAM, they borrow from main memory. So, for example, if we are using 2GB of graphics memory and 2GB of system memory, an integrated GPU will use 4GB and crash a 32-bit program. Kind of a simplification, but it's pretty close.

The HD3000 (and probably a few others from that era) also seem to exhibit weird behavior where it uses up way more than we'd expect, even from an integrated GPU. For example, am HD5500 winds up using less than 1.5GB at game start, whereas an HD3000 winds up using more than 2.5GB. We are looking into the source of this discrepancy.

But why did it get so much worse recently? In a ...

Yah, we've definitely been giving the HD3000 the side eye. You aren't the only group with the issue, but the 3000s have gotten a pretty big uptick since 9/4. We have one coming into the office tomorrow so we can bang on it. Thanks for sticking with us.

Thank you very much for putting together this post!

Rest assured, we are aware of these issues and we are working hard to resolve them. Definitely keep the bug reports coming. We do read them and we do take them seriously.

I'm the tech lead for the client, so I wanted to chime in to give you guys some context on the issues we are investigating and give some ideas on how to help us solve them.

[Warning: You are about to get a whole bunch of engineer speak.]

1. Unity Crash

This is the one we are most concerned about right now. It definitely seemed to start hitting a lot more people around the 9/4 release. We are looking into what changed but also trying to understand what's causing the issue. It generally appears to be an issue with the game running out of memory. That's why you'll be fine for a bit, but then it will crash seemingly randomly.

What's weird to us is that we are seeing situations where we didn't...

There are a number of reasons, but as an example, we can't pre-load your opponents deck (animations, card art, etc...) until you see a given card. If we loaded that data ahead of time, the client could be hacked to show your opponents deck. And naturally we don't want to load every possible asset.

You are not alone. A number of players are experiencing degraded performance and the tech team is working hard to sort the problem out. If you want to help, you can provide information according to this tweet: https://mobile.twitter.com/mtg_arena/status/1178124572878458882?s=21

A detailed description of your experience is very helpful. Does it get worse the more games you play? Specifically how does the lag manifest? Does the whole game freeze up for a moment? How frequently and how long are the freezes? Do they happen during particular actions? We have reporting for these details, but getting a user's perspective on this can help us make sense of the numbers.

Thanks for the detailed and well-thought-out post. Thanks to the OP as well for urging users to send us detailed reports. Believe me that we get them and believe me that we find them useful.

As far as network latency is concerned, I can tell you fairly categorically that the game does not hold rendering or game loop processing to wait for network replies. Game actions like a land being played or a spell resolving are definitely paused to wait for the server, but rendering is still occurring. In fact, one of the dead giveaways that the server is under heavy load or that your connection is having trouble is when you play a land and it pauses mid-flight and hangs out in the full-card mode. We start the animation for playing the land while the network request is in flight, but don’t finish the animation and put the card in play until we get the response.

You can determine if the render loop is still running by looking at some piece of the game that is always i...

I'm on vacation (so you definitely don't see me posting) and I plan on digging into this more when I'm back, but I've been just playing as a customer and noticed something a little ironic. There is something to your theory that performance can degrade more on higher spec machines. We still have a number of per-frame memory allocations we are working on killing. So if you are running at a very high frame rate (I was around 250), you are allocating a lot more memory and, therefor, incurring a lot more garbage collections. Capping my FPS to 60 smoothed me out a lot. It's only one small piece of the puzzle, bit I though I'd mention it.

Not at a computer to double check my work, but you can add a minus sign to exclude a given term:

-e:ana

SHUCKS! You are totally right. Hm... I wonder what the right filter for that would be. "Castable with"?

Our super awesome community folks put something together here:

https://forums.mtgarena.com/forums/threads/46567

I've been playing a bunch of sealed and I kept wanting to visualize different color combos. When you are often building a 3-color deck, toggling on those three colors really starts to be "all those colors and all your gold cards". If you want to only see gold cards that are in your chosen colors, you can use the advanced filters in the Search box.

As an example, I am thinking that I'll go Mardu with this pool (Red/White/Black), so I put this in the filter:

c<=rwb

It looks a little goofy but that basically says "Show only cards that have these colors or fewer". This will also include colorless cards.

1. Calling this phenomenon "Gatecrash"... Bravo for that. :D

2. We fixed it. Should be better in the upcoming release.

3. Just for fun, some hints about the code branch we missed: If a typical standard deck wants 24 lands and you have 10 non-basics, how many basics should you add to fill out your land count? Okay, now do that math for 25 non-basics. ;) Little bit of a facepalm, but it was easy to fix.

Doh. I looked into this. Know exactly why it's happening. It won't be fixed in the 0.12.01.00 update, but we'll try to put it in the next one after that.