Developers describe how Star Citizen vehicles are made across departments and studios, and how ship slots are scheduled around capital ships. They cover Retaliator modules, ground vehicle physics, the Pulse, Resource Network passes, and upcoming ships including the Zeus ES (4.0) and the Polaris (IAE).
TL;DRShips go from designer briefs through concept, vehicle art and tech art, with gameplay, UI, branding and other feature teams supplying input, forming a big web of upstream and downstream dependencies.
Well, I'll start sort of roughly in pipeline order. You tend to start with designers coming up with the briefs. Then it goes around a lot of people to make sure the designers are not doing wild things in briefs. That sounds a bit odd, but... There's the concept team. The concept team makes the words become pretty pictures. Then we've got the vehicle art team who make pretty pictures become pretty 3D objects. Designers set them up. Tech artists set them up. And then we've got a whole bunch of downstream and sort of upstream dependencies. If the new vehicle or an existing vehicle has gameplay, gameplay people need to work with us on that to give us information. Especially if it's new coming alongside a vehicle, they need to work hand in hand with: hey, Feature X is doing this, we need this from your ship. And we do that. And they go, actually, it's not quite how we envisioned it, can we adjust things as we go?
Yeah, it's the feature development teams, and the designer takes it from the original concept all the way through, and we liaise with a lot of different departments and teams to make sure that all of the features that make the ships fun to play actually work when they're implemented on vehicles, because it's a very different experience of how something would be with FPS ground and how it then needs to be implemented on an actual vehicle to work. So there's a lot of back and forth and maybe things change and tweak to make it work a bit better with a vehicle, because it just depends on how the original gameplay loop was envisioned to work.
I think we say that we've got upstream teams and downstream teams, but then one of our upstream teams, like the feature team that developed mining or salvage, probably is a better, more relevant or more recent thing, is they also have dependencies and upstream teams. So they'll have input from the UI team and the branding team and whoever else to get their feature working. And then we kind of supply them. So we're kind of downstream to them, but it's kind of a big web of connected teams.
TL;DRThe ship and branding teams discuss manufacturer colors and try to keep them consistent across the game, but the branding team is described as flexible and ships needn't always match a manufacturer's usual palette.
We have discussions over it, yeah. I think it's good to get these things ironed out and get them out in the open. To be fair, they've done a really good job at bringing all of the... I think everyone is a little bit guilty sometimes of zeroing in on the details of one particular thing. We tend to have years that are quite heavy in a particular manufacturer. So when we have a year that's quite heavy in a particular manufacturer, we tend to kind of zone in on that.
Yeah, no, I mean, they're pretty flexible. The biggest one has been the Crusader stuff where, you know, the red and the white and the blue and the white and that sort of stuff. So getting those things more consistent across the game is... Well, so it's a bit of a story.
It started with the red and the white and then went to the blue and white. But then I noticed the Firebird looks red and white. And the first time I saw the Firebird, I thought it looked like Crusader.
Yeah, we have a lot of grey ships, and you can't say grey ships are... Some colours, like Argo's orange. Does that mean we're never going to make another orange ship? I don't know. You get red Fords, you get red Ferraris, so...
I do think it's important, as we've mentioned many times, that lots of teams work on lots of things at once. So if you can bring all of that stuff to kind of be coherent, it's really good. But that doesn't mean there's not flexibility in it, because not every Crusader captain pilot wants a white ship. And why should they?
TL;DRBeyond audio, ships involve VFX, lighting, QA, platform and website teams, marketing and production, with barely any team that the vehicle team doesn't work with eventually.
VFX, huge as well, because it gives the ambient effects and everything. We get help from the lighting team as well, so that they do some standardization so that we get better-feeling headlights and the intensities of them. We recently had a massive pass from them, so they set new standards to make sure that we had a nice consistency amongst all the headlights. But there's barely any teams that we don't work with one way or another eventually.
Even once the vehicle is done, ready for release, then there's all the teams that deal with actually getting it out the door. So there's the platform teams, the website teams, QA.
An inordinate amount of QA time gets spent on them, because at the end of the day, when it goes out, people start using them, they want them to be in the best state that we can get them. So trying to find all the issues and bugs and resolve them and get them just to be as good as possible for the release.
My favourite team is the marketing team, because they take our stuff and they just make it really, really pretty. You give it to them and you're not quite sure what you're going to get back in the trailer, and then you kind of get the initial cut and you're like, okay.
We also got to shout out production, because they're the ones that make all of these teams work together. And quite often, because they're not actually clicking a button and moving stuff around in the editor, they kind of get maybe forgotten about. But yeah, they're a massive part of it as well, making sure that all works together.
TL;DRVehicles are assigned to studios by project and available time rather than by manufacturer, usually staying within one local team, with other studios supporting audio and VFX, and work rotated to avoid burnout.
So generally speaking, the way we assign it is no one studio site has any particular manufacturer, but we'll do it by project. Let's say we were going to make, I don't know, the Crusader jalopy. Let's say. So we would figure out how long it was going to take by doing an estimate. Once we had a general estimate we'd see the resources and bandwidth, but generally it would try and stay within a single team, so it would either stay within the Montreal team and the designer of the Montreal team would handle it and the artists would take it through. Obviously not all studios have all the teams that we need, such as audio and VFX, so we'll have to go to a different studio for support for that. But for the actual internal vehicle team, we try to keep them local to the actual studio. So it's a lot easier to work within the same time zone for quick iteration on things. And the UK team, for example, is much bigger than some of the others, so we actually have the vehicle team from an art perspective split into three separate groups to make it easier to manage the different vehicles that are taken through the actual pipeline process. The vehicle team's gotten to the size from an art perspective where we actually need three different art teams within the UK side to do it. But generally speaking, I know that in the past people used to think that the US do all of the RSI ships, I think it was, and the UK do all of the Drake ships, but that was just what was assigned to them at the time. And it'll be like that moving forward. It's whatever time slots we have on different teams. It could be that one team might work on a big ship for 18 months, and a big ship is tiring for 18 months, so then we do smaller projects afterwards and the big ship goes to a different group instead.
Doing back-to-back capital ships is obviously quite... crushing. I think giving people a variety of manufacturers to work on is important. If you're only making Anvil ships for like five years, you're obviously going to get pretty bored of Anvil ships. So I think it is nice that people get the opportunity to work on different manufacturers from an artistic standpoint, like keeping it fresh, challenging yourself with learning new styles basically.
TL;DRPeople have favorite and disliked brands, and varied assignments keep creative staff engaged, while prior experience with a manufacturer helps them ramp up faster, so the team balances variety against skills.
I think you're absolutely right in that. People definitely have favourite brands and people have brands that they just don't particularly like, which is kind of, I guess, life in general. But I think it is super important to challenge people. A lot of people in the creative industry really thrive off of that challenge and reward. So giving people new opportunities to try out new things and get more experience in different fields is super, super important. And ultimately, if you are making the same thing over and over, different ships, but you're always on a particular art style, there is that element of burning people out with that. And all you really get from that is a drop in ideas and a drop in creativity.
The other thing worth mentioning about that is there is a benefit to having experience with a certain manufacturer. If you've worked on a Crusader ship before, you probably understand the style and it's going to take you less time to ramp up and get to know it. So there's certainly a benefit to people having a broad experience and being able to basically say, I've worked on Drake ships, I've worked on Crusader ships. That way, because we are divvying out stuff, it's not like we've got a Drake team or whatever. It's a double-edged sword. It's pros and cons. It's a healthy balance between variety and also making sure that people have the right skills to get the job done.
TL;DRShip choices are fitted into a finite schedule of patch slots, balancing capital ships, backlog and new ships, and support work for new gameplay features, with leadership adjusting the order.
We look at the schedule. Obviously we know Star Citizen, we joke about it internally, we have six quarterly patches that we do every year: we have the four quarterly patches, Invictus and IAE. And we always deliver at least one ship in every one of those patches, if not two or three. We also sometimes do point patches as well. So we can look at a year, pick this year, next year, whatever, and go, right, we've got these slots, there are ships going in here. And then we'll go through and go, if we are going to do capital ships, that's going to take up a big chunk of the team. So putting a capital ship in here means the rest of these slots become much smaller. We have to balance delivering backlog ships with fresh ones as well. And it sort of sorts itself out. It's like doing a big jigsaw puzzle. You go around the edges, well, I do go around the edges, and then you know where you're going from there. So once you put a few of the big pieces in play, you don't really have a lot of options. It sort of dictates the rest. And then we go through that with Chris and Rich and they go, actually, no, we don't want you to do this cap ship here, we want it here instead. That changes the order. Or, no, we don't actually want that there, we want two other things. So it's a lot of iteration and it sort of boils down to: we have chunks of time, a finite amount of people. We could put everyone on capital ships and then you perhaps get two or three a year globally, and then we've got patches without anything. Two or three ships, period. And we're just talking about new ships as well. I think we're going to talk about this more in a bit as well: 4.0 has a huge amount of support that the vehicle team needs to deliver. So we have to factor that in as well. We can't just go all new ships all the time. We have to work with those other teams, like the gameplay teams we talked about. They might be coming online with a feature like base building. We need to support that as well. So it's sort of a balance.
That one often dictates what we have to put into the schedule. Random example: when Salvage came online, we needed the vehicles that can support Salvage, so we have to make sure that we can have a vehicle ready to go with that gameplay as it comes online, same with mining.
Also with that, it's not just doing the Salvage vehicle, it's the fact that we need to do a pass on every vehicle in game to get them to support that feature. To be salvageable. And even little things like, oh, we want to add fire extinguishers. And you're like, okay, cool, that's easy, right? Our ships are big. And it's like, well, it's easy on some stuff, it's not easy on others. I think we were doing something the other day where we were looking at: right, if we spend a month on each ship, you're like, okay, that's one person for like 16 years. It's a lot of work, right? Or 16 people for one year. Then you get nothing else. So I think even little features, when you're talking at the scale of the game we've got, it does become quite a challenge to play that kind of Jenga of stuff, which is why we try and fit these things in. Like you say, oh, there's a pocket of time here that's got two months on someone that could be used for a small ground vehicle. Or we could actually tick off support for three other features that are coming in, and that gets more gameplay.
TL;DRA capital ship is a large piece of content rather than a feature, and new features like Resource Network need base-level support across all existing ships, which is a huge amount of work.
Yeah, and it delivers interesting gameplay. Although it is a huge piece of content, it isn't a feature. And the thing that will make the capital ship engaging is all different features, but we can't easily implement a whole new feature that's meaningful and impactful on only one vehicle, because realistically, for it to work, there's going to be things that are going to affect all the other vehicles as well. So Resource Network is a random example: to make Resource Network work, we can't just say, well, this one ship has it. It's a big, huge system. And to get that to actually work across the board on everything, we need to do at least a base level of support across everything, which is a huge amount of work. But if we want that feature and everything that comes with it, we have to go back and adjust and alter all the existing ships to at least function with the feature.
TL;DRPriorities vary by department, but overall the vehicle team aims to deliver ships that support gameplay mechanics as features come online, rather than releasing ships just because they're finished.
I mean, I think that varies depending on which department you ask, because from a designer perspective our number one priority is to make sure that the ship makes sense from a flow and navigation point of view, and that it functions, and all the features inside the ship that are currently available function. So if there's a gameplay loop or there's content that should work in it, they do work. That's our priority, that's our number one, and to make sure that when you look at the ship, it makes sense for it to be that way. But that's not art's priority. They have a different set of priorities for what we do, and it'll be the same for tech art. Depending on the department depends on what your number one priority is. And John's will be completely different again, because you're more about the bigger picture.
Bigger picture, so the vehicle team exists... Vehicles are the heroes of this game. That's the best analogy that people keep saying. In other games you have hero characters; ships are sort of those for Star Citizen, I feel, in that everyone's got their favourite and they're there to do mechanics. So for the vehicle team it's delivering content that supports those mechanics, whether it's updating existing mechanics like we talked about before, adding in salvage... Refuelling was another one: there's no point just putting a refuel port on just one ship for the Starfarer, we need to do it on all of them, and that takes time. And working with those other gameplay teams to go like, hey, the quarter two patch is going to bring this feature online, so we need to update ships with that. Q3 is going to be this, Q4 is going to be this, Q1 next year is going to be this, Q2 next year is going to be this. And sort of getting away from what we did in the past, like you mentioned, of just punting the ships out just because they were done, and working with the other teams. It's great seeing a ship out there. It's better seeing it out there doing the job it was supposed to do.
TL;DRThe team wanted wee-woo lights on the ship but ran out of schedule time, wants them added at some point after other work, and would need better controls for them.
Wee-woo lights, they weren't going to stop it going out. I was pro wee-woo lights. I think we were all pro wee-woo lights. However, I have read some feedback on the discussions over this, and I may be thinking that if we were to do them, we certainly need a better way of controlling them, because I believe that they can be a little bit intrusive if you're trying to be maybe a little bit more stealthy.
Yeah, but if you need to put your headlights on so you can see where you're going... To be clear, we wanted to put them on. It was just a schedule thing. It was a matter of time. We needed to get the ship out.
The exterior needs a bit of a pass anyway, with things like damage and so on as well. There were a couple of things that we wanted to get in for it that we didn't quite manage to get in time. We only had one guy working on it and it was sort of his first project as well.
Well, it's what happens when we do variants of older vehicles. Obviously, to release the vehicle with a new feature, because obviously you've been asking for the Medivac for years, we found a slot where we could get something in to do it, but we didn't have a slot big enough to completely gold standard the base Ursa, because that's what it is, it's a variant of the base Ursa. So that's why the front is still the old-style dashboard; it's not new and updated like the Lynx's is. We have so much time and we get as much done in that time as we can, but at some point it's a case of either nothing goes in that slot or something else goes in that slot, and it was a case of: we could get what we did in, but not everything that we want. We would have loved to do a full gold standard on the Ursa, but that isn't the time slot that we had. And if we did do a full gold standard on the Ursa, we definitely wouldn't have had time to do the Medivac. So it's just about seeing what we have time to fit in the slots that we have.
And I don't want the lack of wee-woo lights to distract from how good a job Harry did on the Medivac. He absolutely smashed it. There's a few things we missed off, but hopefully people will appreciate what was included.
TL;DRNew vehicles are often chosen over backlog ones because of size, scope and gameplay, since older ships need costly concept reworks and may lack gameplay to support them, though backlog ships aren't being abandoned.
A lot of the time, it does generally come down to size and scope. And it's gameplay as well. A lot of the new vehicles come with new or updated gameplay. And it's a lot more time-efficient to do that in a new vehicle than it is to go look at one of the old backlog ones, which probably at this point need a concept pass as well. Concepts are another finite resource that we need to manage. Not that we want to never do those backlog ships. We do. They just come with a larger cost, with all the things we've learned over these years.
Well, look at the Carrack as a prime example, right? The original concept, the interior did not fit inside the ship. To try and get everything inside that ship, it was never going to happen. So we either cut scope on the ship or we increased size. We had to take it back to concept. But then the concept artists have a situation where they're trying to preserve the old ship while also adding everything that's needed, and it is arguably more difficult than doing a fresh concept. And we do want to get the vehicles out with the new features, the small gameplay loops. It's not that they're never going to get done, but certain time boxes, especially if a gameplay team says, we're going to have this feature ready for this quarter, we want to try and have a vehicle ready to go out with that feature.
A lot of the older vehicles do have gameplay ties now. We've sort of got through that backlog of ones that don't have gameplay tied to them. So things like the Starliner: yes, we could do it, but there'd be nothing to do. We don't have VIP transport... well, it's not VIP. We don't have transport missions. We don't really have NPCs getting on and off our ships. So again, we'd do it, spend a bunch of time on it, and if the gameplay team hasn't done their work, or if it's just not a priority for them... Server meshing or doing Starliner.
Marketing certainly have a say in what they would like, but at the end of the day, it comes down to Chris, Rich and myself balancing that with what's best for the game.
TL;DRThe variants are a mixed case: balancing schedules, bringing older ships up to standard, and giving new staff manageable starter projects, with more variants to come, though not a deliberate turning point.
[On the 'Nursa' nickname] Only heard about that recently. I wish we'd figured it out during the actual development, because we always nickname ships when they're going through development, just because it happens organically with the team. We never came up with Nursa, and I love it.
I think it's mixed, really, because as we've already spoken quite a lot about, it's about that schedule Jenga, or Tetris, that you've got to try and play to get things to work together. It does tie into also bringing ships up to our current standard as well, because a lot of the time, going back and revisiting other ships to bring them up to the current standard, it's not a short amount of time, it's not a short amount of investment that goes into it. The Retaliator is an example. A lot of things have changed since that ship was made, and internally we're like, oh, it's like an onion: you take one layer off, you're like, oh, we need to do... okay, that layer comes off, you're like, oh no, that means we need to do that. And before you know it, you're almost back to square one.
Yeah, but you want to retain some of its original character as well. You don't want to go in there and make a Mark II. You want to build on it. But sorry, with the variants: if we're bringing stuff up to current standards and we're making a variant at the same time, it becomes a little bit easier, because you get more from the same one. Like I think you were saying earlier, when people have got into that particular zone for that particular vehicle or art style, whatever it is, it's quicker.
So I think we are getting a little bit more for our money by doing it that way. We'll often see a post or we'll be chatting and we'll be like, oh, it'd be great if we did... a Crusader jalopy, or a Cutter bounty hunting ship or whatever it is. There's lots of things that we talk around between ourselves because we're like, oh, that'd be super cool. And sometimes those things are, oh, actually, that'd be super cool and it fits. And sometimes it's, oh, that'd be super cool, we'll put it in the bank of ideas that we could do when we get time, when we get to it. But it's a big balancing act between what the game needs, what we want to do as a team, and what we're asked to do from other departments.
Variants are a great sort of new starter task as well, as their first real meaty project. We talked about this briefly at CitizenCon, that we had lost a lot of people from the team over the last year and we've been rebuilding. So Montreal, their first task was the two Cutter variants. The Nursa was someone's first project. Same for the Firebird, and then there will be more. And again, they're great things to... Here's an existing ship. You can see how it all works. We want you to change X, Y, Z. You get to see the whole process, get something out the door, and then you're ready for the next big thing start to finish. So Montreal did the Cutters and then went on to the Zeuses. So the Zeuses will be their first full start to finish, but they ramped up with the Cutters.
I would just add to that that it's great when the ship's fairly up to date. The gold standard passes tend to require a significant amount of weird CIG knowledge, I guess I would call it. You need a lot of understanding of how our systems work, just understanding really the in-depth stuff of the ship and how to take it apart and put it back together, right? Newer stuff, you've got a fresh start, I guess, or at least something more tidy to work with, more up to date with our current standards. So you're building upon something that's already quite polished. Whereas if you're taking something that's quite old, the standards have changed, the way we do things has changed, and you have to know the good practices to recognize the bad practice.
To be honest, even AAA games now take years and years. So it's not even like our life cycle is particularly long compared to a lot of other games that are a third or quarter of the scale of what we do. But a lot of the time you develop pipelines and processes and you lock that in. You get to a certain point in that game development and you lock it in and go, right, this is it, we're finishing it. Whereas obviously with our game, we have the luxury of constantly evolving our tech and our pipeline processes, and you can hopefully see the improvements with the latest patch as some of that stuff's come online. It really makes a massive difference to our player base. So we absolutely want to be at that cutting edge of making the best we can. So our processes do change, our quality standards change, our visual detail levels change. And yeah, we're always trying to push that stuff forward.
TL;DRSwapping modules in ships like the Retaliator now works, and future or reworked ships can get it, but detachable pods like the MPUV's still need more tech.
So, for the most part, there's a couple of different levels of modularity. You've got the sort of modularity you have with the MPUV, where the pod can detach and attach. We're still not there yet. But for something like the Galaxy's pods or the Retaliator's pods, where, say, it's something you take somewhere to swap out for you, we're now at the stage where we can do that one. So ships moving forward that would have the feature will have it, and all the ships, when we get round to doing the gold standards of those ships, we can revisit the modularity to introduce it to the ships that need it. But it depends on which version of it. So there is still some tech needed, but for the base level of being able to swap out the modules inside of the ship that need swapping out, we can actually do that now. Like you see with the Retaliator right now: it swaps in, swaps out. You can get the torpedoes, you can get the cargo. It depends what you want to do with the ship. So that's working. Big shout out to the team. Got it working all in time. Works really, really well.
So with the Retaliator in 3.23.1, the torpedo module they've had in there can now just be swapped out. The new module is a cargo module, so you can turn it into a cargo ship with the proper grid and everything. And then the blank base module, because if you have to pull it out, you have something to put in there.
Yeah, but it depends which one you got, right? Although people have had the loaner for a long time now, which was the Retaliator Bomber, which was the torpedo variant, it depends which version they got. They might have bought the base, they might have bought the base with all the different modules. It depends what they purchased.
TL;DRPossible next Retaliator modules include a dropship, habs and living quarters, with ideas for bounty hunter and medical ones, but the ship shouldn't become one that does everything.
The dropship one. Habs, slash living quarters ones. And then, again, we've thrown around ideas about other ones. We talked about doing a bounty hunter one, like prisoner cages for going to get things.
We could support a bunch of different gameplay features with it. I don't think you'd necessarily see, I don't know, a salvage version or anything. So I don't think it's going to be a case of all of a sudden it becomes the uber ship that does everything. I think it still needs to make sense as to what that vehicle's role is.
We'd love to. I do want to touch quickly on the torpedo one, because I know there's an issue for some players at the moment who have the Bomber, that they're missing their torpedo modules. Turbulent and Platform are looking into it. There's a couple hundred accounts for some reason where, when their pledges got converted from the old Bomber to base plus torpedo module, they did not get the module, but that is being looked at. I've seen a few Issue Council things on it, but it's being looked at.
It's not new. I remember back in the days of Port Olisar, people used to get the X1, PTV and Dragonfly inside the airlock, and you'd go down to spawn your ship for the first time and someone would just be sat in the middle of the globe on it.
TL;DRThe ground vehicle bouncing is a network and physics update problem that doesn't occur in the editor and is being looked at; reworking the separate ground vehicle code is a priority question.
It's somewhere between network and physics, because there's a weird update problem, and you can see it if you have a load of vehicles next to each other, that they all sort of bounce on their suspension at the same time. That's being looked at, and it doesn't happen in the editor. So again, the experience we have when we're developing these vehicles doesn't translate one-to-one with how it is in the live product, frustratingly. People have seen, or hopefully have seen, the fix for that for AI combat in the recent patches, where they've gone from being unresponsive at times to probably a bit too responsive now. It's the same with ground vehicles. There's still more we want to do with them. Compared to spaceships, they don't have a huge amount of customization. We want to eventually go upgrading engines, gearboxes, wheels, swapping your wheels out for different ones, so they have a similar sort of upgrade path. But again, it comes down to gameplay engineers: do we want to refactor that ground vehicle code? Because it is a completely separate code path. It's still based on a lot of the original CryEngine arcade vehicle code. Even though the wheel and tire handling is all new from us, the underlying system is still sort of separate to vehicles. I've talked with Chris a lot about just unifying them into just a vehicle system, but that requires someone to go: rather than this line in the XML that deals with engine parameters, it's an item now that goes on and drives those wheels. So again, priorities. We want to do it. It's just engineering directors: are you going to spend your time on this feature for 10, 15 ground vehicles versus whatever else?
TL;DRThe team likes ground vehicles and wants more, but the current wheel system means each new one adds rework debt, so they are cautious about making many before it changes.
I think our game, it's a whole universe, right? You've got planets that you need to be able to explore and you've got space you need to be able to explore, and different players play the game different ways. So I think we need to support all aspects of that. So from my point of view, I love ground vehicles. I come from 10 years in racing games. So yeah, I definitely want to see more ground vehicles, more variety, more options and functionality. There's still space for more. I want some motorbikes.
At the same time, though, because of the fact that the wheel system is the way that it is right now, we know that every ground vehicle that we make is something we're going to have to go back and fix again. It's not even just fix. The rework we're talking about there, to change it from what it currently is to what it would need to be for this whole new system, is a massive amount of work. So it's just like talking about a new feature, right? It's the same as talking about all the different modules we want to do for the Endeavor. It would be a huge amount of work to go back and change it. And it's not just us. It's a feature team that has to fix the actual wheel. So for argument's sake, say that happens: all the vehicles that are made will need to be fixed by us, by tech art, by audio, to use the new system. And every extra vehicle we add is more debt that we're generating for that. So don't get me wrong, we love ground vehicles like every other vehicle. I mean, it is just a vehicle. But it's knowing that we are at some point going to have to go back and do this. It's just avoiding having the exact sort of situation we had with the Starfarer, where we made a vehicle just to get it out and then had to go back and retrofit a feature into it because the feature had slightly changed from how we made it at the time.
TL;DRNo, the change restores the original intent that all med beds allow spawning, to be tested and adjusted, with the harsher Death of a Spaceman consequences coming later, with no date given.
I went and talked to the design director for Squadron 42 and the Persistent Universe, Rick Porter. He was on the last Star Citizen Live; you met him along with Rich and JJ. They were the makers of the original med bed spawning system back when they were just on the actor feature team. Back then, which is about four years ago, their intention was for all med beds to allow spawning, and just for some to be at this distance and some to be at this distance. That was their original intent. It didn't get in at the time because of this, that, or the other thing. It was four years ago. But now that they've gone to Squadron and they're back, and they're now overseeing the development of the Persistent Universe, it was one of the first things they wanted to bring back. And thus, they did. Obviously, like anything else that goes into the Persistent Universe, it'll be tested. It'll receive a whole bunch of feedback. It'll be adjusted as necessary. Maybe 50 and 20 is too long. Maybe it's too short. Maybe it needs to be 70 and 30. Maybe it needs to be 30 and 10. It's a thing, just like anything else, that'll be adjusted. But the one thing that they really wanted me to remind you of is Death of a Spaceman. Death of a Spaceman is coming. I'm not going to sit here and say when, just to say that it's a lot closer now than it ever was at any point in the history of our development. And Death of a Spaceman will introduce a whole host of difficulties and challenges and detriments to your character should you choose to respawn over and over and over again. So looking at it through the context of Star Citizen today is of course natural and proper, and you absolutely should. And a lot of that feedback that we're seeing is because they're looking through the lens of Star Citizen today. But they are making decisions, laying the groundwork for the Star Citizen of tomorrow and the day after and the day after. So remember Death of a Spaceman. You can still read an excellent write-up of it on the website. It's still pretty accurate. I think we're about due for an update, actually. I'll talk to Rick about that and what the current intention of design for that is. We do have a big CitizenCon event; maybe we'll do it. That's not a promise. But keep in mind that that's coming, that's on its way. If that affects your purchase, know that that's on its way before you buy, and enjoy getting back into the fight even quicker and more consequence-free for the time being. But that change is coming, so remember that.
TL;DRHalf of the ships shown in the CitizenCon teaser are still unreleased and in production, mostly expected within about a year except one that is further out, plus other unannounced ships.
Right. So if you go back and look at the CitizenCon presentation we did, we had a sort of teaser video. There were 10 ships in there. We're, what, six months past CitizenCon now? Six months to the next one? We're halfway through those ships now, so the five that have not been released from that video, they're all in production now. With the exception of the Legionnaire, they should all be within that 12-month window. Legionnaire, again, is going a bit further just because of gameplay. The gameplay teams can't support us for when we wanted to do it originally, which is fine. But there is also a lot more than that. When we did that video, people didn't know about the Syulen as well, so San'tok.yāi, X1s, Spirits, Hornet Mk IIs, Nursa... the Firebird wasn't in there. So it wasn't like, here's 10 ships, these are the only 10 ships that we're delivering. We're doing more than that on the sly as well.
There's two from that video and they're pretty much the two that people know about now. The first one is the Zeus. So the Zeus ES is coming at 4.0. We did the LOD0 gate review for that yesterday.
Yeah, so that was the one that Montreal have been working away on since they moved on from the Cutters. And yeah, it's just passed LOD0 gate review. Smashed it. It's looking so good. So very, very excited to get that one.
We showed it to Chris last week, I think it was, and he was like, setting new standards. And we're like, that's really, really good. It's a bit scary, but really, really good. So yeah, very, very happy.
There's another Sabre, probably the one that people thought the Firebird was going to be. It's that. That should be soon™, not giving dates. And then some of the other recent releases will be getting some variants.
TL;DRResource Network is a full system replacement, so the most popular multi-crew ships get a full pass with physical components, while the rest get a base-level pass, alongside other ship work for 4.0.
Like I was saying before, we can't partially do it. It's a whole new system for how resources get transported around the ship. So we can't have some doing it and some not. It's straight up a redo of the system. It would make no sense for some ships to use it and some not; it just wouldn't interact correctly with each other. So we've taken the most popular multi-crew ships, and they have got a full Resource Network pass where we've physicalized all the components inside the ship, so they're all physically there, they can be opened up, you can see them, you can repair them, whatever. That's with the top 10... not top 10, it was the top 10, but some of them are variants of each other, so we've just taken the most popular ones. And everything else still needs a base-level pass for Resource Network to actually allow them to function. So it's changes to their loadouts, adding the relays, and then making sure that they actually function, because we've got to remove the pipe system. We're also using it as an opportunity for what we mentioned at CitizenCon, where we talked about why the Zeus had way more shield generators than everything else. We're actually using 4.0 as the opportunity to do those changes. So actually there's a huge amount of changes to other ships as well with their component numbers and sizes and things. The ones mentioned before, that will all be physicalised. The others won't be physicalised, so they'll be invisible inside the ship, but they'll be able to change their loadouts and things. But that's not all for 4.0. We're also having to support other features that are coming online. I won't go into too much detail because it's other feature teams, but it's huge sweeps across all of the ships, and we need to get all that stuff delivered, because as the stuff that everyone saw at CitizenCon comes down into the PU, it doesn't just magically work. We need to actually go in and change the ships to get them to work with that. So we did the markup pass for all of the mini-maps inside the ships, so you now get a nice map when you bring it all up. But this is all extra stuff that we've spent time on and that takes resources to do.
It's the Polaris. People have obviously seen the teasers and trailers, and the outside looks very, very nice, but that's what we focused on. That one has had some of our most talented artists on it to try and get it to the highest possible standard in time for the flyby and everything. Big shout out to all of our art team that's been putting so many hours into it.
I think Alex, Dan, Lloyd, they all kind of smashed that exterior. Obviously, we've only shown the exterior, or are only showing the exterior so far. The exterior technically is in grey box, but obviously visually it's far beyond that.
TL;DRThe Polaris will be fully flight ready and released to backers at IAE this year, not at 4.0, with just under half the UK art team working on its interior.
It will come out at IAE. Also, massive shout out to all the interior guys as well, because we've got a whole other bunch of artists that are smashing the interior. It's not at the level where we wanted to show it yet, but yeah, they are plowing through that work and it's going to be great.