Richard Tyrer

Yes. So the first good news is that the new flight model is fully complete, working in Squadron 42. There is no master modes. All the functionality you have at your fingertips is purely based on your engineering distribution. So if you want to have weapons powered at the same time as your quantum drive powered at the same time as radar, it's purely up to you. So you can manipulate your power pips to dictate how you want to fly. We also have the quantum boost functionality in quantum travel. So now there is no SCM and NAV. You just fly in the direction you want. Go where you want. You go max speed or not max speed. You can quantum boost at any moment. Quantum boost is, I have to say, incredible to use. You can use it in atmosphere. You can use it in space. It takes a short amount of time to charge up and go. When you are going, you're in this kind of quantum bubble light. You can actually steer and maneuver. You're obviously not going as fast as quantum travel at all, but it's giving you a much faster speed around and navigation. So if you're coming out of a landing zone and wanting to get up to an LEO station, you can trigger quantum boost and get there.

And it's freeform, right? You don't pick a destination?

No, it's freeform. So you can go into the black of space, quantum boost around a planet. And then obviously then we have quantum travel. So the new flight model, obviously it's been directed by Chris alongside myself. We're really happy with what's there in Squadron. We will be obviously then getting lots of feedback, which I think we've already had a few tests with players from Star Citizen. The work ahead of us is now transposing that flight model into Star Citizen with all of the necessary details and intricacies that Star Citizen brings, because obviously they're not a one-to-one gameplay experience. We know that.

Making sure it works in a networked environment as well. Make sure we don't introduce any new desyncs.

Yes, 100%. Things like bringing it over, making sure it works in a multiplayer environment, making sure it works in PvP, making sure it works in PvE, making sure it works for all careers: miners, bounty hunters, haulers. So we've spent a long time making sure that it is fun to use, it's intuitive to use, and ultimately has a lot of depth for the players who want to go in and manipulate how they want to set up their ship. They can do that. I think we're in a really good place. We'll still continue to get lots of feedback as we transpose into Star Citizen. But from a Squadron perspective, that flight model, which is what we want to become the foundation, is functionally complete.

The core ethos of what we call Mission 2.0 is essentially enabling our designers, or anyone in the company, to be able to create meaningful, scalable and robust content. So what do we mean by that? Let's talk about the intent first, as that pretty much solidifies the direction we want to take it to. So as Rich said in the 1.0 conversation, we're going to be having a main story, right? So the first part of that is our mission system will need to be able to create story scenarios, which influences NPCs or game world objects, animation, Track View events, dynamic events in the game world. So when we're telling story, that mission system can drive a lot of that. And currently, we don't have a lot of that functionality. The second major thing is we want to be able to do quest chains. So once you're progressing along that story, you want to be able to finish Story Mission 1, and then unlock Story Mission 2, etc. Again, functionality that we're missing currently right now.

And those quest chains retain or continue across logins.

We were going to get to that, but Rich, you're absolutely right. So jumping onto a little bit of the functionality outside of the intent, upgrading the capability of what we can do. Our first major one is obviously persistence between logins. Carl, you've picked up a mission. You log off for the night, the next day you still have that mission. You don't really care what had to happen on the back end for that mission to still be there in your contract manager the next day, but you want to log in the next day and see it there, ready to go, right? Also, other types of functionality we need is a deeper ability to specify mission sharing and rewards. So right now, as we've seen on a variety of our missions, participation or rewards being split equally are some issues that we wish we had a few more parameters on. So if you want to share a mission with someone and they want to receive some rewards, they have to do a certain amount of participation.

I think it's also really key to understand there that we want to encourage people to be able to play together. They shouldn't have to play together, but if they want to play together, we don't want to penalize them. So Mission 2.0 will give us the ability to allow players to come together without having to vie for individual rewards. They should be rewarded for playing together.

