TL;DRThe panel argues a good spaceship mainly comes down to a sensible, believable interior layout that is easy to navigate, plus looking good, while noting the best ship depends on what you want to do.
It's got to be believable. I think that's the thing that sums it up for me. That kind of covers the layout, the functionality, the visuals: believability. It could exist. Things feel like they're in the right place.
I still struggle to find my way around the Starfarer. I'm the one that looks after it and I still to this day cannot get to the crew deck without spending like five minutes going around the wrong way.
Gotta look good. Looking good's relative though, because it's different people's opinion. Argo is by far the best looking manufacturer. I love that big bright orange.
TL;DRA good ship can look ugly or brutal if its looks follow its function, but each manufacturer should keep a recognisable identity, with sleekness suited to role, such as workhorses versus fighters.
It can be ugly, in a sense, right? Brutal industrial, right? I think that can be iconic. That can look good, right? I think it's led by its function, isn't it?
If you've got something that is a big workhorse, an Argo ship, you don't expect it to be super sleek and organic. Whereas if you've got something that's a fighter or something that's like a racing ship or something, you want it to look sleek and feel believable.
I feel when it comes to our project, it's really important that our manufacturers don't merge into one. Our manufacturers have their identity. And then within that, you've got a subclass of what the functionality is. If we were doing, like I say, an industrial ship that was made by Origin, you wouldn't expect it to be like an 890 with a laser beam in front of it. But you would immediately want to recognise its Origin still. It's fine for it to be industrial, civilian, combat, all having a very obvious direction that the visuals go, but at the same time you still want all of the manufacturers to immediately be recognisable from each other.
TL;DRPerformance matters, but what counts depends on the ship's purpose, such as luxury for a yacht-like ship or combat ability for fighters and gunships.
I mean, yeah, obviously. But it also doesn't matter to everyone. Because there's a certain place in my heart for the 890 where I just like the image of living this luxury lifestyle and I don't care what its performance is.
Well, performance means different things based on what the ship we're talking about is. So in terms of the 890, its performance, I suppose, is how luxurious it feels. It handles like a super yacht, because it is a super yacht, but what would you say quantifies the 890 performing is it delivering the luxury experience. You're not talking about its combat capabilities when you're talking about performance, because it's not a combat ship. But if you're talking about the Gladius or the Hammerhead, you're talking about its combat capabilities: how well the Hammerhead's turrets can screen you from fighters, or how well the Gladius can do in a 1v1 dogfight and combat. So the performance is based on what the goal is to achieve with the ship. So performance matters, but what performance matters depends on what the ship's for.
TL;DRPlanning poker is a team estimation method where members privately pick time or complexity values, reveal them together and discuss differences, which gives the ship team more accurate estimates and lets them adjust scope to fit available time.
I should have brought the cards. I used to manage the prop team, and I've recently transitioned over to ships, so that's why I'm here with these people now. So basically, I mean, it's probably not the most legit. I'm sure there are agile development experts out there who would shake their heads at how I do planning poker. Basically, you have a stack of cards. It's got numbers on it that represent values. I tend to just do it in days because art tasks are pretty easy to break down in days. But if you're doing more nebulous things, you can use a point system. It's kind of weird. I don't really like that. I like days as a measurement. Do you guys use story points for stuff?
We use points, yeah. The only difference really is, as you said, art is pretty straightforward and easy to estimate how long something might take, but engineering tasks tend to have all of this R&D and experimentation work, and it's very hard to guess. So we tend to quantify things in terms of the complexity rather than the time.
It's like a consensus on how crazy what you're asking someone to do is, right? It's not necessarily saying this is six months of crazy, it's saying this is 30 crazy, right?
So you could probably derive an estimate from that, but it's a bit different. Anyway, so that's a bit of a tangent. But basically, so you have these cards, they've got values on them. Everyone has their cards face down. And you say, OK, so we're going to look at how long do you guys think it will take to do the white box pass for the exterior of the ship, for example. And everyone will have a little think. They'll select their card. And then you say, show your cards. Everyone presents their card. And you basically look and see if everyone's got a consensus on how long it's going to take or if there's a massive deviance. And if there is, you say, Henry, you said it's going to take you 20 days to do this task. But John said it's going to take 10. Why is it going to take you twice as long? And then you might say, well, here's a bunch of things that John didn't think about. And then John might go, oh, OK. Or he might say, Henry, pull your finger out, mate. Come on. But basically, the point is that you've got the people working on a task, and you're trying to reach a consensus. It does take a bit of time as well.
I think in the past what we've tended to do is we've tended to do this on a ship scale. So we've basically looked at a ship as a whole and kind of gone, okay, well, we know another ship of roughly this size and this complexity, with a really well known art style or a completely unknown art style. We've kind of broken it down that way. Whereas what this allows us to do is the team to have more input into that. And also because the complexity of our ships has grown so much over the years, it's no longer a case of, oh, here's a small single seater and all small single seaters take X amount of time, because some of them have one wing that you can just mirror around. Other ones have completely unique parts and completely unique functionality. And it just allows us to get a better understanding of how long we think things are going to take and because of that, hit our targets better.
Compared to how we used to do it, it used to be at a high level, leads and directors would say, it's roughly going to take this long as a best-guess ballpark. Sometimes it's been so long since we've been actively doing some of the things that our estimates have fallen short, or new tech's made it more complicated or easier. So we don't have as accurate an idea of it anymore compared to the people who are doing it day in, day out. So we've had a couple of ships go through this process now and the estimates we've got from doing this have been almost to the day correct. And with some of them we underestimated the whole scope and cut back what we were going to do because we knew it wouldn't fit because of the better estimates, and everything got as much attention as it deserved, and we now know we just need to go back and revisit something else later, but we also know how much time that's going to take so we can plan for it better.
Yeah, we can adapt the scope of a project to the time we have, basically, because we have a better idea of how long each individual thing's going to take. So we can say, right, we've got 30 days. All this is going to take 40 days. Ben, what are you willing to cut? And then Ben will say, well, this task is 10 days, so we'll cut that. Better planning.
TL;DREvery ship goes from a one-line idea to a design brief, director sign-off, detailed concept, planning, then white box to test it works and grey box for most modelling, with reviews at each phase.
So TLDR, as we start out, John and his design team come up with the idea of, we want a ship to do this role and deliver this, and then I think you normally sit around, you pitch it to people, don't you?
We have the very high level, like one sentence: I want a space food truck van. We use that as an example for this. And it has to be Drake. And either I've come up with that or I've got it from Chris or Todd or Tony or someone like that. I give that to a designer and they flesh it out into the full brief. That goes back around all the design leads because there's a lot of design teams and they're all working on slightly different things. They all may have slightly different ideas; the designer who did that vehicle brief may not be aware of, say, what EU PU is going to be working on in nine months' time, which may have an effect. So they all have their feedback. We update the brief, it goes to Chris for the final sign-off, and then it goes into the concept phase. Pretty much unchanged.
But we spend a lot more time on the concept to make sure that everything is going to work now. So we do the interiors fully fleshed out to make sure that everything that's going to fit inside the ship actually fits inside the ship. And with the extra complexity we've now got, there's so much more to consider during the concept phase.
It would also be worth adding to this point, obviously I'm not the most knowledgeable about the concept pipeline, but I am aware that concept is literally not just drawing a picture. I know you mock up the geometry of a ship and the general shape and everything. So you have a reasonably clear idea of what it's going to look like.
It's much easier to make changes and to invest time when it's in concept than it is when you get into production. Because in concept you've got one artist working on it and it's fairly easy to course correct. Whereas by the time you're into production, you've got an art team invested in it, plus all the downstream teams and design and everything. It's a much slower shift.
And you've got to worry about performance and actually having it work and stuff. Whereas in concept, it's a visual representation of it. So it doesn't matter if you look at the geometry and it's really jank, because we've got a whole team of production artists to basically convert a concept mesh into something that actually goes in a video game and runs, right? And looks good.
And looks good. So concept's complete, we then do proper planning. Planning phase. And then it gets scheduled. I'm still learning the new production. And then into white box, which is basically, we do a fairly quick breakdown of the ship and all the parts that need to be in it and get it into engine as quickly as we can, just to allow us to run around it, make sure that what we think works visually actually works from a gameplay point of view, and make sure it flies, make sure thrust is in the right position.
At the end of each phase we have a review process where we sit down with everyone, get everyone in a room and make sure we're all happy with it. White box is basically: make it work. We don't really care what it looks like at that point. It's about making sure that we know what we're doing and it's all going to work. And then into grey box is where we do most of the modeling, most of the artwork.
TL;DRLOD means level of detail, progressively simplified copies of a model used as it gets farther from the camera; LOD Zero is the highest quality, and changes after it are costly, so it is the last chance for edits.
LOD, level of detail, is basically you take your geometry, so your 3D model for the ship, duplicate it and then smush it down, optimize it more. You do that a few times. Less complexity, right? The further away you get from it in space, it will transition to the next LOD. So it's basically a way of optimizing a mesh as it gets further away from the camera. LOD 0 is the highest quality one, so if you've got your face up against this table, and you step two metres back, these ridges in the table won't be modelled anymore, they'll be flat. And also if, for example, we do LODs on something and then we get feedback about it, it kind of makes those LODs redundant, right? So you really want Ben to be like, we're not doing any changes to it after we've done LOD Zero. That's your last chance to say, change this, because we're going to move on to basically all these destructive processes that mean you can't really go back from that point.
Bear in mind, right, Corey joins the team, and within about two weeks, he's like, right, we need to talk about the pipeline. And I'm like, okay. And he's like, yeah, we need to change this. And yeah, it's much better for team health, much better for scheduling and everything else.
We're trying stuff. This is all stuff we're noodling with. It's not like, this is the way. I'm not coming in and just being like, oi. These are suggestions of things to try.
The situation you could get into is that you make four different versions of the ship geometry. And then myself or Mark come along and are like, that thruster's in the wrong place. And you now need to redo that area of geometry for four different versions.
Some things are easy. Because again, as you go down through the LOD chain, you're making the ship less and less detailed. And so by the time you get to LOD 4 and 5, moving things around a little bit doesn't really matter. Sometimes you play with the scale of them so that you reduce the amount of pop you get as these things change. But the LODs are the icing on the cake in terms of where it is in the production pipeline, but it's also the least fun and the most tedious part of the production pipeline.
TL;DRThe vehicle feature team mostly sits outside the ship pipeline, supporting it with tools and tech such as a new tool showing designers why thrusters are grouped as they are, which was received positively.
We actually are largely independent of the pipeline. The first reason is that we tend to try our best to not have to do code work for every single ship, just because there's loads of ships and it would be unfeasible to do so. So we sort of live adjacent to the pipeline, doing things to support it every so often. So that could be making tools to help designers, or a new piece of tech that you can integrate into the ship to make the doors open differently, something like that. And so we interact with the pipeline in the sense that we're trying to support it functioning. Most recently, for example, we made this tool that shows the designers why certain thrusters are being used in a certain way, which was received pretty positively, so that was good. So for example, the way the flight system works is it'll take the positioning of the thrusters that the artists have done and it'll try and automatically put them into groups to use them for certain things. So when you fly left, it has a list of thrusters where it's like, oh, I need to fire these thrusters when you go left. And that process is automatic. And the designers very often found that the thrusters were in odd groups and they didn't know why. So now there's a tool that shows them these thrusters are in this group and these are the reasons. And it's usually because, oh, you've rotated this thing in the model incorrectly or something like that.
It was a nightmare having to go through the entirety of the XML and find out where we'd accidentally put X or Y, or a minus instead of a positive, and there was no real good feedback for it. So we'd have to just comb through the whole thing and try and figure out what wasn't firing or why it was pointed that way.
Thousands of lines, and as far as the game knew, you intentionally put it that way. Because you're telling it that. You said fire down the X axis. It didn't know that you wanted it down the Y instead.
Well, if it's physically pointing in the wrong direction, it won't fire if the implementation file has it in the opposite direction, because there's a degree of functionality with it as well for how far away from the angle it can point. But then that was the other problem: if we were one degree too far on a fixed thruster or something, it then wouldn't fire, despite the fact that it was correct, positive X and Y, because the angle wasn't the right angle, and we wouldn't know.
TL;DRHow real a ship is varies by ship; thruster layouts are made believable but not always scientifically ideal, the flight system forgives imbalances, and moving parts like doors are physically accommodated so interiors fit exteriors.
If you look at the Hornet, that's a really good example of thruster layout for what a real spaceship would be, in that it's got a big thruster at the back, it's got two retros that are in line with it, and then the maneuvering thrusters are all equally spaced around it. So it's very functional. It's a cube with spaceship dressing on it. So that's a real spaceship. But if you want every spaceship to be like that, that's sort of the perfect layout, which means every ship's thruster layout has to be like that, just on a scale. The Gladius, hopefully everyone knows what a Gladius looks like: those thrusters aren't in line like they are on the Hornet, they're spread out because of the shape of the wings. So technically that's less perfect, less real, but it looks, in my opinion, cooler than a Hornet. And it's like that on every ship. We always try and make sure, and I'm pretty sure we have in every instance, but I'm not going to 100% confirm that, that every ship has enough thrusters to believably do what it's supposed to do. And they may not be in the scientifically correct place. If you look at the 400i, there's thrusters there to move it, but they could be in a better place, but that would mean changing the toothbrush nose of it. Snout. And that's where the rule of cool compromise comes in. And that's different for every ship.
The decisions that were made in the design of the flight system are such that we tend to forgive imperfections with regard to the balance of things. So the thrusters, their positions do matter, as Mark has made clear. But if you, for example, have a slight imbalance between the front and the back of the ship, the system will ignore the imbalance. But you do kind of need to be sensible, because there is a point where you can do something kind of dumb and it won't fly.
It's very good at mirroring real life in that way anyway, because I think with our advances in technology as a race, we could probably come up with the perfect automobile, right? We could probably come up with the car that is the most efficient, but if you look at cars on the road, most of them are different. And I think there's always a point in real life where a decision has been made to be like, okay, we could do it like that, but this way just feels better. This way is nicer. As a collective, we prefer it like this. And our systems allow us to have that freedom as well, pretty much.
I want to also give a shout out to the realism with regard to the way ships animate and move. Like you mentioned earlier, the way doors move and animate, all of it is not faked. There's physical space for how everything moves, which is really cool.
Nothing disappears into... Well, what you were mentioning earlier, which is, you start white boxing and you're walking through the ship and it's like, oh yeah, you've done the doors and everything. And you're like, cool, just put it in the outside camera and open the doors. It's like, oh, okay, all right. We can hide stuff if we wanted to. We just don't draw it when it goes into the wall. But we want to make sure... we want to sell the dream.
Those are the sorts of details that you can notice a lot of the time, especially when you've got lots of things that are breaking the laws of physics in subtle ways. The more they build up, the more it breaks that sense of, this is a real place I could be.
And it was a real stumbling block in the past for a lot of our concept artists who worked on other projects, and they were used to, it's just a movie set, or it's just a TV set, so I don't care where that door goes once it's opened.
The inside has to fit in the outside? It seems like such an obvious thing, but it's not a consideration that exists anywhere else. Not just in other video games, but in any of sci-fi.
But it feels great when it does, though, because everything makes sense. As you're walking around the ship: why is it so thick? Oh, well, that's where the bulkhead door goes. Why is this wall thicker than this wall? Because that's an outside door. And it sells the realism of the ship more, which is so important, that it feels like it could be a thing.
TL;DRThe speakers name different hardest parts: transform errors that cascade through nested objects, ships' overall complexity, unique-feature edge cases needing special code, coordinating a large global team, and justifying each new ship's role.
Basically, on an animated piece of geometry, every bone has a position stored on it. If you haven't oriented it correctly, that position is stored in the file and it can skew things. A helper point in the wrong way, so when something attaches to it, it's in the wrong orientation, or it might offset when it goes to its LODs, so something just flies out into space when it goes into the LODs, stuff like that basically. And it stacks on nested objects, so you can have a big corridor section that's made of like 50 child objects, and there's an XForm issue somewhere. It'll kind of compound everything beneath that. If it transforms it one meter off for the first child, then the next one's two meters off, three meters. So you just get this weird cascading event horizon. And it looks fine in the Max file. When you hit export, it goes in engine, and it's like, oh.
But you can't just look at the entity and go, oh, well, this is the parent of it all, so that's why it's wrong, because the entire thing breaks, so you've got to painstakingly go through bit by bit and potentially fix them all, because there's no way to see if it actually fixed it in Max, because it doesn't show in Max.
I think the biggest challenge, for me at least, is just the scope of a ship as a whole, right? It's so many different moving parts, so many different bits and bobs. They're just very complicated, and because of their complexity, you have to be very attentive and you have to make sure that you don't miss any details. And it's very easy to break stuff sometimes. And then it's a case of everyone getting their heads together and being like, okay, why is this broken? And you need someone from design to look at it, and then someone else will look at it and they'll be like, I don't know. You have to track down what the issue is. They're very complicated. I'd say that's it.
I've got an answer that is sort of unique probably to the programmers' experience of these ships. Most of the ships probably don't come directly through my hands, because the tools that we've made for the design and art teams work, and the ship is created, and it's all fine. From my perspective, it's all good. And then there are some ships that have special, unique functionality. And these are the ones that come through my plate, because the artists and designers will come to me and be like, this thing that we want to do with the ship does not work because there's no tech to do it or the tech doesn't support this. And those are the ships that are difficult to deal with. The turret starts on top and then it rotates around to the bottom: the Scorpius is an example of this. The animating section on the Hull C is another great example of this. A very difficult thing to deal with, the edge cases from that. Another thing is the thruster folding on the Redeemer. Those folding thrusters, they have special case code to deal with those. All of those weird edge cases of the things that make the ships unique and special.
There's a lot of challenge just because of the size of the team and the global nature of it. I manage a lot of people, so anyone that's done management of more than 20 people knows the pain of just keeping everything a well-oiled machine. And I think vehicle pillar-wise, if we include vehicle feature, the artists and designers in the US, tech artists and the VFX and audio, it knocks on to like 80 to 90 people, trying to get everyone all working together on maybe six or seven vehicles simultaneously in various stages, just getting that all harmoniously working and being able to tell the people at the top, yep, 12 months from now, this is what's going to come out, and hit those dates. And that's where the planning poker has helped a lot. The previous version was just, we give the t-shirt sizes of small, medium, large, extra large, and we just book those in. And the teams would always do their best to hit those dates. Sometimes they slipped, sometimes they were ahead. But yeah, that management side of it is a difficulty, but that's part of the role. But related to the actual ships themselves, for me, we have a lot of ships in the game, and it's every time we bring a new one in, getting a real believable justification for it. Because it's the first question you always ask me when we do the filming: why? Why this ship? And we don't want to just make them because they're cool looking ships. They need to have a role and purpose and not tread on another one's role, and all just work together nicely.
TL;DRShips like the Hull C and salvage depend on gameplay teams, so they try not to release ships before gameplay is ready, and salvage forced a pass over older ships' damage meshes, with some visual flaws likely remaining.
Yeah, absolutely, and that's it. There's things that are pipeline internal and then there's things that are game wide, and the Hull C is one of those things that juggles both, or careers straight through both. They're always the tricky ones as well. Sometimes we're ahead of those gameplay teams, sometimes we're behind.
We always get the damned if we do, damned if we don't. The ship could be ready, and in the past, we would have just released it without the gameplay. But now we try and not do that. But then it's the case of, well, hey, this ship's disappeared off the roadmap now. It must be done. So it's coming in the next patch. And it's like, gameplay's not ready.
Yeah, and things like the Hull C, it's [Hull?] on steroids, basically, because that rear section, you can walk around it, which you can do on the [Hull?], and that causes a whole lot of pain. Lifts in moving... anyway.
Three. I have quite high expectations for that, and so that unfortunately requires some additional work from the different teams to get that looking right and feeling right. Okay, and then, talking of salvage, that's one of those things that is somebody else's baby and feature and has a massive impact on all of our ships. So the team, Henry's been spearheading some of this stuff, have been working exceptionally hard looking at all of our current ships that are in game. All of their damage and underlying damage meshes were created for a damage feature that was worked on many years ago, and now we're like, well, that works for salvage, but some of it works great, some of it didn't. And so we're going through, and for me, I love supporting new features. For us to take all of the damage meshes and the UV2s on ships and everything and do them to a gold standard is years of work. And I don't want to be the person that's holding back a feature that can be really good fun for the sake of me being like, you can kind of see through that bit, kind of see through this bit. So we're going in, getting all the ships ready, getting all the UV2s updated. We're improving damage as we can as we go through.
And that's what I mean by impacts our pipelines. It's tech debt basically. And I mean, that's the natural part of being in a project that's creating new features, right? The ships we made several years ago, they're not necessarily going to be fully compatible with these new features we drop. So that is tech debt, and that's sort of a part of development, right? And basically we just had to triage the ships.
And there's good kinds of tech debt and then there's kinds of tech debt that you can avoid, right? But things like salvage, we want the damage to look good anyway, so it's a pass that, you know.
Yeah, the salvage work that necessitated all this was built off the damage system, which we introduced with the Gladius, I don't know, 2015, 2016. And that system hasn't really changed since then. And it looked good for damage, like when you're shooting another ship with a spaceship 100 meters away and you see the burn and the glow and everything come on. And when we looked at salvage, it was like, yeah, we've got a system, it works. But then when you pressed your face up against it, scraping it with a thing, it was like, no, actually, this technically works, but it's not to the standard we want.
I think as well, over the years, you call it rot or just changes and stuff, damage maybe hasn't been scrutinized as much because it hasn't needed to. And then when a feature like salvage is coming up, we sort of need to take stock of where everything is now and review it again and be like, these ones probably want a bit of love, right? And then there's some that you're like, oh, that'll work. It's not all going to be perfect for tier zero salvage with hull scraping, but it will work as a feature.
The visual damage will all mostly work. And the shader's had a bit of love, and we've created some new textures for it as well, so there's a little bit of visual polish that will benefit damage as well. Less tinfoily damage.
On the plates. Dan's done a great job on the team. We've got issues that were ship-specific, which means we have to touch every ship, and then we've got improvements we can make that are ship-wide, and the new shaders and the texture improvements and stuff that we've done affect all ships in one go. There are going to be cases where you salvage a ship and you might see a bit poking through. It's still fun. We did our best. We've done some work on resource management. And we're in prototyping phases, getting stuff in and working. But we're not at the point yet where that's actively rolled out across ships and we haven't done a big pass and stuff. We're early days with that stuff.
TL;DRThe ship team members each give personal reasons, including the puzzle of ship design, a sense of adventure, fascination with physics and realism, sci-fi fandom, and simply loving how the ships look.
They're so complex that, for me personally... every single one feels like it's a puzzle that needs to be solved. And solving that puzzle for me is really satisfying, to put it bluntly. It's why I like doing the layouts of ships so much. Does it make sense to put a corridor there? Why does it not make sense to put a Jefferies tube in anything? Why does this ship need a rework?
For me, it started a very long time ago at my former job at a former company. I was sat there one day and a colleague reached out to me and was like, I'm working on this project with someone I can't talk about, and he's trying to put a one kilometer long spaceship in our engine with a full interior. And I was like, that's impossible. There's no way that could work. And he's like, well, here you go. Here it is. And I was like, oh. It is possible. Cool. This seems like a fun thing. And then some months passed and then I ended up here.
As an old backer of the game long before I worked here, for me it goes back to just the sense of adventure of going to space. That's a very fundamental driving feeling behind being interested in spaceships. And then the second level, which makes Star Citizen particularly interesting to me: I'm also a physics nerd, and the realism and physicality of the game and how things work is just unbelievably satisfying. So you get this double hit of the sense of adventure and wonder of going to space, with this feeling that, oh, this can actually work. And it's just so satisfying. It just feels really good.
I mean, I've been a longtime fan of sci-fi and space games and space stuff. And coming to this company was a really exciting opportunity for me. And I had a really great time working on props and weapons. To be honest, I'd been on the props team for a very long time and I kind of fancied the change, and this opportunity presented itself to me. And I've always really admired visually the spaceships in the game and how they work functionally. I find it just amazing. So for me it was a chance to renew my passion in a way. When you've been doing the same thing for quite a long time... don't get me wrong, I love props, and that team was so fun to work with. But starting something new again, it's exciting. I feel like I've got a lot of challenges and things I need to learn again, which is a feeling I haven't felt for a while, if that makes sense.
H
HenryVehicle Artist
Oh, they're just the best looking thing in the game, aren't they? I mean, I'm pretty simple in that way.
I think for me, I grew up watching Red Dwarf on VHS over and over, and then watching Star Trek and Star Wars. And I think, like you said, that sense of adventure is a big draw for the project. When I first saw what Star Citizen was, I was making racing games and that side of things. The vehicle art being inspiring is one thing, but I don't think I'm lucky enough that I will make it into space. So this is as close as I can get. My kids might, if they're lucky. Star Citizen for me is a game that I really want to play, and I want to have that exploration. Playing Star Wars Galaxies and those other games, the big MMOs and exploration, that to me is just a huge driving factor, the exploration of the game. And also, I told my sister that I was going to go and make spaceships, and she thought I was going to go and make real ones. And I'm like, no, Sammy, I make video games. I do not go from making cars in racing games to actual real life spaceships.
TL;DRTeam members pitch personal wishes, including colonizing ships, a giant mobile ground base, organic creature ships, junker ships, a questline-restored old ship, and an early quantum-capable ship.
I'm going to keep pitching to John the idea of us making a giant ground vehicle base. That's what I want to see in game, so I'm going to keep asking John. A giant ground vehicle moving base. So think like a giant tank that has three floors on it. Like Mortal Engines, a Mortal Engines style giant base. That's what I want.
So I don't know how the artists might enjoy working on a ship like this. However, I love the idea that exists in some sci-fi worlds of organic ships that are organic creatures and move in weird, strange ways and are animated very fluidly and smoothly. The sense of wonder and strange newness from that just appeals to me. And I'd like to see something like that out there.
There's definitely space for more alien ships in our universe. I'd like a traditional space rocket, just because I think it would just be cool, right? Proper portholes on the side of it, big thrusters, takes off vertically. But I've just seen Space Sweepers and their junker ships. For me, that's what our universe is missing. It's not a manufacturer, and I've been harping on about how important manufacturer identities are and everything. It's not a manufacturer. It is people that live in the... duct tape together, Scrapheap Challenge style. A ship that people have passed down through generations, that has been cobbled together with whatever they can find, and it might see a station once every 10 years, and it's really unique and homely and it has a personality of its own.
H
HenryVehicle Artist
Wallace and Gromit ship. The one from Wallace and Gromit.
The thing that I want is the old space jalopy. I want a ship that isn't sold. You can't buy it in a store. You can't pledge for it. It's the old hulk that you have to find, and that you have to repair. Basically you have to go on a 28 point mission through 13 different planets and locations and find the parts and basically reassemble this thing. And what you've got is not the fastest and not the most capable or anything. It's an old 200, 300 year old spaceship. But when you're done, it's a status symbol. I put in the work, I put in the time, and it's a collector's item, and it's restored. It's like an old classic car. I would like a questline ship, something that you have to pursue and develop through gameplay.
For me, it's sort of like Ben's. I want to do either the original Zeus or an [Asperia regression?], which, if people don't know, is the first RSI ship that could do a quantum jump, that had a quantum drive. I think they were notoriously unreliable. So there's a lot of them just scattered around the universe. What if we combine the ideas? It's just a really cool visual. It's like the old space plane.
TL;DRReleasing in stages helps the team see what the new combat system, with balanceable shields, weapons and thrusters, adds overall before tuning individual ships, which can only be judged in real combat.
It makes our life a little bit easier in terms of basically understanding the changes we've made to the game in terms of the feature set. So the big change for 3.14 is we've got a brand new combat system where you can balance your shields, weapons, and thrusters. And that's a new system. So basically going backwards a little bit helps us understand how that system is influencing the game. Rather than being bothered about how it works on the individual ships as much and being caught out by tuning it to a set ship or not, we get to see an overall experience of what this has added to the game. And then we can look at it from an experience point of view and go, right, what does this feature allow us to do on this ship, on that ship? And where does that ship need to fit? Because we've done a rough guide of where the ships fit, but until we see it in the combat situation, so we see all the ships fighting each other and the different weapons and different missiles and torpedoes all come together in terms of the combat, we don't really know, because there's so much to test. There are so many ships.
It's worth pointing out as well that we don't, we also don't want to... And it just so happens, I think, especially in the case of 3.14, making the game fun for this particular feature set that we have now also helps us understand the features that we have changed for this release, which is what Rich and Yogi are after.
TL;DRThe roles of ballistics and energy weapons haven't changed: ballistics still damage the hull through shields, but now have limited ammo with no regeneration, unlike energy weapons.
They pretty much haven't changed. I mean, the balance has changed, but the function and the way that we intend for them to work hasn't really changed. The idea pretty much has been all along that ballistics are not, like, 'oh, they only work against the hull of the ship' or something; that isn't quite true. The shield is taking away some of the stopping power of ballistic ammo through absorption, but they still will then go through and attack the actual hull, even if you have a shield up, which is how it's always been. We've changed some of this a little bit, which maybe Yogi knows a little bit more of the detail of what's happening there. But that's largely the idea. The ballistics then become obviously very desirable because they can damage the hull even though you have a shield up. But obviously a lot of work has happened in this patch to make ballistics this significantly more valuable thing, where the ammo is much lower and they run out really quickly and they don't regen in the same way that energy weapons do. But that's kind of the trade-off. You can do loads of effective damage to a ship with ballistic guns, but you don't have this cool feature with energy weapons that you can regen the ammo, which is how we're trying to balance this.
TL;DRBallistic magazines were cut and damage raised because continuous fire streams were too powerful with no other way to force pauses, making players choose when to use them.
That is mostly down to the role we want to see in ballistics. I mean, the purpose of ballistics was always to feel limited but powerful. And in 3.13, we didn't really have that. Ballistics were practically just cannons which looked and sounded a bit different compared to laser weapons or energy weapons. I mean, they had fire times of several minutes. And it comes back to the thing that David said before: we want to give these things purpose. And the specific issue that we had in 3.14 was the length of a continuous fire stream which you could put out, which was always much more powerful than the energy cannons, which had natural fire pauses because they needed to regenerate. But that offset was very, very large still. And even when we equalized the DPS outputs of energy repeaters versus ballistic weapons just to see how they would perform, the ballistics were still a lot, lot more powerful because they could keep up this weapon stream. And at the moment we do not have any other ways to force a break in that fire pattern. So for that reason we harshly limited the ammo and also upped the damage quite a lot to force players to make very conscious choices about when to employ those weapons.
Sorry, there's one extra point I forgot to mention about ballistics, which maybe we shouldn't go into too much detail on, but Mark mentioned the physicalized damage. When that comes along, ballistics' roles will change. And obviously certain ships that have very high armor will then be much more resilient to ballistics than they are now, right?
So there's more work we want to do on them to make them feel different in the future. But everything will make more sense once the physicalized armor system is in. But for now, we're happy in terms of where it brings us in terms of weapon versus ship balance.
This is just because we can't do it any other way at the moment. But this comes back to the question we had before. We'll talk about these things in 3.14. But specifically for that reason, we swapped out most of the loadouts of the ships to have at least 50% energy weapons. And only a fraction of them actually have ballistic weaponry on board. But yeah, obviously that is the case. If I'm flying in a huge capital ship, then of course it makes more sense if we can dish out a lot more ballistic rounds.
To be clear, when we say we can't do it, it just means that the system right now needs reworking to do that. And for this release, we lacked the time to actually do that.
TL;DRThey have no exact time-to-kill target, since it varies with pilot and sub-targeting and a fixed number would encourage meta builds, though perceived time to kill was too long.
Okay, so in general, from the feedback in our combat tests that we had before 3.14, the perceived time to kill was always too long for us. Because you could tape your fire button down and fire forever and eventually ships would explode, but it was not really meaningful. I think giving an exact time to kill is not really working because you cannot really measure it properly. Combat is very dynamic, and depending on how a pilot flies his ship, if he makes a left barrel roll or takes other maneuvers into use, the overall time to kill changes so much based on the individual pilot that it's not really useful for us. And also, the other thing with exact time to kills is that it kind of tells you, hey, you have an exact number you're aiming for. And I would say no. Because if you just look at numbers and then you have tools that data-mine the game data and try to draw strategies out of that, this is something we would like to avoid. We want to avoid the gameplay of building a meta build that will always be better than all other builds combined. So as such, for us it's not important to get an exact number, but rather to experience how these ships and fighters and shields feel, and if you as a player think they give you the advantage that you need. Because ultimately, we want to play a game and not read out an Excel sheet. So that's why we do not have a specific time to kill. We roughly know where we would want it to be, but this is some data we really don't want to give out, because we want people to enjoy it and tell us, hey, this is too long, this is too short, and then we adapt it accordingly.
I would add that as we improve the actual flight experience, as in moving your ship around in combat, we want to head toward a situation, which I think we've done a pretty good job of in this patch, where it's not a DPS race of just hold your gun down and then eventually the ship explodes. And so the result is that, particularly in this patch and going forward, combat is not about waiting for the health to go to zero or something. A simple naive way of doing it is, oh, you hold down your button, and then the ship blows up. And in the older patches, that was like two seconds. But the actual experience, like what Yogi is saying, when you actually have a fight with a real person, it doesn't feel like two seconds. And that issue is much more magnified in this patch, which is why this is the way we plan to do it.
And of course, we're using the phrase time to kill, but with physicalized damage and armor and stuff, at some point it's going to morph into a time to disable, I suppose, would be a more appropriate term.
It also depends what you're targeting, too, because now you have sub-targeting and more items are getting physicalized. If you want to kill the ship, maybe you aim at the power plant and it blows up. If you want to disable it, you shoot out the thrusters. If you want to just disable the guns, maybe shoot up the guns. The definition of a win is different.
TL;DRThey don't want a tool giving an overall ship health number because it would encourage number-adding meta thinking and misrepresent a ship's real durability, and they currently lack such a tool internally.
Well, a tool like that would actually emphasize the thing we want to avoid, which is building a meta gameplay. We do not want players to say, OK, if I add this part and this part and this part and this part, I have 20,000 HP together. But those 20,000 HP give you no idea what the actual effective HP of a ship is. So even if we had this tool, we wouldn't want it to be an effective thing in your decision making. I mean, if you buy a car, maybe you look at how fast it can go, but you're not really interested in the exact number. You're interested in how it handles, if it's safe, how many airbags it has. But you do not care about, hey, it has a top speed of 260.5 kilometers per hour. You do not care about, hey, the frame will dissolve itself when you crash it with that much velocity into a wall or something. It's always about the experience. And I would like to avoid that kind of thinking that you just add up numbers. Star Citizen is not an RPG where you do that. It's supposed to be a believable gameplay simulation slash experience. And as such, I would like to de-emphasize the pure number thinking and go more to the experiential view of things. That said, we actually do not have a tool ourselves to display all the data. Sometimes it would actually be useful, but at the moment, sometimes we actually have to draw the data out of XML tools.
There's also, on top of us wanting it to be experiential, a lot of subtlety to the combat system that makes giving numbers actually quite hard. A really good example that we have had is that a certain fighter could have, I don't know, let's say 50,000 hull HP points. But it has, say, a wing or some other part that's extending out and it has thrusters on the end of it. You could, for example, break that part off without dealing all of the HP damage and have effectively nullified the effectiveness of that ship. Which makes the actual HP, for example, not actually that representative of what fighting that ship is truly like. And that subtlety is not captured in straight numbers.
TL;DRThey aren't against a meta emerging and want players to discover and debate setups themselves rather than being handed hard numbers, with different scanners giving role-specific information to support varied gameplay.
I think, what a desirable experience... Yes, there is meta. And I think we're not necessarily working against that, because the players can still play the game and figure out the meta and make their own notes about it and try and learn about the game by playing it to then decide on what the meta is. And an ideal situation is a group of players play and they find that a certain configuration of components works really well. And then a different group of players start from a different starting point and discover that actually a different set of components is better. And that kind of variety in the community, that's desirable. And you're not going to get that by the game giving you just hard numbers. You're going to get that from people trying to learn about the game and quantify it and then having disagreements and discussion about it. That's what we really want.
One other aspect of this, too, is going to be scanning. Depending upon what you want to do, we're going to have different scanners give you different information. If you're a mining prospector or something like that, the scan that you're going to get on another ship is maybe not what its guns are. Maybe it's not any good information about combat. Whereas a fighter ship, when you scan something, it's going to tell you how combat-ready that is against you. Whereas a more security ship is going to want to scan and give you maybe how much bad cargo you have in there. So it also depends on what we want to give the players when you scan and what information to get based on the role of that particular ship or what they're trying to get at. A medical scanner is going to give you something different than someone who just wants to blow stuff up. If you go in the game and you just want to blow a bunch of things up, eventually the idea is you're going to run out of money. If you blow up a cargo ship or a Prospector that has a bunch of valuable cargo, you just lost it all. You want to disable that ship and maybe capture it, but that's going to make that Prospector maybe call in his friends. So a lot of it right now is how can you get away from just making the gameplay blowing people up? How do you incorporate different information so that different gameplay aspects can come out of it?
I mean, you're going to get the people that want to blow stuff up. But if you repeatedly do that, how are you going to get money to continue to blow people up?