TL;DRThe new flight model is functionally complete in Squadron 42, with no master modes, power-pip control and freeform quantum boost; the remaining work is bringing it into Star Citizen, including networking and multiplayer.
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.
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.
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.
TL;DRMission 2.0 is meant to let designers build robust, scalable content more easily, adding story scenarios, quest chains, persistence between logins, finer sharing and reward options, and better contract presentation.
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.
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...
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.
TL;DRArmor roles, Starwear and suit lockers are all in development and meant to arrive together, with decoration insurance expected to cover weapon racks and suit lockers, but no release timing is given.
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...
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?
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.
TL;DRMaelstrom is technically complete in Squadron 42 and is meant to replace the current armor system wholesale in Star Citizen, but still needs network integration and balancing, and is expected among the early features brought over.
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 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.
TL;DRThey attribute recurring mission breakage to huge content volume, complex interactions, missing automated regression testing and a brittle Mission 1.0 toolset, and say they plan more automated testing and focused robustness work.
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 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.
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.
TL;DRThey agree on the need to offload loot during Siege of Orison, are looking at item banks along the way possibly tied to local inventory, but the details are still undecided; it's something they'll look to add.
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.
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?
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.
TL;DRLogging out and back in at the same place is part of the plans, and the intention is to do everything possible to return players to the same position, whatever their scenario.
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.