I mean, you've talked a lot about the player impact on Mission 2.0, but for me, it's all about the way that our content creation teams are working to create those missions, right? Our mission tools suite at the moment is very granular and detailed. Mission designers are essentially programming in our mission description tooling. And so they have to worry about way too many error handling cases, initialization, streaming race conditions and things like that. They have to uniquely and very specifically find all of the elements in the world that they need to work with for their mission. And Mission 2.0 is sending things to be much more building-block oriented and make it more declarative. The mission designer will declare what conditions and what environment and what objects they need to be able to work with, and then the mission system provides them with that. They don't have to go and find them and serialize them and worry about their loading and initialization order and things like that. So yeah, it's a big tech...

For everybody at home, that means those missions will be more robust, have less bugs, easier to find out.

There's a question later on that discusses that, so we'll talk about that in a bit.

Well, it means basically if you're a designer, you can focus on designing the content and not...

The gnarly edge case stuff.

Also, some other improvements outside of the way we're building is the presentation of that information. So as we work towards 1.0 and we're scaling the type of mission content, we need to be cleaner in terms of how we're presenting those contracts to the player. The ability to search or the ability to filter, things like that, will be very valuable. Also, the way you accept those missions. Right now, you open up the contract manager, you pick a contract and you're good to go. On the story missions, they'll call you up, they'll enroll you into that mission.

There's also a couple of things there. We want to be able to tell people what tools they need to take on that mission, whether they need a multi-tool or whether they need a specific ship. Also rewards, outlining what rewards they'll get. So a lot of functionality, both from the back-end side for developers to be able to make more robust missions and more complicated missions, all the way to the front end, from the players experiencing that mission, both from a point of view of as soon as they pick up the contract versus playing through the mission and obviously then the rewards at the end. So yeah, there's a lot coming, I think, with Mission 2.0, which is going to be good.

So in a nutshell, Mission 2.0 is essentially an umbrella term we use that affects everything from where we're heading to the way we're building to almost how the engine works. So it's a big initiative.

So essentially engineering is something that we're always looking at and making adjustments to. I'd say the current balance isn't necessarily where we'd want it to be, which is why we're continuing to iterate on it.

The standpoint right now from an engineering perspective, I think, is to let everybody know that it's not where we want it to be. It's not the finished product. The intention with engineering, like we've always wanted it to be, is for it to extend the life of your ship. And with that comes the opportunity for players to engage in further activities to be able to do that. I think right now the balance of fire is probably a bit underwhelming with what we want it to be. The problem that we have trying to achieve the true full scope of engineering is that there are other features around it that need to come into play. But I think that we will definitely be balancing engineering over the next year to make sure that we are getting that tuning right on the base functionality. And like I said, when the new flight model comes in, engineering will be the way that you manipulate and utilize your ship, both from a single-seater all the way up to a capital-class ship. So there's definitely things for us to do there. But at least that's the current standard. But I know that you wanted to take us through some of the future.

We can elaborate on a bit more. So let's talk about soft death a little bit. So when you're fighting specifically AI ships, the soft death tuning is also, I wouldn't consider, where we want it to be. And what I mean by that is right now, there's a high likelihood that they would just explode. So we want AI ships that you're fighting to explode if a component goes critical. But then you also don't want a ship to be dead in the water and the mission still requiring you to take it out. So we'll be adding a few more callbacks on a mission point to be able to understand certain scenarios where it will consider that ship no longer part of the mission requirement, which I think will help. Another part of that is once the ship is soft-deathed, we want to be incentivizing more dynamic content. And what I mean by that is cargo manifests right now are also built through the mission. So obviously that's not very scalable. It requires every mission to be prescribed explicitly in terms of the manifests, whereas really we want that on ship archetypes. So basically when you come across an AI ship in the wilderness, that will have its cargo manifest, and that means we can create more dynamic scenarios. We're also going to be looking at the bug on the MFD screen. So when you scan that ship, you'll get more of a comprehensive and legible readout, again, to further give you the information you need about whether you want to...

