At the time this question was sent, the PTU was in a very rough state. How concerned are you with avoiding another 3.18?
TL;DRTyrer doesn't want another 3.18 but doesn't expect it, explaining that foundational tech needs broad live testing to find root causes, so shipping with some issues is a judgement call.
Well, I don't want another 3.18, if that's the short answer. The long answer: you have to evaluate two points of view before we decide whether a patch should go live. I think the first point of view is the fact that you want to evaluate the gameplay experience. Have we made the gameplay better? Are the new features in there polished and working as intended? Are the existing features working? Have we lost anything from a previous patch cycle that we want to make sure is fully functioning? And that is a whole team-wide effort. That's not an individual person. That is from all the reports that we get. We then obviously canvas live QA. We have the player experience team. We have publishing. We have the development leadership. We're all playing it ourselves, getting a good sense of: is the quality of the game what we want it to be in terms of the gameplay experience, in terms of the features, when it works well? Then the other side of the coin, where it becomes trickier, is because we're an alpha product, we are releasing foundational technology into the game, into the wider audience. So for example, this one is the replication layer and the server split, which is the precursor to server meshing. 3.18 was another foundational moment, where we did persistent entity streaming. I don't believe it will be the same as 3.18 personally, but I'll soon find out. But when it comes to that foundational technology, similar to what I was discussing in terms of the interaction lag, when you put it to Evocati and then EPTU and PTU, we're only getting a fraction of concurrency compared to live. So when we're looking at some of the issues that are performance related and stability related, we might think we're golden, and then you go to a live audience and something else pops up that we're like, oh, this is a problem, we need to hotfix it, we need to evaluate it. We could spend the next two years just trying to get it to be absolutely bug free and then go live and it still have issues, because it's such foundational technology. It's not like we've bought something off the shelf and gone, slot it in, it works as intended, great. We're proving something out that's never been done before, or at least we've never done it before. So we need to make sure that when we're testing this, we test it as broad as possible. And then that is the balance between: okay, is the gameplay what we want it to be, but we might be introducing something that is potentially reducing stability or reducing performance. And when you look at reducing performance, that then has an impact on all the other things. So interaction lag, for example: people going up to doors and going, the doors are broken. Well, actually, no, that's just interaction lag. Your interaction's being backed up. Or the elevator's not working, or I'm stuck in my cockpit seat and I can't get out. It's not because your cockpit seat's broken. It's because the interaction was being absorbed and it was being queued in this giant queue trying to get through. So ultimately you have to look at all of these different parameters, the performance, the stability, the new technology that we need to test, and all of the gameplay side of things, and you have to make a judgement call about whether it's beneficial for us to put it into the live audience so that we can get as much feedback as possible, to then continue to work on it, to continue along the development pipeline towards where we ultimately want to be, which is: we've released server meshing, we can have servers that have got hundreds and thousands of players playing all together. So it's never as black and white as just, it's good enough, let's ship it. It's always about, okay, are we going to accept that we might run into more issues than we'd like to, but we need to do this to test this thing? And when we say testing a specific thing, it's also not about saying, oh, well, this issue was live on PTU. Sometimes that issue is live on PTU, but we don't know where it's coming from because it's so complex. That's the big one. And then it's like, well, we can keep putting speculative fixes in, and speculative fix and speculative fix, and optimize this area of the code and optimize this, and is it the networking? Is it the player interaction system? Is it game code? Sometimes you need to go broad to be able to find it, and I think that's where it's never as easy as it sounds.
I'm so happy you said that. That's the big thing that I think gets lost in the 'you should just let it cook' argument. It's that we can see this is broken, this is broken, this is broken. That's not the same as seeing the cause. And in order to find a solution, you have to find the cause. So we can see all these things, and we're looking at the same thing that our players are looking at, and see that, okay, that's broken, that's broken, that's broken. But we're not finding the root cause of it because concurrency is only at this level. So putting it on our live alpha environment, the big thing that environment can do for us, it stresses it to the point where now causes reveal themselves and solutions can be built.
Yes, exactly. And to be clear, we'd never push something out that was just broken across the board. We would never want to do that, because that would just be a poor experience. People would stop playing the game, and then we wouldn't get the concurrency for us to be able to find the issues. So we're always going to want to strike that balance: we are not a fully live, polished game. We are an alpha game, and we have to strike that balance with: we want to keep improving the game every patch so that people come to it and they enjoy the gameplay experience. I mean, that's my ultimate goal. But we still have these technology ambitions for us to be able to achieve the overall goal, and those are steps along the way, and this will be the same when we do server meshing. We will have scenarios with server meshing where it's such foundational technology that we will find things and we will fix them and fix them and fix them, but I can guarantee it right now, when we put server meshing live, we will find issues that either have been exacerbated by something or X, Y, Z. So that's just the nature of the beast.