Developers describe how Star Citizen ships go from idea to game-ready: concept art, white box, grey box, final art and flight prep. They also cover ship prioritisation, metrics-driven reworks (Vanguard, Merlin), turret placement, snub craft, modularity and why RSI website specs are inaccurate.
They come from a variety of places, as obviously we have a lot of ships in the game. We have some very obvious gaps in lineups, so it's only natural to want to fill them up. Sometimes we have a new gameplay feature coming online that may not require a spaceship to do that job, but a spaceship would help extend that gameplay. And then there's also the wildcard: director and executive, and really anyone in the team can pitch an idea for a spaceship. And sometimes if they gain enough momentum, they work their way in.
Occasionally, yeah, quite often. There's certainly real-world analogs for a lot of spaceships, particularly on the military side, so everyone's got their sort of favourite World War II dogfighter or fighter or bomber, modern-day things. The Vanguard always gets back to the P-38 Lightning. Everyone knows it. The Eclipse looks like a B-2 stealth bomber. So the military side definitely has a lot more analogues. On the less combat side, they sort of have their: we want a space trucker ship, we have a space tanker ship.
Not as often as you would think really, because obviously we'll have the design direction from John, we'll have a steer from Chris, because sometimes I'll follow one direction and Chris is like, no, it should be this. I'm like, okay. But yeah, I guess you'll approach it from a functionality point of view. You'll reference whatever you can. Obviously, we'll just pull something off the internet. Obviously, with spaceships, it's kind of harder. With ground vehicles, that sort of stuff, there's a lot more things we can pull upon. But really now, the team is pretty well versed. And so there's a lot of stuff to pull on. There's a lot of just natural experience as well. So these all feed in.
It's mostly Paul's judging of skills, and it's basically his choice. We have an external artist we've used for a long time, and he trusts them, he'll give them more complex stuff. If not, then we'll use internal that can be done maybe quicker, it's less risk.
I mean, it varies. The likes of the Esperia Prowler, I think that had four concept artists on it, because it was a brand new manufacturer. Everything. On the one hand, it was awesome. And on the other hand, it's kind of terrifying, because it's just a completely clean board. So basically we use different concept artists for different stages just to sort of push it along, get the best out of it, because the timelines never change. So it's like, okay, how do we hit this timeline? And you sort of use your assets basically to the best of their ability.
Yeah. And I think that's the promo stage. I call it selling the dream. Basically, it's about selling the experience of what a player could have. And when I'm working out what shots to do and I'm working with the marketing team, we'll pull reference from familiar movies, or we'll sort of say, okay, it needs to be this moody scene, it needs to have this sort of vibe going on in it, and you try and tie it all together. It's just, like I say, to sell whatever the emotion is you want to bring with that image. So, it was good. I think the bike worked out pretty well in the end. I think a lot of people got on board with it.
TL;DRWhite box turns a concept into a rough, functional in-game version of the ship with basic geometry and borrowed parts, so it can be tested and problems the concept missed, like metrics, get fixed.
So white box is getting the fundamental geometry in. Depending on the concept and depending on the concept artist, it could simply be taking the concept mesh, doing a very rough re-topo or recreation of it, putting the absolute bare-bones functionality in, so you'll grab a seat from another ship, grab a dashboard from another ship, and get that ship functioning. Because you don't care that the concept has this style of seat, you care that the ship functions. We'll take the main geometry, we'll start splitting it up in the places that it needs to split up. So the idea for white box is that you have all that base setup in there done by design. So design, in an ideal world, which doesn't always happen, can just be hands-off, and art can just sit there and iterate on that file, and a fully functional vehicle is maintained at all times, it's just the art progresses. It doesn't always happen, and there's always a level of backwards and forwards between design, art, tech art. But that white box is really taking that concept and giving it an in-game presence that can be tested, because at the end of the day, when we do a concept, we can only check for so much and we have to assume some things will work. Especially for ground vehicles, you can't do a full suspension test in a bit of 2D art. You need to get that vehicle in-game and run it over rough terrain, because the clearance might not be enough, the axles might not be wide enough.
Yes. Certainly we've changed the process over the years and we run into a lot less of them now. A lot of the older ships never had that level of concept done to them.
We have a whole suite of metrics now that we can just give to the concept artist and say, okay, here's all your chair heights, seat heights, toilet heights. Here's where the sink should be. Here's all that sort of stuff. Here's where the button should be.
If you're getting out of a bed, you need this much space on the floor. And if you've got beds on each side of the corridor, you need to account for both people getting out of bed at the same time and not clipping into each other. So that's why ships over time, especially from concepts, can grow in different dimensions. Why have they just made this ship randomly wider? It's 99.9% going to be that it doesn't work with our animation system.
It's one of those things. In a real-world submarine, you can have these super tight corridors, because human beings can put their arms up like this and scoot past each other in a hurry. But in a video game setting, when you're in a hurry and you're just running and you hit each other, things often have to cheat a little wider than they normally would in real life. And white box is the phase where we get to figure that out.
Our character models... If you were going to make a collision mesh for me here, I'm not a big cylinder, I'm a sort of squished cylinder, so if I turn sideways, two of me can go like that down a path. But in reality, our collision is a capsule, so it's really something with rounded edges, because if I spin around on the spot, my shoulders fill up that entire void. Having that is a lot simpler to calculate than having a more complex shape. So we can't have, like you say, the submarine example of two people going sideways past each other. We need to have a wider corridor that can fit two people going shoulder to shoulder.
I think we learned that lesson on the Valkyrie, when it turned out the doorways weren't wide enough to fit two people through if they're wearing the largest armor, so we widened them slightly.
Grey box is where the geometry is essentially finalized, and going from grey box into final art, geometry is locked and doesn't change, so then it's just about finishing off materials, maybe dressing with props if needed. But grey box is locked geo and shouldn't change.
I would say, well, final art is basically just a level of polish. At least in my head anyway, it's going through it, validating, that's a good word, isn't it? Going through checking all the shaders, materials, performance in terms of amount of shaders, does everything operate as it should do, animations, VFX, lighting, fog volumes.
Yeah, adding props and finding opportunities for life, basically, where you want little blinky lights or whatever it is that you want to put in the ship.
Yeah. So, as you say, once a vehicle gets to final art, that's a fantastic portfolio piece, but it's not a game-ready asset. Certainly not for our game, because that's what we call the 100% pristine model. That's what you see when you spawn that vehicle. We then need to do all the damage setup. So that's the UV2 wraparound, so when you shoot it, you see the little burning of the textures and seeing the hull underneath. That all needs to be set up, all the shield setup, all the optimization, LODs, all the stuff that isn't really glamorous to do, but is essential to get that vehicle to work in game.
TL;DRShip priority is fluid, driven by Squadron 42 needs, having ship content in each quarterly release, studio capacity and schedule gaps, gameplay feature timing, company wants, and which artists suit which manufacturer's style.
So it's a very fluid thing. I don't think there is really one particular... No, there's many different aspects to it. So you obviously mentioned Squadron. That's a big driver of it. Another one is ensuring that there is some ship content in every quarterly release. Because every ship takes a different amount of time, and we have different amounts of resources in different studios. If you gave the same ship to the three studios that work on vehicle content, they would all come back with a different end date, because they have different capacities. So depending on when we want a ship to release defines when we want to start it, which also puts other gaps in the schedule. So if we know we want to have a ship finish at X date, and that team is currently working on something that's going to finish at Y date, which is six months before, we can't just have those guys sat around for six months not doing anything. So if there's a ship that those guys could do in six months, that will go in there, which explains why sometimes it seems quite random, where a ship will go from not on the roadmap to suddenly on the roadmap, done for the next quarter, because that swap has changed. It might also be tied to gameplay features. We try and work with the gameplay guys to go, right, this quarter you're doing this gameplay feature. When possible, we'll try and deliver a ship. That's not always possible. Sometimes we'll slip on the vehicle side, sometimes they'll slip on the feature side, sometimes we'll both slip and we'll slip different amounts.
Needs of the company as well, sometimes what Chris wants, what he wants to see in game too, what John wants to see in game, what makes sense with other things that are in game.
Yeah, there's no point just... I mean, we could sit down now and completely change the schedule and just focus on doing capital ships that we have in our backlog.
Yeah, you wouldn't see a ship for nine months, and that ship is for a very small amount of the community that have it. You could argue that it'd be better time spent doing multiple smaller ships.
I think you also made a point earlier on about picking the right artists. I imagine not every person who builds ships for Cloud Imperium Games has the aptitude or skill set to work on every type of ship. Some artists' personal styles would be more appropriate to work on a Drake ship, and some artists' styles would be more appropriate to work on a MISC ship. And when you have an artist come free, you want to keep that artist engaged. Like you said, you want to keep them working. And, yeah, we wanted to do a Drake ship next, but this artist isn't really the right fit for Drake, but they are a fit for MISC, so maybe we pull something from MISC up ahead since they have that opening, to keep them going.
Yeah, it works the opposite way as well. For instance, on the 890 Jump, there's certain artists that needed ramp-up time to get used to that art style, because they'd been working on something from Aegis or Anvil beforehand, which doesn't have the curvy flows to it. So we need to think about that when we're also scheduling in the ships.
And as a reverse of that as well, we can also sometimes find that if someone's worked on the same style of ship for a long period of time, they're great at doing that, but they're absolutely sick of doing that art style. They're begging to do another one.
TL;DRFunctionality comes first but ships still have to look cool; the team says it is now more considered rather than deliberately rule-of-cool, with realism and Chris's feedback pulling designs back to reality.
It seems like a trick question, but let's just say that we're a lot more considered now. There's the functionality, which is king, but then it does have to look badass, and Chris never lets us get away with it, do you know what I mean? We all know I've had some horrors in my past, but we always get there. So sometimes it's just difficult, isn't it? You're reliant on the artist, and you're literally just starting with a blank piece of paper, and it's like, okay, how do we make this super cool thing that's not been seen before, that hopefully doesn't get accused of being someone else's ship, even if it's not, all that sort of stuff. And so it's always a bit of a struggle, because sometimes functionality does define where you end up at, especially if you're making a realistic kind of game. If we do something just utterly ridiculous or fantastical, Chris is just going to go, no, that wouldn't work. And so you're brought back to reality. And again, that affects the strokes of the pen, basically.
TL;DRIt is a big challenge, so the team gets a high-level download of the planned feature and builds the ship so the interactable piece is modular and can be replaced later without redoing the whole room.
Yeah, it's a big challenge. If we're doing a ship that has a gameplay feature that we know is not going to come out with the ship, or is not going to come out anytime soon near the ship, we'll try and talk with Todd, Tony, Chris and get their high-level download of where they see the feature to be. And then when we're building that ship, we try and think of a way that minimizes rework for us down the line. Say we've got a ship with a feature that requires a big interactable thing in the room. We'll try and build that room where the thing you interact with can be easily taken out and replaced down the line. It's not integral to the room. It's not built into the mechanics of the room. So instead of having to redo that entire room, you're just redoing that one piece.
Yeah, building it modular, or just building it very carefully. You know you're almost certainly going to have to go back and do something to it. You might as well not redo the entire ship for the sake of that.
TL;DRDesigning for unimplemented features is tricky, so the team presents a few concept options, then reviews them in first and second passes where every discipline flags problems early, since later changes are very expensive.
It's tricky. John and his team do a good job of giving as much information as we can. Everybody can do better. But let's take the Vulture. We haven't done salvage. And so we did quite a lot of designs for that one. We went one direction, it was quite basic, it was going to be that sort of transit van with some kind of recovery arm on it or something like that. And then we did a whole bunch of things, and eventually Chris was just like, no, this is the ugliest ship I've ever seen. And then we were like, all right, I guess we're back to the drawing board. Initially then it was a little bit of rule of cool, but it's driven by gameplay. It's like, okay, I'm sat in the cockpit, I'm doing this task. How do we make it as visceral and interesting as possible? And that basically was how it arrived, and so that's how we got the two arms and we got the tractor beams pulling all the pieces, and it was like, okay, that is going to make it a pretty cool experience, all this stuff coming in. But there's always that: you're not sure what problems you may hit.
Yeah. There's the key stages of the concept phase, where we provide some options to Chris of possible looks. Once he's happy with one, we'll move on to the next stage, where it's like a first pass. It's like a white box of the production phase. And at the first pass review, we get every single discipline involved to call out what they see, what could go wrong with this ship, so we can change it now. Going from there is the second pass, where it's like grey box final, where everything's locked. It's like, this will go into production next, but again, we give them the opportunity to call stuff out.
TL;DRThe Vanguard is the example: its concept predated current metrics, including ship item metrics, so doors, seats and its doubled components could not fit without compromising the original visuals.
From the original one, which is why it ended up the way it did. There were other reasons why it ended up the way it did, but a big reason why it ended up like that was having to... This was made without the metrics that we have when we built the ship. Like I said earlier, when you have to fit certain things of a certain dimension into a space, sometimes you cannot keep the integrity of the visuals.
And when you say without the metrics, you mean that the metrics themselves had developed since the concept was done. So the concept was done under one set of metrics and then the game progressed, and when it came time to build it, those metrics no longer applied: doors had to be wider, chairs had to operate somewhat differently.
When that was done, I don't think we had metrics for the ship items. And that was a key feature of the Vanguard: it has double the items for redundancy, which, when you have to find space for all those things in there, is a lot of space.
TL;DRShips get reworked mainly because of metrics and component fit, a global animation overhaul that exposed fudged animations, evolving art style, and old damage models, with the oldest ship due for an update pass soonish.
Number one is probably the metrics, if it's not for components. Because every ship has components, they are all going to be in a physicalized location inside. Obviously, we don't want to cheat things. If the ship physically can't fit everything it's supposed to have inside of it, something has to change on the ship. We've done a huge pass on the animations, which I think people have noticed in the recent patches, but they perhaps don't understand why things have changed, like the cockpit, or the little Terrapin fans with the cockpit seat height thing. That was fixed as part of a completely global change to every single animation in the ships. So previously they were just one canned animation for getting in. We've split that up into the individual chunks, and now design and animation can stitch them together in any different combination. So when we were designing ships before, we would say this ship uses the Gladius enter animation. So we had a template file and it had the ladder touch points. So that ship was built around that entire animation. So you had to get in a ladder of the exact same metrics as the Gladius, into stepping over a bit of the wing that is the same size as the Gladius, down into a cockpit that is the same size as the Gladius. That's all now split up. So you can have the sequence animations now. So you can mix and match, say, going up the Gladius ladder with getting into the Hornet. So it gives us a lot more flexibility. But that meant all the ships had to be vetted to fit things. We found examples. The Avenger and the Eclipse supposedly used the same animation. Turns out they did not in game. So when we fixed the animation, on the Eclipse you were walking inside the geometry as you went up the ladder. That's because someone had just done a sneaky little fudge to the animation, saved it as Avenger 02, job done. So we had to remodel bits of the Eclipse to get that fixed.
As well as that, the more we make the ships, the better we get at it, and the more our art style gets better. So look at the 300 series, for example. They were one of the first ones to be made. I wasn't around then. But with the rework and the 600i, completely different style, so reworking it made it look way better than it does. So art styles evolve, and iteration.
Yeah, and I think in 3.5, the M50, nobody will have noticed this because you just can't have seen it, but the M50 was actually carrying around the old damage model this entire time, where instead of having the UV2 damage, it had the four bespoke modelled damage states for every single part. Because you didn't have the UV2, you literally just swapped the left wing from 100% to 75%. So in the old days, we had to model a ship four times to do that, and then you'd swap between it. That's gone now. And that's probably the oldest ship in the game that hasn't had a touch. And that's on the roadmap soonish for an update pass.
TL;DRRework means a full ground-up rebuild, while improvements and updates keep the core geometry and touch up things like materials, LODs and cockpit UI; small ongoing quality-of-life changes usually aren't put on the roadmap.
I would say there's really only two, and it's just different people saying the same thing. So rework is a complete ground-up rework of the ship. Nothing remains of it. Improvements or updates is like what we're doing with the Merlin. So that core geometry stays the same. We're just perhaps redoing the materials to modern standards. We're updating the LODs. The big thing with the Merlin is just redoing the interior of the cockpit to match the metrics we have for UI now. So it had bespoke UI before, but it was very small compared to what we had deemed as our minimum screen space for UI. So that's been adjusted to fill that. And really that's just an update or improvement. It's not a rework, because only a tiny part of the ship has had a complete rework. The rest has just had a touch-up.
And oftentimes we've been going through and doing minor improvements to ships for ship components and stuff, just making sure that they have the appropriate spaces, adding doors.
Yeah, we don't tend to put them on the roadmap, those ongoing quality-of-life changes. If an artist is spending a considerable amount of time on it, then it goes on the roadmap.
TL;DRAwkward turret placements come from older concepts made with less thought, and ship style or starter-ship status; the team would ideally revisit some, and John guarantees the Freelancer turret will be addressed someday.
Three very different answers to those things. Part of it is the old concepts, where those things weren't really thought about as much as they are these days. We just go, we want a turret on the top and the bottom, that would give great range of fire, done. Whereas these days we do a lot more at the concept stage of putting cameras in the turret positions and going, that doesn't look as good as it should do, it doesn't cover where we want, so we'll change it, and then Paul will work with the artist to adjust that. Generally at the design brief stage it'll be: it needs to be five turrets, ideally one or two pointing this way, one or two pointing this way, and then we leave it to the art guys to pick a combination of what can hit those goals and what looks best. The Constellation ones, they're not great. I don't think anyone's a fan of them. It's also a starter ship.
Constellation is a starter ship? Well, it's one of the ships you can start Star Citizen with. It's one of the ships that you can get a game package with.
Those turrets are also sort of part of the style of the ship. If we change them to be something that was significantly better, you ruin a lot of the aesthetics of the ship. The Starfarer rear ones: the old flippy upside-down turrets didn't work well, which is why we spent a lot of time on the Valkyrie lower ball turret, where you stay the right way up. You gimbal with the turret. That makes the experience much nicer. Ideally, for ships like that, we'd want to go back through them and change them. There are some other considerations we need to do for that.
In an ideal world, we'd love to do that. We learned a lot during the Valkyrie, and that should be put back into the other ships. The Freelancer: those are always supposed to fold up into the ceiling. We will do something about it someday. That one I will guarantee.
The gate checks that we have at the concept phase, that is exactly what that is for. Every discipline will get involved and say, I don't like it this way, this will do this, this will do this. That'll be our feedback to go away, reiterate on it, come back, show them again, and then maybe they'll be happy. Then we do balance again for stats, and that's during the flight prep phase.
They're parasite ships, in terms of they require a sort of mothership to transport them around. They don't have quantum drives. If you have a quantum drive, you're not really a snub ship. We give them a different name. It might be a scout craft or something like that. So they require another ship to cart them around, and they're really there to provide protection. For things like the Corsair, it's a Constellation competitor. The Constellation has a snub craft and two turrets. The Corsair has three turrets and no snub craft, so they provide that alternate defense. Offensively, they're never going to win a huge fight. They're there to provide protection from things or provide deterrence.
I consider them full spacecraft. They serve a particular subset of a role, so the ones that are fighters are there for that deterrence and defense. The ones that are racers, they're great racers in their size of craft. If you brought an Archimedes against a souped-up M50, you're probably not going to win unless something bad happens to the M50. The 85X is a great little two-person runabout. If all you want to do is cart you and a friend around between relatively local destinations, it's great. It's not a Starliner. It's like comparing apples and oranges.
I mean, you can't stop a player doing what they want with it, because it's like the real world, right? I could take somebody's Aston Martin and put a luggage rack on it and put a ton of cargo on the top of it. No one's stopping me, but just because you can... It's like a transit van as well. You can make it a racing transit van, or you can make it a camper van, or you can make it an amphibious transit van, I guess.
You can spend a lot of money on your transit van to make it a racing transit van. You probably could have spent less on buying an actual race car, but two different experiences.
TL;DRThe team designs for what players are likely to do but can't anticipate everything, doesn't check every object that might fit inside, and treats unexpected uses as emergent gameplay that may inform future design.
Yeah, we always think about... We know what the players do. Everything that we think they're going to do and more. So when we're designing ships, we know this is what we want it to do. We can make a safe bet that people are going to try and do this with it, forever asking what fits in what. We know that everyone's always going to try and cram another ship inside another ship. So we know what we want it to do. We know within reason what it could do with some stretching. We can never think of what everyone would do. Reclaimer arm wrestling. Reliant jousting.
I think the phrase we use is emergent gameplay. We put it out there for the intended purpose, and then the community no doubt shows us all of its other capabilities.
And the thing is, because we're quite an agile company anyway, if people are doing something repeatedly, we can start to incorporate that into future design, I would say.
The dream of using the Caterpillar as a broadside machine, sitting there loading it up with cannons or with railguns and using it like the old-style sailing ship broadsides.
I've seen people with the Caterpillar with just the doors open, Arrows landed on every single one. It's now an aircraft carrier. And that was never designed to be like that, but that's happened, and it's cool.
I think we've got a good pipeline now. It's come on a long way. Things can always be better and smoother and faster. It's game development. Anything can happen. I don't think there's a single big thing missing out of the pipeline, really, that will go, oh, if we had this, we'd do ships in half the time. We're at the point of diminishing returns on improvements.
That's where I have to do the disclaimer. Again, building ships and building the gameplay systems are two separate things. We're talking about building the physical ship, not building the salvage gameplay or the repair gameplay.
TL;DRPilot view was overlooked on legacy ships because it wasn't part of the pipeline, but it is now checked with screenshots at concept review, and the concept team is reviewing older ships.
Not anymore. For the legacy stuff, yeah. It wasn't part of the pipeline check. Now it is. We have the seats, the pilot, the camera goes in the pilot's head. We get screenshots in front and left and right. No more strut-gate.
It's one of those questions that comes up at every single first pass concept review: what's the pilot's view like? And we can accommodate and show them, and then they can say, oh, you need more space, or restrict the view, maybe, for the characteristics of the ship. So that's why we take that.
It's hard, because spaceships for other mass media, for movies, TV shows, comic books, video games, whatever, are never built one-to-one. They're never built to actual proportions and built out to direct specifications. So they can cheat a lot of those things. You look at the interior of the Millennium Falcon, you look at the exterior of the Millennium Falcon... I'm sure Disney had some struggles the last couple of years when they were building their life-size one down at Disney World. But those were some of those lessons we had to learn, quite frankly, the hard way, from those early days when we were concepting ships the same way you would for a movie or a TV show, and then getting in there, developing the metrics over time and seeing how these things actually work in practice in a one-to-one environment.
Yeah, and the concept team, they boot up the game, they go into ships, and they're sort of evaluating some of the more historical stuff. So they're very much on board in terms of fixing those issues.
Yeah, there was one animation. It wasn't ever that the seat was designed to be that low. It was using an animation from another ship that was just incorrectly put on that ship.
I think the Hammerhead, the window at the bottom of the ship, that came out of a first pass review, because somebody said it'd be cool if you could see downwards, and then Paul's like, yeah, okay, I'll do that.
TL;DRModularity depends on the ship: it is sometimes built for gameplay, like the Retaliator modules, but mostly for production efficiency and performance, while gameplay swaps stay to big wholesale changes rather than small furniture swaps.
Depends on the ship. Sometimes we build the modularity for gameplay reasons, like the Retaliator modules, where that entire room can come out and be a different room. But also sometimes for art production reasons, like the Vanguard rework. The Hoplite central pod room is, well, across all the Vanguards, it's essentially four bays now, two on each side. And Joe, the artist who's worked on it, has built those bays to be modular. If you want to go nuts, you could build a Vanguard variant that had eight beds in it and no bathroom or anything, because they all just fit in those big slots. It's partly for ease of use in production, because for the other variants now we've moved some of the bits around, and rather than building two beds on the left-hand side built into the wall, now we have to build two on the right side. It's literally taking the geometry and putting it back in another way. For the Hoplite, we built a set of two jump seats with gun racks that go in that bay that can be cut and pasted around, so it speeds up art production. It's more efficient in memory. You're just loading one asset and instancing it. You're not having to load duplicate geo. But for gameplay reasons, we tend to stick to big wholesale changes rather than letting you swap your wardrobe for a gun rack.
Now, we use the term modularity a lot, and there's a stretch goal for enhanced ship modularity. We essentially have two types of modularity. We have developer modularity, what we use to build the ships, and then we have player-facing modularity. You touched on that a little bit: the Retaliator rooms, the living room, the bomb bay, the jump seats. That's player-facing modularity, the stuff that will come through the ship customization feature when that comes online. But what we're talking about here, when we build the ships, that's the developer modularity. That's to help with performance. That's to help with draw calls.
It's the same on the interiors of big ships as well. Those corridors aren't unique pieces. It's a two-meter wall section, a one-meter wall section, a four-meter wall section, an inside curve and an outside curve, repeated everywhere. It's part of the reason the Hammerhead was so quick to put in production, because that is the Idris kit with a new material on it and some new bespoke component hatches. The rest of that is all the work we've done on the Idris, rebranded.
TL;DRThey have metrics for a maximum ramp angle they avoid exceeding, but the bigger concern is access size, meaning whether cargo boxes of various predefined sizes can actually get in and out of a ship.
Yeah, we do have metrics for ideal ramp angles. It is shallow, it always causes problems, but we do have a maximum one that we don't tend to ever go past. Ideally, yeah, in the real world, professional haulers load off docks, so it's just roll on, roll off. But it's less thinking about the ramps and more thinking about the access sizes. So if this is a cargo ship, can it actually take 1 SCU cargo boxes in and out of that space? If I stack it four high, can I get them out somehow? If this is a ship that's not going to use 1 SCU ones, it's going to use the big ones, is there actually space in there to do that?
They go up in quantities. The biggest one is a 32 or 64 SCU crate, which is what you would see strapped to the side of a Hull C. You wouldn't have 4,000-and-however-many individual 1 SCU boxes on a Hull C. That's just not efficient. So the boxes themselves don't have a bespoke name. They just come in some predefined volumes.
This is another one of those legacy things. When we do our design briefs now, we have a drop-down tickbox quantity for what level of onboard facilities you have. Do you have no onboard facilities? Do you have Spartan, which is a bunk and a toilet? Do you have basic food making on there? Do you have a full kitchen? So yeah, there are some ships out there that might have a bed but no toilet. We might have to look at those in the future, but there are some where there is just a bed. It's not designed to be... That bed is there for a gameplay purpose, for providing logging in and logging out.
Less fully dynamic breaching; there are some big tech hurdles to go there. There are certainly going to be predefined areas, like you say, the doors; you're going to destructively and non-destructively breach through those. All the turrets' entry holes are a metric which is conveniently the same size as docking collars. Make of that what you will. And then there's obviously big windows that you can get in, elevators. There's very few ships where there's only one way in, and for those ones, that's a nice quirk of the ship that provides some defense.
So as we're making the ships, they still have these areas, the hatch areas, the door areas. But as far as anything more specific than that, I would say that probably depends on the development of the actual feature itself by the feature team.
TL;DRWebsite ship stats are updated manually and in batches, because some listed stats don't exist in-game yet and constant tweaks would otherwise make numbers churn, though they say they are working to improve.
So there's a few things. Both CIG and Turbulent want that to be better. It's a very manual process at the moment. Obviously, where it's a manual process, there's room for error. A big problem we have with it at the moment is those stats pages show stats for in-game attributes that just don't exist at the moment. So in an ideal world, we'd have a nice automated system that would look at the game files and then pull that and put it on the website. What do you do for stats that don't exist in-game, like jump drives? Do we just fill our in-game data with fake data? That's going to be as prone to errors as manually putting something on the website. So yeah, that's the big fundamental thing that stops it from all being automated and forever correct. Again, when we spot things, we tend to save them up for batches and just push them out in a bunch, because if every time someone spotted something that was wrong on the stats page we'd go call someone at Turbulent and say, drop what you're doing, this value is wrong, they would never get anything done either, because they have their own sprints and work to do. And so we just factor it into update chunks.
It's challenging, because there are designers that work on ships in three studios around the world. And I've witnessed the process of balancing, tinkering with these things. It's flying around for two minutes, and then going and tabbing and changing a number value and then going and applying. And I've seen a designer make 30, 40, 50 changes to just one single number in the span of 10 minutes. Tracking all that and documenting all that and having every single successive update would be a disaster. Because if that updated automatically on the fly to the website, you could go to the website and in any 10-minute period you'd watch the stats on the ship go and change and be like, what the hell's going on? So it definitely has to be in batches. Even if we have this automated system, it would definitely have to be in a batch, like a script that's run every two weeks or something, and go, okay, grab the current set of data. Plus there's the very real consideration, and this is something I can speak to, that while we are constantly saying all stats are subject to change, and this is game development, not game construction, all things are being developed and subject to change, we have a responsibility to minimize the number of those changes whenever possible. It doesn't do anybody any good to see the numbers on the Hornet change 15 times in a week, or two weeks or three weeks. While that tinkering, that balance, is a normal part of game development, having that be forward-facing and seeing those numbers change... There are folks who don't follow every broadcast, who don't read every article, who don't follow Spectrum, who won't know what's happening. They'll just see that these numbers constantly and dramatically change over and over again. So there's a responsibility on our part, to the feelings and considerations of the backers, to make sure that while we have to change these things as many times as we need to to figure out what the balance is, when we update them, we do it in as responsible and as timely and as limited a manner as possible. The term that keeps coming to my head is: you're playing with my emotions every time you tweak something. So there's definitely a middle ground there. The answer is us getting better with our documentation and keeping that together and making sure Turbulent gets updated, and not swinging the pendulum so far the other direction that we introduce instability in the stats. It's definitely a challenge. It's one that we've been working on for some time.
When we did the big stats page update, I forget when, but it was when all the shipyard articles came out, we had every single system designer that worked on ships look over their ship's stats. They looked over each other's stats. We had all the marketing and community teams look over those stats. So it must have had 30, 40 people look at them, multiple versions, and they still missed things that the community spotted within seconds. And it's the same story for brochures.
Oh, the number of review passes is ridiculous. We have so many eyes: player relations, community, customer service, legal gets in there, design gets in there, the lore team gets in there, I'm in there. We're all looking and we all spot things. And even with all those eyes, sometimes...
Yeah, when you look at the same brochure, 30, 40 versions of it, it gets tough to keep track of what's happened. And then someone will change the phrasing on something, and when you're looking at it, you go, yeah, that was what it was before, but it's completely changed the context of it. But because you've read 20 versions of it before, your brain just doesn't process it.
Which is why we bring so many people in, because we need fresh eyes to catch the things that you're not capable of catching the 30th or 40th time that you've looked at something. And of course, it's definitely something that we still strive to improve on. Definitely room for improvement.
TL;DREach speaker names a different favorite challenge: getting ships out to backers, turning sketches into a chosen 3D direction, and keeping unannounced ships in production secret from backers.
Well, me and John are two of the rare people who get to see it from Chris's head or John's head right up until it's in the game. So I think for me, my favorite challenge is getting it out to the backers. But it's very challenging sometimes, just keeping everybody on track, making sure everybody's communicating with each other, making sure metrics are correct, making sure that Chris has seen it and he likes it. It's all those key stages that add up to the end point of getting it out. It's challenging, but I like it.
There's a lot of challenges. I think there's one challenge that I really sort of hate, but it's also part of the process, which is basically going from the ideation phase of sketches, where you can go in so many different directions, and it's that sort of coalescing and transforming it into the 3D and really picking your direction. That part is, for me, the most difficult, because it's the most troublesome. There's a lot of feedback and a lot of iteration. But once we're on the road, on the road to Rome, on the road to success, you're like, okay, we're heading towards the second pass, great. Okay, now I know what I'm doing, we're on it. So you can't hide from it. It's just part of the process.
I think the favourite but also the most challenging thing for me is not leaking ships that I know about that are in production, because we often work sometimes a year, 18 months ahead of what people publicly know about. And there's been many times where I've been sat at events talking to a backer and they're like, oh, it'd be really cool if you could just do this ship, and it's like this. And you feel bad not being able to say, oh, it's happening.