You want to be able to go into combat, fight an AI ship, and some of the ships might be worn and heavily worn, poor components, and then they blow up. But some ships should also, like you said, soft death, and then you should be able to use that as part of the reward for that mission and be able to go and salvage it, take its components. Does it have cargo on board? And obviously radar should be able to give you some of that information and be able to play the game. That's where we want it to be. We're not there yet, but I think that's still a good vision for us to work towards. The development needs to be faster. We need to get more iterations into the players' hands. I think nobody's happy with the pace of development that we want to push towards on these iterative features, and it's definitely something that we're going to be moving towards. And that's coming back to Mission 2.0. The reason why we're investing time into Mission 2.0 is to help make the development faster, so that we can focus the engineers not on helping the designers to fix mission bugs, but come and help us iterate on engineering. We're well aware that we want to be improving on that front, and it's something that we will do.

Ah, so storage and ships. So this is one of the ones where we talked about having it split into three sub-features. We have Starwear, suit lockers, and then there's...

FPS Armor 2.0.

Yeah, exactly. So it's FPS Armor 2.0. So we are working on all three of those things. We want them to come as a cohesive unit. So if I touch on FPS Armor 2.0, in a nutshell, that is the armor roles that I've talked about in the past. We still want to do that. We still want to have heavy armors be G resistance.

And for the system that brings all of this together, we actually did the pre-production of that earlier this year. I just didn't quite get to starting the work.

Yeah, so all of that work is all these little things. It's not this one Goliath feature. It's all these little things for Armor 2.0. So we are slowly chipping away and knocking each one of those down. And then obviously, how does that tie into suit lockers and Starwear? Well, Starwear is the ability to customize your character so that you're not having to wear just a single undersuit and then armor on top, and you're very limited. I've actually played a full version with Starwear. That's almost finished. I've had sunglasses under my helmet. I've been wearing boots on top of my... It was great. But how does suit lockers tie into that? Suit lockers is the way that you save that loadout. So then you can go into your ship and you can be like, this is my radiation package, this is my FPS package, this is my flight suit package. And that should just be a single interaction. You're going in, single interaction, you're now... I've got a different loadout than the loadout that I was in. That should be removing friction so that you can quickly switch between play styles. And obviously, we're working on all three of those. And the big thing with suit lockers, which everyone will obviously want to know, is that insurance, tier three insurance, which includes decorations, would also include weapon racks and suit lockers. So if you are setting up all of your ship and you're filling all of the lockers or the weapon racks or the food goop for your kitchen or your medical goop for your imprint or your medical bay, all of that will be covered under the decorations insurance. So you'll be able to pull it back and decorate your hub or your ship as you see fit, which... what was that guy's name?

So we saw an outstanding video internally. It was incredible. We watched it last week. So that was by John Claude Van Wick.

It was a great video, right? I mean, he had an Idris in the upper hangar. He set up all of the weapon displays and you could go in. That's what we want to see. We want people to be able to customize their ships. We want people to have a home away from home. That is the design. We are absolutely going to deliver that. We are working on those features and it will come.

Maelstrom, okay. So similar to the flight model, Maelstrom is technically complete within Squadron 42. All of the combat, all of the ships, all of our props in the environment are set up with Maelstrom. They all break apart. I mean, the Maelstrom on the ships is fantastic. The challenge ahead of us now is then transposing that into Star Citizen. Obviously Star Citizen is a lot broader, has a lot more, 200-plus ships in Star Citizen, a lot more scope. So obviously it will be the same system, but it will need to be network compliant. It will need to make sure that it's working in all the conditions that we need it from a gameplay perspective and a balance perspective. That will replace the current armor system wholesale. Damage is fully enabled with Maelstrom, so it takes the weight of the bullet, the projectile speed, the type of the bullet, whether it's an energy or ballistic. It calculates the kinetic force on impact. That is all working. All of the physics has been calculated. So that is fully complete in Squadron. Now it's about bringing it over to Star Citizen. And as Squadron moves towards its release, more and more resources, more and more gameplay features will come over. Similar to how we did a big push in 3.23, we brought those features over, we'll be bringing over another tranche of features, which is Flight Model and Maelstrom.

Maelstrom's going to be one of the earliest ones that we look to bring over, right? Because it's quite a chunky piece of tech, and it's going to need some integration with our network model.

