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;DRThey say engineering balance isn't where they want it, plan to keep tuning it over the next year, and want AI soft-death and cargo changes, while admitting development needs to be faster.
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.
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;DRThe intention is for players to choose on death between several permanent respawn locations (hospital, base, ship) plus temporary ones, which they say will come in a future update with no date given.
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.
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.
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.
TL;DRNo other Stanton planets or moons get volumetric clouds in 3.14 because the work focused on Crusader, though it is something they are looking at for the future.
So the short and disappointing answer is no, but let's break down maybe why. Originally, Carsten and the team were prototyping on a moon or a smaller planet as a starting off point, but it became clear that we just needed to focus on Crusader itself, focus the tech development on that and just specifically look at that just for this release. So it was for a particular reason to just focus on one, just because when you're above the clouds or going in the clouds, you can just focus on that. Also, the scale, right? The scale is a unique thing. Also, part of the conversation as well, as soon as you're putting clouds on a planet or a moon, there's a lot of additional factors that you're going to need to consider, right? Like the occlusion that you'd get from the sun. So there's just a lot of extra stuff that we need to kind of consider. So unfortunately, not for 3.14, but it's something we're looking at for the future.
TL;DRNot biomes in the traditional sense, but Crusader's clouds vary vertically, from wisps at the top through canyon-like wind-stretched clouds to an enclosed cavernous layer above a hard deck.
Let's see, in the traditional sense, biome implies it's a different asset pack, ties into the flora and fauna that you'd expect there. But one interesting part of the development of Crusader is one of the things that the tech allowed us to do is to have not a variety of visual designs spread horizontally across the planet, but we have a variety of visual designs spread vertically. So on the video last night that went out, people could see a slight glimpse of the variety there. So because it's texture driven, we were able to design a format where on the very top, around where Orison is, you have some wisps above the player that catch the light, that gives you that classic skybox vibe. But then if you go down one step below, we were able to create these kind of canyons. We wanted to describe the effect of wind. Wind is the unsung hero across everything to do with Crusader and Orison. It drives everything. So we wanted that feeling where these winds have stretched the clouds. So you have a kind of a ravine. And then lastly, on the bottom, you can actually get into a cavernous space where you're completely enclosed in cloud, but it feels like you've gone down really, really deep. And then below that, it's the hard deck. From there on in, you're just going into clouds, and then that will kind of limit the play space. So in a more traditional sense, no, but actually, I think, yes. And in the future, Todd and I were discussing that we want that to tie into a variety of play space, a variety of gameplay experiences dependent on that depth.
TL;DRIan Leyland says Crusader's hardest parts were the huge scale and building new volumetric cloud tech with a specific look, while Orison's floating latticework looked bad in game at first and took hard work to fix.
It turns out making a gas giant is hard, right? Well, let's see. So we started off by seeing how far we could get with the current tech. I think the last time I spoke with you, Jared, we were like, okay, we'll see what we can do. Abuse the rules, see what can happen. I think we got pretty far. We showed it to Chris and Chris was like, nope, we're missing the volumetric clouds, right? So the focus then turned into the volumetric clouds. But whenever you create something for the first time, it's always hard because it's the first thing. You've got to go through that process of trial and error. So with something like the gas giant, instantly the scale was the hardest part. For example, the radius of Crusader is, I think, about 7,500 kilometers, right? And, for example, Hurston is like 1,000, or one of the moons is maybe 300. So it's considerably larger. So with that scale, when the player flies in, you come up with a design and then you fly into it and you don't see anything move. So instantly that scale became the first thing that became a concern. And then second is just, we've never made a gas giant before, and you can look at fantastic satellite imagery, but we wanted to do something that was a little bit different. Chris had a very specific look in mind for Crusader that we wanted to achieve. And remember, like I said, that sort of feeling that wind has blown these clouds over the surface, so we wanted a particular look. So then the tech develops, and then Carsten, and Seb did a fantastic job as our principal tech artist of being that communicator between the art team and the tech team and translating what features we would need and how the tech works. So like I said, there's a lot of trial and error there. But then once you start doing look development, you start getting something. There was one day, OK, it was like, cool, this is working. And then Jake, who's previously been responsible for the space gas and the gas pockets and stuff in the game right now, he just had a little play, right? He was just very curious. He took the tech and then he tried something out and instantly it was like, that's Crusader. He hit it. The man was talking about the layer in. He just tried something out. We all looked at him and were like, that's fantastic. So Seb kind of took it from there and stabilized it. But it was quite a difficult journey just because it was the first thing for the game and it's brand new tech, right? So I kind of see it where, where we were a few years back in terms of planets, if you look at how they've developed and grown and increased in fidelity, it might give a good example of where we are right now with this new bit of tech.
And then for Orison, this is a classic example of taking a concept art that you look at and go, that's just going to be the best. Orison was always my favorite of the Stanton locations. I fell in love with Orison a long time ago. I looked at the concept art. And guess what? We put that blockout in game and it was like, this looks horrible. Horrible. Turns out a floating latticework in the sky with thin struts doesn't translate well from concept art into game. It tested us as a team. It tested us. But I think I speak for the team: through hard work, passion, dedication, just trying ideas, trying things, what we ended up with, we're quite happy with.
I sit in on those Tuesday reviews every week, and I remember a year ago, the first early tests of Orison and that latticework that you were talking about, and going, I don't know how he's going to do that. That doesn't look like it's working.
Yeah, it was a definite... okay. We had to fight for every win on Orison. Although we came with the experience of making previous LZs and previous modular locations, it tested the team to the fullest. But I think they did a fantastic job.
TL;DRCloud movement is the biggest missing piece, along with ongoing performance, quality, lighting and player interaction improvements, and eventually removing the hard deck so depth depends on the ship.
Well, let's see. Probably the biggest one is movement. See, I always wanted this feeling like it's an evolving landscape, and we always talked about the idea that it'd be cool to, sometimes you go to Orison and you're just in a cloud, right? Or other times it's nice and open. Obviously, the focus was on the core version of that tech. Movement is obviously an adaptation of that tech. So it's a shame it didn't make the first release, but it's something we're looking forward to in the future. Performance is going to be ongoing, but also that, combined with quality. With crazy drops of tech like this, obviously, it takes years, right? It usually takes years. It's very rare that people get to see tech so early in development. So quality and performance, seeing those two increase, obviously will be coming in soon. Also lighting and player interaction, more complexity there. So like I said, the analogy I gave for the gas giant: it's the first one. We're going to have many more gas giants in the game, but we'll see this improve. So it's going to hopefully follow a similar sort of evolution format to what we've been doing with our planets.
Regarding the Crusader aspect as well, right now, as Ian had talked about before, we have kind of a no-fly zone. Now, eventually, the idea would be that there's not necessarily a hard deck. It's really kind of what your ship allows, how much atmospheric pressure is associated with it. And so that's one of the things that I know Dan's team is currently looking at and starting on. So eventually, that will be released with basically the gas giants.
TL;DRThe focus is only on Orison for now, but its open, hierarchical setup means additional platforms or locations could be added later, and placing things on opposite sides of Crusader is something they'll look into.
The focus is exclusively on Orison; that's the major landing zone on that gas giant. But what's interesting, right, is, remember what I said right back at the beginning, building Orison was hard. It came with certain challenges, where on previous LZs, you had terrain for the player to land on and get out and experience the location. Whereas we didn't really have that option there. So right from the very early stages, we were like, and it's kind of listening to the community as well, they don't want restricted areas. They want to make those decisions. So right from the get-go, we're like, how do we make this? So it is almost exclusively open for the player. So when you look around Orison and the entire stretch of it, I think there's two restricted areas, and they're around the commercial area and the industrial platform, just because of the social spaces, right? It's to stop griefing, but everything else is open. So to answer your question, basically, when you look at the latticework, think about it as a hierarchical OC system, whereby, okay, it's a habitation platform, and then within that habitation platform, you have the buildings, and then within those buildings, there's rooftop OCs, and there's going to be the building interiors that Todd mentioned before. So the way in which we've built it, if we wanted to create sister platforms or additional platforms or additional locations in the future, those OCs are already made. And when people do get to fly around Orison, one of the reads I really wanted is, I want to be out on a lonely platform in the middle of nowhere. So if you think about how big this is compared to other LZs, you could be on an industrial platform way out in the distance, and it would feel like you're looking at Orison in the distance, if you know what I mean. It was an early look we wanted to achieve. So to answer your question, initially, no. But we've kind of done the hard work to do that setup already.
I mean, we've talked about things scattered around Crusader so that they're on complete opposite sides of the planet, so on and so forth. So those are things that we will be looking into and trying out. But like Ian said, we have the base now for these things to be built off of.
Port Olisar has a special place in my heart. We built it back in the day. Whatever we do with it will be fitting. It's just not going to disappear. I'll just leave it there.
TL;DRLeyland answers yes and no: the team is working toward closing out previously discussed Stanton content, but will keep developing new tech in Stanton while also expanding to other systems.
I'd say yes and no. So yes, in the sense that we're working towards an objective to kind of close out what we've previously discussed. And as Todd said, this could be to do with celestial bodies or it could be to do with landing zones. But on that side of things, it's fairly quantifiable. But on another side, we're also developing tech as we go. What I mean by that is, as new tech comes online, it's very important to not [only] showcase that in a new system coming down the pipe. I think it's very important that we showcase that in Stanton. An example would be as Planet Tech is developed, last quarter you saw us update the height maps and we've got quite a lot of content coming in the next quarter. So those kind of give a little example as to how we're looking to still focus on developing our original system, Stanton, but also we're looking to expand out into other systems. So in answer to your question, Jared, it's yes and no.
TL;DRThe team is updating older Stanton locations, such as adding hangars at Grim Hex and finishing New Babbage details, building foundations other teams can add content to later, with not every change advertised.
Quite a lot. And it's quite varied as well. So just to kind of give a little backstory. So you guys are just seeing how we've updated something like Grim Hex. So this is kind of a classic example of how we've taken one of our fairly old locations in our game and as we've developed the game we've kind of realized what that location needs. So obviously we've gone back through and we've updated it with the hangars so it supports the player ability to land and take off from there in all size ships. I think that was huge. That's something that we've wanted to do for quite some time. Also while we were in there we were doing other things, like there's the mission giver location. And although we've done that work, obviously the mission giver wasn't ready for that release and the racing, the gameplay elements there as well, weren't ready. But essentially what we're doing is we're almost making the movie set. We're building the sets ready for the actors to come, and that's kind of a nice analogy, a nice way to kind of look at things. So even though we're laying the foundations, it kind of gives the opportunity for other teams to put their content in a little bit later on. So that's one example. Also, as we've closed out New Babbage, we wanted to obviously validate that last release we did. But there's a few things that we couldn't quite get in there for that release. An example would be something like the Factory Line, the flagship store in New Babbage. And even something as small as the kiosk in the spaceport. We're constantly looking to go deeper or add further layers to the player experience. And it could be even something as small as the player noticing, oh, hey, that's changed. And for me, even as a player, I really like it when developers do that because the space feels alive, it gives you that reason to kind of go back to it. Alright, okay, what's new? And we don't always advertise every single change we do because as developers we want to make the experience as good as possible.
TL;DRWork on Stanton includes deeper space station interiors like cargo and refinery decks, gas cloud visuals at Lagrange points, and early investigation into AI spawning, hospital gameplay and station exterior access missions.
Okay, so just to focus on the modular side of things, we've been looking to go deeper into our space stations for some time. You've seen them go from these quite small locations to these much larger, much grander locations, and that was step one. And now step two and step three is to go deeper, literally go deeper in terms of the internal components to it. So right now we're working on spaces like the cargo deck and the refinery deck. So these are ways in which we can add further variety to these much larger locations. And we can have a little bit of fun as well in terms of one space station in one part of the system will be very different to another station in another part. So that's one example. Also, you guys have been seeing the gas cloud tech develop for some time now. And one of the things that was important for me is to find an initial platform to showcase that in Star Citizen. So one of the things we're doing now is we've done the preliminary spacescaping, we've defined all of our VDBs, we're doing the lighting. So we're really getting a good idea of the palette that we can do in our Lagrange points. And now it's about other disciplines coming online and them doing the bodies of work to support that.
So from a design side, as well as on our side, we're focusing on monster closets, which is just our goofy way of saying, hey, this is where our AI will spawn, kind of out of view, and then also despawn out of view. But it allows us to fill up the cities or space stations, or even, let's say an incident happens around a certain area, it allows us to actually despawn AI in a realistic manner. From there we've got basically prepping for hospital gameplay and the healing aspects. So Ian and I have already had early discussions with the team as far as what we need to do there, as well as Rich Tyrer and other directors, on kind of how we want to roll that system out as well as the environments associated with that system at the same time. And then we also are working on what we consider kind of space station exterior access points, and this will allow us to have different missions, whether that be a repair mission or whether that be a dead drop or infiltration or those types of things. So you can actually access different parts of the space station from EVA and then be able to enter into the space station and do things there. So that's really kind of just early investigation stuff.
TL;DRBeyond Pyro work, new per-asset displacement tech may prompt a sweep of Stanton's geology, and new painting tools speed up planet creation, though planets and moons won't necessarily be repainted right now.
Yeah, so obviously we're hard at work on Pyro. But outside of that, some new tech features are coming online. A first example would be that now we've got the ability to have displacement on a per-asset basis. As part of that process, we're going to do a sweep through the Stanton system and look at our geology packs and try and showcase that new feature where possible. And if you think about going back through many planets and moons and updating the geology features, it's fairly sweeping, right? But it's something we've been after for a while and it's a good example of how we can go deeper. Other things that you might not see specifically in the next release but that are fundamental to how we work: we got these new painting tools, so I'm sure we'll do a showcase and feature on this a little bit further down, which is the way in which we physically paint onto these planets now. Previously, you'd do a pass on the colors and a pass on objects, whereas now you can define all of that data into a single brush. So this is going to be a huge shift in terms of how quickly we can sketch in planets or sketch in moons. So, like I said, we might not necessarily be going back through and repainting each planet and moon in Stanton just now, but we're utilizing those tools for how we're doing Pyro right now.
TL;DRCrusader is in a prototyping stage using existing tech so it doesn't block release; early results are fairly promising, though without volumetric clouds, and some shader tweaks may be needed.
Okay, so with regards to Crusader, this has been a question mark for us for some time, but in the same way that we approached something like ArcCorp, the idea is we'd look to validate the release of that location by utilizing the tech we have. So rather than going away and saying, hey, we need all of these tech features, and okay, that pushes it out, let's see how we can get creative with the tech we have. We're literally in this type of prototyping stage right now. Results are already fairly promising. Obviously, it doesn't include wonderful volumetric clouds and things like that, but as with everything in how we develop, we can always get better further down the line. But as part of this journey to bring you guys as the community along with us, hopefully you guys see these locations develop over time rather than us just putting it behind the wall and saying, hey, we'll release it when it's ready. So with regards to Crusader, that's where we're at right now. We've got some interesting prototypes with the tech we have. We might need to do some tweaks and shifts in terms of some of the shader code, but the idea is we do the best we can with the tech we have right now, so it doesn't block the location.