Why not scale back some features until the game gets into a more playable state?asked by Tech Travis

That is always the question. I feel like we ask ourselves that question internally every single week. That's the constant challenge. Folks expect a patch, and then folks expect a certain threshold of content to be in that patch. None of that determines how fast a project gets developed, how fast a feature gets successfully built, how fast bugs are found and destroyed and whatnot. And that's what we talked about earlier. Sometimes when it's a thing that's egregious and we can do it, like ship trespass, we pull it out. And sometimes you go forward, and it's like, we think this is in a place where it can still generate good feedback. We think it's in a place where it can still be useful for testing, where it can still be useful for analytics and stuff. So even though it's not perfect, we still put it out there, because it serves a purpose to our game development to get it out there and to get it in the hands of players. And I hear this conversation constantly, there's always this back and forth between whether that should be pulled, or whether that should go in with just a little more pillowing around to make it safer. It's the forever challenge, right?

We've done something similar for 3.19 when we introduced the ability for tractor beams to remove and reattach items. We knew that there would be issues with some of the ships because they're not up to gold standard yet. But we accepted that as a risk, because we felt the feature was in a good enough state that it would add so much more value to the current game. We now have the ability, when you go out for a salvage contract, to find loot and strip the ships of their components and make some cash on the side, right? Or re-equip missiles for some of your vehicles. There was value in just pushing forward and not scaling back and not saying, okay, let's get all these ships sorted out and hold the feature from getting released. We felt like it was the right call at that time.

It's that same debate. It's the debate that's going on in Twitch chat right now. It's whether a thing should go out, whether a thing should be held back. Oh, that's too many things being held back, now the patch has to be delayed so we get more stuff in. But if you delay the patch too much, I thought we were going to pull things out so we didn't have to delay the patch. It's just this constant, never-ending shifting of levers.

Part of that too, going back to what a producer's role is in all this: every single one of those things, putting out new features, addressing stability and performance issues, bug fixing and releasing patches, the events we do every year, preparing for CitizenCon, these are all goals that are set by our business leaders. They set the goals. This is what we want to do. What they don't know is, if they come in and say, hey, this is a new initiative we want to do for this next release, how does that impact everything else we were already planning on doing, right? So as a producer, a new request comes down. How does that impact the current state of things? And something that I feel like we've improved at over the years, but still could very much improve on, just full disclosure here, is better communicating impacts: this new thing came in, here's what that impact might be. We want this new feature. Okay, well, do you realize by requesting that new feature, it means this team's allocation towards quality of life and bug fixing actually shrinks? Was that something that we were aware of? And often that's not the case. So we have to be better at communicating that as well. And I would say over the years, we've improved at that leaps and bounds from where we were four, five, six years ago, right? But we can always do better at that. So I'd say that is something we're constantly assessing: of all these things we're trying to juggle, which thing is the most important at any given time? Because that does change quarter to quarter. And essentially, what would we lose by focusing on this versus that, and that sort of analysis and what I call scenario building: if we do this, then that means this; if we do that, that means that. That's the communication management aspect of this, right, where you come in and here's the impact, do you want to go left, do you want to go right, and then hopefully we can help our business leaders make a more intelligent decision that way.