I've seen it. I've played it. It is a very different experience based on the armor system currently. So that's exciting.

I won't go on too long about Maelstrom, but the biggest thing is just the feedback that you get when you're shooting a ship. It breaks up much more granularly. You get that feedback that you're actually making progress, that you're removing bits off it. You see bits of wing come off. You see bits of the ailerons come off. You get to see the visual progress.

It's that tangible feedback right from your cockpit, right? And that is game-changing.

Good ideas, great minds think alike. So the expectation with medical is that when you die, you will have multiple options for you to be able to choose from. So you should be able to have your main hospital location, depending on where you want to imprint. You should be able to in the future also have a location for your base. You should be able to have a ship location. So there's like three permanent locations that you'll be able to imprint. And on death, you will be able to choose which one you want to go to, if you've got a specific ship, if you've got a specific base or a specific location.

Or if you've been camped, you can go back to what you want.

You can choose. Then you should also have access to some transient locations. So for example, if you're in one of our large mission operations where you want to be, say, in a line of mine, or you want to be able to respawn at a location, you'll be able to log that imprint, and that will be a temporary imprint that you'll be able to switch back and forth, and vice versa. You'll be able to also have a temporary imprint on somebody else's ship. So you should have these options available to you, and you can choose which location you respawn. And obviously once we've done the Death of a Spaceman in terms of the DNA integrity that ties into your respawn mechanic, that will obviously have wider ramifications depending on where you actually respawn and the tier of the bed and the facilities. But that's what we want. That's been the decision. We've had that design and vision for a long time, and we still want to do that, and we will be bringing that to you in a future update.

It's a good question. I had the same question when I joined the company a few months ago.

Well, why don't you take this one, Carl?

Yeah, I think there's two parts to this question, or two parts to the answer to this question. The first part, and I think the most pertinent part, is what Benoit, our CTO, mentioned, which is a huge scale of volume of content and a huge level of combinatorial complexity of that content with different gameplay systems and features, paired with a lack of validation testing. He talked a lot about our lack of a robust suite of being able to test, validate, pre-submit the work that somebody's doing, working fine for the content and the feature that they're working on, but is not going to regress something that was made seven years ago or what have you, right? Or even seven weeks ago. But that's the thing, right? So once something is released, it goes into the pot of this huge volume of content that we have. And just the scale and combinatorial complexity of all of that integrating together means that we run a pretty high risk of a change not being compatible with something that was released a while ago or fairly recently.

So what are we doing to stop it?

So essentially what we need to do is leverage more automated testing and more tooling around, whether it's gameplay feature development or especially our content development tools, to basically be able to sweep through a suite of all of our content and do some basic regression testing on all of those systems.

The next bit, I'm assuming you're going to talk about the declarative model.

Yeah. The other thing is obviously this person was directly referencing missions. Missions specifically have an additional challenge, which is the complexity of the tooling that we have around our current Mission 1.0, let's say, means that the resulting mission flows and the logic setups and all the things that we just talked about, like finding all the entities, collecting them all together, dealing with streaming race conditions, having to put things into the mission logic to deal with things like server crash recovery and things like that, it results in a very brittle system.

I mean, a good example of this going wrong in some respects is Race for Stanton. What was interesting about that was, for some reason, the way that the mission system interacted with the back-end systems, it funneled everybody to this prologue mission or setup mission to one location. And nobody wanted that. It didn't happen in our own testing because we didn't have enough concurrency. And then when it goes live and the live environment is slightly different, it then funneled everyone, and it's like day one, oh. What? And it makes it poor for the player. It makes it a poor experience for us, because people have spent a long time trying to make the content and get it out live. So that's something that, none of these issues do we want. We want to be adding new content to the game, and every patch should make the game better than previously. And that's something that we're very well aware of and we want to improve on. And we have taken steps, like you said, in terms of refactoring some of these large systems, but we've also taken steps into highlighting these individual areas within the game or development in terms of buckets. So we've talked about the first hour for a new player. We've talked about quantum. We've talked about freight elevators, hangars, and taking those and really doubling down on making sure that they are robust within a short time frame. So yes, I think that is a great question. We're very well aware of the status of the game. Our community is very vocal and we are thankful for that. We want to say that we are taking that on board, and absolutely we will be improving on that going forward.

