How do you account for known performance issues and desync when you're developing experiences like this? Do you balance and tune for the ideal experience that we're working on internally, or do you adjust for the current realities, knowing that you're going to have to adjust again later on?
TL;DRThe team balances for the ideal expected server conditions, then compromises as needed, aiming to return to the original goal as server improvements come, though server variance makes balance hard to read.
Yeah, that's a pretty good question. So we balance it really for where we think it's going to be, so the ideal circumstances. And then we look at what's going right or wrong with that, and we'll make compromises along the way. So basically, as things get better and we understand the problems and we're able to improve some of the framework on the server, we'll basically be able to move back to where our original goal was as we go. But there's always compromise with that. And as Luke said, it just kind of varies as well where people are on the server and stuff like that. So we've got lots of server kind of things to deal with where it creates a lot of variance in the testing. And that does make the balance tricky, because it does make it hard sometimes to understand where the balance currently is. But we're always aiming for where it should be, and then we kind of bring it back to make sure it's delivering the best experience at that time.