Isn't it fun when the community highlights something that we internally have had a lot of conversations about?

So essentially, yeah, that's a great question. It's a very pertinent question right now. So ultimately, we completely agree on this. We've been talking about it a lot with Rich internally. The ability to unload your hard-earned loot throughout the mission is something that we're looking into, whether that is item banks along the way at the various medical facilities throughout. Does that tie into my local inventory in Orison? I remember we were speaking with Jens about that. So the nuance about how that would work, we're still looking into, but it's something we'll be looking to add.

I was just going to say, because we have to basically reconcile that with the fact that Siege of Orison is instanced content, right? That's using new technology.

So you'd be communicating from your inventory in an instance to your inventory in your, if your home location was Orison.

Looting is also, just in general, we want looting to be less friction. So we want people, if they go in and spend their time working on a specific operation or specific series of missions, we want people to be able to be rewarded, and it's not great when you do all the effort and then you don't get the reward. So yes, we definitely will be looking into that. And in some respects... I don't think we had a crafting question, did we?

Not yet.

Okay, so a tidbit for crafting. We're going off piste. Yes, for crafting and refinery, this also comes with respecting people's time. We want to make sure that if you are searching and you spend a period of time finding ore of a specific quality, you should, at the end of that period of time, feel like you've made progress to what you want to do. And I know at the moment it's a bit too random. And we want people to be able to take some of those ores and then put them together and then obviously refine them to higher quality ores. So that is something that we will be touching on. And I think it all ties into this same overarching message when it comes to the time that you put in the game. You should be rewarded for that time, whether that is through credits, whether that's through reputation, whether that's through gaining access to a new ship, or whether that's for crafting materials. We want you to be utilizing your time and being rewarded. You've moved forwards during that play session. I don't want to be in a situation, and I've used this example many times before, I used to do end-game raiding when WoW first came out. And I used to do the roll call for all the mages. And I would have people be like, I can't afford to come on the raid because I can't afford the repair costs for my gear. And that sucked. So I don't want that. I know Chris doesn't want that. So we're not going to make it like that. So we want to make sure that if you put in the time, you should be rewarded for that. And that is part of that bigger vision.

So that's a great question. So absolutely, that's part of our plans. The ability to log out and log back in in place is something that you've talked about before, Rich. Chris has talked about it. It's definitely in the plan. How that works if we're in a party and how that works if we're in a ship? Well, I think...

An easier way to describe it, because I think there's lots of different permutations that you could be in: okay, what happens if I'm on a different shard or I'm on a different server, or I'm in space or I'm not in space and my ship's docked. Ultimately, the intention that we want to get across is if you log off in whatever scenario that you're in and then you log back on, we want to do everything possible to try and put you back in that same position.

You want to try and go as far as you can.

I don't go home very often. So that's one. Ultimately, I've set up hierarchies on both of those teams to be able to work independently of me when I'm not there. But I spend a lot of time reviewing both sides, from Squadron and Star Citizen. And if they were very different games, it would be a very different beast, but obviously they share the same features, they share the same aspects that we want to get from the games. They're obviously different content, but I have to work with Rick and JJ. All three of us were on the core gameplay pillar and then we did Squadron and then we've done SC, so we've kind of all been all together. You have to build up the teams to understand that they can... give them the authority to be able to deliver on decisions and make those decisions, and you trust those people to do that. And then ultimately I'll be reviewing the game and give my feedback. But yeah, it's a lot of meetings and a lot of discussions, but it's very enjoyable.

A bit of both. Whenever there's a new design, we all come together and make sure that we're all on the same page, and then we kind of split off and divide it up amongst ourselves to get it done.

Yeah, the biggest thing is that it's something I've been very cognizant of. I've always wanted to make sure that we're a trio of partnerships, to make sure that we're all on the same page, because we've got such a large team. We want to make sure that we're giving consistent messaging to the team that we're working on. So any new designs or anything new or any new content will always have an initial brief amongst ourselves before it propagates wide. But then, as Rick says, we definitely do divide and conquer. So JJ tends to look at the events and work with Elliot on Mission Feature Team and System Design. Rick is obviously more technical and, from a technical background, is working with Joe on the tech design team. And then obviously myself is more broad, but we definitely divide and conquer to help. But it's never isolation. We always come back and spread out again and come back and spread out again. And we've all got different expertise in different areas, so it works well as a team.

Yeah, we're all sat right next to each other. There's not a day goes by we're not talking to each other.

I'll take that one. So we've got Space Cow and also Space Whale, and aside from the cool names, we've also got Space Worm, all these really cool creatures that we're working on in the background, but each of those has their own unique challenges that are going to take a little bit longer to get out. So with the Kopion, we picked a creature that we knew was going to fit some of the early missions that we wanted to do, a ground predator, land-based, that we could get in the game within the timeframe that we had. And then the other cool thing is the Marok is our first boid. And our boid technology is something that will allow us to scale the number of creatures that we can have on planets in the future. So it's exciting to test that feature early.

Yeah, and just to summarize what a boid is, if you're not aware, in very simple terms, it's basically a lightweight AI. So you have a human AI, which is fully fledged combat, what people have been familiar with in 3.22 and previous. A Kopion is the equivalent of a human AI in terms of its complexity, in terms of its animation, sounds. A boid is kind of just a lighter version of that. So obviously a bird doesn't have all of the same parameters. A fish, for example, would be a boid. So anything that's got flocking, that you want to have as a group, flocking together. It's just a simpler implementation. So as Rick says, they were two creatures that allowed us to hit the things that we wanted to hit. It doesn't mean that we're not going to push the Quasi Grazer and the space whale further down the line or into the game at some point. These two were good ones that we needed to get out from a technology standpoint.

So we wanted to basically review a bunch of our major items in the game. So looking at armor, weapons, ships, and basically start to apply more logic to why they are being priced that way. We started with the weapons and armor, basically. So we started looking at things like applying value to different aspects of them. So looking at pure size and associating a rough material cost: a pistol is obviously going to be less material cost than a bigger rifle or a shotgun or something that's a bit chunkier. So obviously there is a weight of value associated with that. Then also looking at things like manufacturers, because some of them have a manufacturing quality associated with them, or a prestige. Looking at the different tech levels: we've got some very basic ballistic weapons and we've got some very advanced electron or laser weapons that are going to have manufacturing costs associated with them. So people can go to the shop and look at the different weapons against each other and go, oh, okay, this makes logical sense, because this is rarer, or this looks more expensive and feels more expensive to use. And we did the same thing with the armor too.

Then we started looking at some of the bigger ticket items like our ships. So again, we applied very similar logic to those, where we go, okay, let's look at the size. Let's look at how they're being used. Are they used to make money? Because if you think about a commercial vehicle in the real world, typically they cost more because you're going to be able to make money with them. And then looking at manufacturers, quality: is it a luxury ship? That then applies more value as well. And then obviously weighing that up against the actual prices that you're paying real money for as well, and making sure there's an association there as well. And that also allowed us to look at a lot of the outliers that we had previously and go, oh, okay, some of them are sitting way far above everything else for some reason, and some of them are sitting way far below everything else. So it's been a way of leveling it out and applying logic to a lot of that stuff as well.

There were a couple of other things that we looked at too. We also looked at balancing salvage out, because I think that had not had a thorough pass before, and we saw people just getting millions upon millions of UEC through salvaging. So we felt that that was basically flooding our economy with alpha UEC, and that was causing problems: the value of things just goes down so much, and it becomes meaningless when you can exploit a system like that. So we've applied some more logic to that and brought the gains down on what you can get from salvage. And then we also took a look at balancing mission rewards. So instead of everyone having to default to salvage to make money, we're now looking at the effort versus reward algorithm that we're applying to our missions and basically going, hey, how much effort, how much risk, how difficult are they? What are you putting into these missions? Is it super difficult? Okay, you should earn more money from it. Is it long? You should probably earn more money from it as well. So overall, things should feel a bit more as you would expect.

And this isn't the end of that tuning in 3.23.

No, this is just the first pass. Well, the next pass anyway.

Yeah, on that note for economy, I think I touched on this in the Letter from the Chairman. I think a lot of these systems have been around for a long time, like claim timers, insurance, obviously the economy values for missions. And they were balanced correctly as and when they were done a long time ago. The game's been out for a long time. But we need to start bringing these systems a bit more cohesion in how they talk to each other. So going forward, I think the players and the community should expect to see some significant changes to those systems as we move towards trying to create a more cohesive experience in the game. Because I think right now, if you just take 3.22 as a good example, if you really know where to go, like JJ said, you can just make millions upon millions. And once you've got so much money and everything is linked to progression with money, you can just buy your way and that's it, right? You lose the desire or the motivation to keep playing the game. So I think we want to build that motivation in, that, okay, I'll go and do this because I enjoy doing salvage and it gives me this reward. And then obviously the other side of the coin is we don't really have a lot of money sinks in the game right now. So in terms of insurance, your ship blows up, you just claim it back immediately. You die... we've talked about Death of a Spaceman for a long time, but we want to start bringing all these systems in place. And I think going forward, we will have some more changes on that front.

Yes, so we're going to look to wipe alpha UEC and rentals, I believe. And that's purely because if we don't, all of the analytics that we get back from people playing the game are going to be basically false reports, because people are going to be using all of their banked cash and it'll just be like, oh, people are just buying all of these now more expensive items, for example, and that then tells us, oh, do we need to make these more expensive? No, not really. It's just that people are using giant cash reserves that they've been keeping for a long time. So while it might be disappointing for some people to lose the money they've built up, it really helps us in informing us: have we pushed the economy in the right direction, so we can keep making iterations and informed decisions going forward.

And that's a good thing to note as well: we're a live game. Just because we changed the prices in 3.23 doesn't mean we'll then change them in 4.0. We want to put them in; this is our first rebalance or re-leveler. We'll evaluate, and that's why we want to do that. We'll evaluate, okay, look at the data, and then base our next decisions on that data.

Rep-based hostility wasn't really for 3.23 so much as future. It's setting us up for success in 4.0 and Pyro and the systems that we want to do there. The system itself is cool. It allows us to set up factions that you can gain rep with, and they become your allies and help you out and come to your aid when you're being attacked. And vice versa, you can piss somebody off and they're mad at you and they'll attack you on sight. You're not going to see a lot of that implemented in Stanton right now, but we wanted to get it in so we could start testing it in Stanton ahead of Pyro. The first place we want to do it is in Grim Hex. We're planning to set that up as a neutral zone in the near future, so we'll see more of it then.

And we do have some settlements, I believe, with the Dusters faction in 3.23, where if you do encounter them, the AI are neutral to you. So you might have a delivery mission to that settlement; they won't attack you unless you attack them. So there is some small instance where, like Rick says, we're testing out that feature, and then it's really more of laying the groundwork for the future.

We just need more feedback on that feature as we continue to roll it out.

Well, first off, I think, the fact that we're working on a live game, the issue is that we should always be looking at, even if we've got a system that's out in the wild, evaluating it: does it deliver the gameplay that we want, that the community wants, that Chris wants? So when we looked at the combat as a whole, and we're talking a long time ago now, I was probably still on Star Citizen, it was probably pre-Squadron when we started talking about Master Modes. A lot of the combat that we saw across the broad spectrum of the community, not just the new players and not just the very well experienced players, but the broad spectrum, basically became jousting, and we felt that we could do better than that. Now, I know that there's a lot of discussion points around Master Modes where we're talking about lowering the ceiling cap. That was never the intention; that's not our inspiration. Our intention really is to try and create a system that is fair to use for all players, that allows players to come on and still feel like they can engage in the game and compete, but still reward the very best pilots. And Master Modes, the iteration that it is today, has been through probably 20, 25 iterations of different tweaks and changes, and we want to try this and we want to try this. And even the iteration that we're going live with in 3.23, that's not the end. That's just the beginning of that process. We will put it live. I already had a meeting literally this morning to discuss with Yogi spool times between SCM and NAV, or what are we going to do with snub fighters that don't have a quantum drive? Do they have a NAV mode? And I was like, well, yeah, they should do. So the expectation is that Master Modes came from the goal to try and improve the overall flight experience for both combat and non-combat in the game, so that if you want to be a space trucker, that's cool, you can switch in, or if you want to be a trader or a miner or combat. So it's about taking something and making it accessible to new players, that has a lot of depth for existing players to then take advantage of. And really, that was the inspiration. There's never really a moment in time where you start going, this is a problem, we just need to fix it. It's more about you evaluate these systems over a longer period of time and then start to think of solutions about how to improve it. And then those solutions grow and grow into a new system that you go, oh, this could be a solution that we could do. And with Master Modes, you mentioned all the times that we've talked about it, but we've also done several tests with the community before we've even got here, outside of just the 3.23 Evocati and PTU. We tested it in Arena Commander. We tested it with players a long time ago. So this is the result of a lot of effort and work by a lot of people to get it where we are now. And I believe in it. And now it's about getting it to the broader audience, and then we evaluate that feedback and we tweak it and tune it and get it to where we think it could be. Because I think you always have to change the foundation before you can start. You either have to do revolution or evolution. And I think with the previous system, the evolution wasn't going to give us what we wanted from the end result. So we had to go slightly back a bit to then go forward.

To be honest, I've been playing Master Modes for a long time in Squadron, getting a feel for it. Does it feel right? Sometimes you have to sit with a feature and play it and get the everyday scenario. You can't just take half an hour and go, oh yeah, it's approved. You have to play the game and play it for yourself in all the different scenarios and then make a judgment, and then get that feedback, and then we can tweak and improve.

I think the interesting thing as well is, because it's been going for quite a while and obviously we've been playing it internally a lot, we've had a lot of very passionate pilots, aces and pilots at the company, who at first felt averse to the change, like some people in the community are as well. But it's been amazing seeing them playing with it, spending time with it, and coming around on it and going, actually, this is really fun. I prefer this now. So it's been very cool seeing that process happen internally, and it's going to be interesting to see how it develops in SC as well.

Well, first off, we're evaluating all of the analytics that we get back. There's obviously the Issue Council reports that are very useful for us, that people go out of their way and spend their free time testing the game and working on the game for us and giving us the Issue Council reports that we take in. We also obviously have our own internal teams evaluating that. And the interaction lag itself seems to be linked to the network side of things, where the network is getting throttled, and it's essentially related to the RL and the server separation. So it's something that obviously we haven't experienced before in 3.22, but it's been very tricky to try and find out what is causing that problem. And one of the biggest things that we've seen that exacerbates that problem is when the server performance dips below a certain value; that's when it starts to back up. So there wasn't really any silver bullet. There never really is when it gets to things like performance. It's always death by a thousand cuts. So when we're looking at the interaction lag, we've had pretty much a lot of our top engineers from both the Core Technology Group and the gameplay side looking at performance improvements that we can do to basically mitigate the interaction lag as much as possible. And I think in the last EPTU or PTU that we went to previously, it was very minimal. Because obviously we catch all these reports; we have debugging in there that captures all of the data, and that debug actually creates performance problems for us because it slows down the performance. We don't get that debug in live. So we think we've got it, and we think we've done enough to make it so that we're not seeing it anymore in the PTU reports. There are obviously still certain bugs and things that might appear as interaction lag and are not interaction lag. And when you come to performance, it's never black and white, unless you find something like, oh, this ship is intercolliding with a wall and it's causing massive amounts of stalling. But the interaction lag was just one of those ones that was very difficult to track down. And fingers crossed, we think we have done that, but only time will tell.

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.