Developers discuss the Crusader Spirit bomber variant and its stat mix-up, the Greycat STV and upcoming ground vehicle handling changes, and the design process for the RSI mining ship. They also cover the 600i rework layouts, master modes, and programmers' work on PES, hull scraping and the resource network.
TL;DRReception has been good and people are excited, but the stats were confused because several errors slipped through at once; they say these are now corrected on the website.
It's been pretty good. I think everyone's been super excited about it. A lot of confusion over the stats. We made a mess of that. It was one of those beautiful storms of so many things that in isolation going wrong would have been caught, but because lots of things happened all at once, they slipped through. But I think we've got them all sorted now, so it's all correct on the website. I enjoyed it at the weekend, going on to Reddit and looking at all the theorycrafting of what fits, what doesn't fit, what is the real size. I'm like, what is going on? Why is it like this?
Yeah, that was the same with me. I saw someone who put a post of, like, this just doesn't fit this size. And I'm like, I'm sure we fixed all of this in concept. The first thing we do is make sure things are the size we need them to be. And clearly something had gone wrong.
TL;DRThey wanted to offer more than one bomber choice and fill a gap between existing options, with the Spirit's bomber variant filling a middle spot because not every job needs a sledgehammer.
Why? Like with a lot of Star Citizen things, we want to not just give you one choice. If you like bombers, you sort of have the Hercules, and whilst that will have its other bomb option in the future, there was a huge range there and we wanted to put something in the middle. And when we were coming up with the Spirit, we knew we wanted to do variants at that time, and doing the base cargo one and a VIP one were a shoo-in. I was like, what's an interesting third one? And there were a few things that we could have gone with, but with the Hercules A2 in the lineup, it was like, well, let's put something in the middle of it. Kind of fits the brand. And like I say, not all jobs need a sledgehammer. Some of them need something a little bit more...
TL;DRAll stats are subject to change, and bombs already have minimum arming distances, though the current implementation has quirks, such as a bomb failing to arm near the ground while a slightly higher drop works.
All stats are subject to change. There's a lot of gameplay systems; the Centurion existed as, not a counter specifically to bombers, but a counter to threats coming in to attack ground locations. And it does okay at its job in some aspects. There's other things: the bombs themselves do actually have minimum arm distances and minimum safe ranges before they're supposed to activate, to prevent some of the problems that are out there. And we were looking into it recently and found that technically, it's one of these very programmery things, it does work. However, in reality, it doesn't work the way you think it works. There's a minimum safe radius for the bomb to arm, which is something like 50 meters. And that means if you've got a Hercules that's 49 meters off the ground, you drop it, it hits the ground, doesn't go off, great. The Hercules then flies two meters higher, the bomb then goes off. So there's lots of fun things like that that we're working through.
It is. There is a design for it, but it is not in the purview of any of the teams that myself or Ben look after, so it wouldn't be correct of me to sort of tell those teams when it's coming.
To be honest, the reaction was really, really good for it. It's a cute little ground vehicle. There's not a lot not to like about it, but I think it kind of ticks the utility needs, it ticks the racing needs, and I think it's a good all-rounder, and it seems to have gone down really well. So, very happy with it.
TL;DRMore ground speed changes are coming with a new tyre and vehicle handling model; the recent change was a last-minute approximation in the old model, and they balance vehicles based on performance.
So there will be more, as I mentioned in the interstitials, which I don't think made the cut into the YouTube uploads, so unless you watch the full show... To try and not redo it again in full: there is a new tyre handling and vehicle handling model coming, and we had redone the ground vehicles for that. But because of the way time works, and 3.18 didn't come out on the Evocati before 3.17.3 came, we had to very quickly, at the last minute, put an approximation of those speeds in the old model just to get the ball rolling. Because if we had saved it, that same change would have just happened very close after, and everyone loves to think that we nerf ground vehicles immediately after they're released, and that's not the case. We balance them based on how they're performing.
I'm kind of sensing a bit of a theme here, because that happened, and then the Spirit, and there was a lot of confusion over the Spirit that kind of took the heat off of... You've just slowly always got to put something in.
Don't ascribe motive to things that just... It was an honest... Yes, sometimes things happen, and we had a meeting about it, and it was me and a lot of people inside the company being very angry, pointing fingers at me for doing this. I was like, it's this or it's the other way, and they're both going to have some negative reactions, so let's do it now rather than later.
Like all things, it starts with a design brief, and that's actually sat on my desk back in the office. So when I'm finished here, I'm going to give it my sign-off and then pass it around through the design leads and Chris to give it the final sign-off. And then that's where Ben and his team will come in. This will be one of the ships that I'll be running from concept forward, whereas up until now it's always been running the production after the concept process. The new ships at the moment are going to be from concept forward. So it'll be a nice learning curve, to make sure we learn from some of the issues we've had with making sure things are correctly documented from the start.
TL;DRLayout comes first because everything the designers want must physically fit and it sets the ship's size, followed by art style informed by the manufacturer's look and its place in the timeline.
Really early, the layout is what we need to work on first, and really that's the stuff that sets the foundation of how big the overall ship's going to be. Because a lot of the time the design guys will have their wish list of 'these are the things we want to fit in the ship'. But because our game is the way it is, that needs to physically fit in the ship. And that can dictate a lot of how big the ship's going to be and how much space we want to assign to the different elements of it. And then once we've got the floor plan down and the rough idea, it then goes into the art style, looking at all of our library of RSI stuff, looking at the bits that... lots of, yeah, all the struts, the weird kind of angles. Lots of nice sharp angles in it. But the thing with all of our stuff is there's a timeline to our game as well as our manufacturers. So we've got to decide where it sits on the timeline of [RSI] itself and when its release date is.
TL;DRAn RSI ship should still keep its core angles and struts, since that's the brand, though manufacturers' identities can change over time, as Aegis did.
Aegis is a great example of that, because back when the project first started, Aegis were, I think, a dead manufacturer. The Gladius and Retaliator were the last of their lineup. I think they'd lost... narrative people are going to be screaming at me now. I think they'd lost all the recent UEE military contracts to Anvil, so they'd essentially gone out of business or similar. But because this is a game and things can change, when Foundry 42, as it was back then, came on and we made those ships, Chris loved them so much that we're like, let's do some more Aegis ships. So the brand came back from the dead, and then you've got old Aegis, and then you've got new Aegis like the Eclipse and the Sabre.
TL;DRThey expected mixed reactions to master modes and couldn't cover everything at CitizenCon; the questions about ganking and racing will be explained in depth later by the team, with a joking "yes, ganked" aside.
Yes. With a change of this scale, we knew this reaction was going to happen, and there was only so much we could put into that CitizenCon presentation. I think the guys did a great job of getting the basics out there, but we couldn't cover everything. So there was lots of questions about, hey, is my cargo ship just going to get ganked all the time now? Or what happens to racing?
We knew those questions would come up. We just didn't have time to expand upon it in that piece. So when Rich and the team get a chance to do it again — like I say, it was supposed to be today, but sickness and holidays fought against us — we'll go over what the plans for those are. It's their pet project that they've been working on for a long time, and it should really be them that gets to explain it in depth.
At the moment, we've done a high-level concept pass on it. We've worked out the floor plans. We've worked out where the space was wasted. And we've massaged a bit more functionality out of the space that we had to play with. Like I said, we've done our floor plans, done our concept pass, and it's just waiting for its slot, really. On the ship team, we tend to plan; ships take a reasonable amount of time to do. You do little ships, they're a bit quicker. You do big ships and they are a large investment of time. And really, the 600 is a fairly sizable ship.
It is a rework. It's not an update. The majority of the interior is changing one way or another. I think the captain's [quarters] is the thing: the bridge and the captain's quarters underneath it.
TL;DRIn the 600i rework the entire back half interior becomes the swappable module with the middle as shared crew quarters, while the exterior stays largely true to the original with some changes like docking collar and extra windows.
Yeah, without spoiling the future thing, just to say layout-wise: currently on the 600i, the middle section is the module that changes. Mentally, think of the entire interior back half changing as the module now with the rework, and the middle section is the shared crew quarters. That's the best way to think about it in terms of where you're seeing these images. This one here is the back of the touring module now. So you see we've kept the big glass window.
Yeah, we've tried to stay true to the exterior as much as we possibly can. There is going to be a few subtle changes. It shouldn't grow or shrink or change in any form. So it should be the 600 that everyone... yeah, you can do that face... but it should be the 600 that everyone loves already. But we need to improve the docking collar.
TL;DRThis is the Explorer's cargo lift area, which in the rework can fit a Nova on three decks with interior lifts, but it is concept only and production on the 600i rework hasn't started.
And just to make people extra happy, that cargo lift fits a Nova on there now. When we say there was a lot of wasted space inside the 600i, there was a lot of space in there that we've claimed back with the modern way of thinking of doing layouts. There's actually three decks in the 600i rework, and the bottom one of the Explorer can hold that.
So we've got the cargo lift. You can see in this there's actually a few interior lifts as well to allow you to move cargo up through the ship, because there's other areas of the ship that allow us to store cargo as well.
The big cargo lift in the middle of that picture only goes to the outside, and then the one closer to you goes between the decks. Again, this is all concept. None of this is in production yet.
Yes, and there's again a decent amount of size, so each crew should have multiple suit locker space, multiple weapon racks. It's well decked out. Big moon roof. And then this looks like just an alternative. We can't decide on what colour we want it.
Not decided, and I can never remember which one. Interior tinting isn't doable. As much as I hate it, it's just something we can't do yet. So it's one or the other at the moment.
Yeah, so basically you're not having to bring your cargo up and just leave it there and then not be able to fit anything else in. You can bring that cargo up, move it up to its storage, and then you've got that ramp free for other activities.
TL;DRProgrammers turn designers' ideas into working code and often build the tools designers use, also doing some initial UI and design work to test features before handing them back.
Well, trying to explain it to your granny is always a bad idea, because they're not going to be interested. But what we do is basically we turn the designers' ideas into something that will actually work in the engine. Often what we do is we make the tools that then the level and content designers use to create the gameplay.
Y
YaroGameplay Programmer, EU PU team
Yeah, I guess Torsten comes up with an idea. He sends me a GDD. I then look at it, and then we translate it into code and tasks, and then do the tasks, and just combine the code together.
Well, depending on the feature, a lot of the times we will also be doing a bit of the initial UI work or a bit of the initial design work, because we need to actually test the features before we give them back. So you end up doing a bit of everything, honestly.
Often our job is to crush the designers' dreams, because they want to do all this, and we tell them, no, you can do only this.
Y
YaroGameplay Programmer, EU PU team
No, I mean, I think it's more about adjusting what design is like together with code so that it functions together, so you don't end up making a specific feature for one tiny thing if it can be a bit more generic and suit more things, so that we don't repeat code all the time. Because obviously nobody wants to write a lot of code and then it just gets trashed because of the new feature.
No, you're absolutely right that a lot of the gameplay teams are now having to rethink their code to make it properly compatible with PES. A lot of it works, but a lot of it needs some tweaks, some improvements. So one of the largest tasks on us at the moment is to re-evaluate all of our existing systems and make sure that they're up to date with the latest tech.
Definitely not. There's still stuff to do, but we're at a really good point at the moment. It's mainly putting the finishing touches on and bug fixing.
It's cool. I feel like there are possibilities for the resource network and incorporating different types of interaction. We're also talking with Guillermo about that. There's a lot of gameplay opportunities. And I feel like that's also to add to what a programmer does: we also come up with ideas and then go to Torsten and say, oh, maybe we should try something new.
It was to repair a vending machine? Is that what it was?
Y
YaroGameplay Programmer, EU PU team
Yeah, it was a whole vending machine simulator, basically, with lots of parts you could pick apart and some fuses, whatever. But then you need to translate it into the game with networking and all that, and that's obviously way more work.
TL;DRIntegration depends on how close a release is, but for the resource network they were allowed to rewrite the system, and its storage containers will use the same underlying logic as physicalized cargo containers.
So usually we have two things. Either the release is pretty close, and we cannot really rewrite the game fundamentally to support all the things we would like to do. Or, in this case of the resource network, it's actually the opposite. We usually just go to one of the directors and say, hey, this system is not really compatible with what we want to do. And people say, okay, fine, rewrite it. Which is kind of liberating. You're not really held down by your own old code. That usually comes to bite me in the ass a lot. But no, actually, you get a lot of freedom to sit back with everybody who is going to have to use this system and say, okay, what does everybody want out of it? For instance, in this case, the resource network: all the future storage containers, the fuel, power, stuff like that, use the same underlying logic as the cargo containers that we're getting with physicalized cargo. So if the resource network has to move cargo for whatever reason, maybe refinery ships, stuff like that in the future, that's going to be the same system.
A fair bit. Every single sprint we have, there's always a section of bugs to fix. Some of them are ones that we caused, some of them aren't, some of them are things that are just a side effect of other things changing. But we spend plenty of our time bug fixing.
One definitely stands out. Recently we've had quite an amusing one with the room system, because we found that we were getting some room system crashes when people were doing stuff with the inventory, and that doesn't make any sense, they're completely unrelated. Eventually, after a lot of pain, we figured out that it was to do with helmets. When you drag a helmet out of the inventory and it goes as a preview on your head, well, a helmet has a room inside. But it's not a real room when it's just the UI preview. It's the hologram UI helmet. But the room inside the hologram was still trying to talk to the real room system and going horribly wrong because of that. So we had ghost rooms from helmets.
I think we had some interesting ones when we added refueling. That was another feature I worked on. Mostly about the docking, because up until then, docking was something that happened between the stations, which are static and have infinite mass for all purposes, and a ship that is also not trying to move away. But once refueling came in, people were trying to quantum travel with ships, were catapulting ships: you extend the arm, accelerate to cruise speed, and you release the fighter and it goes spinning, stuff like that. The code was supposed to handle that. It was supposed to break, it was supposed to punish the players. It didn't. So we were getting some pretty funny situations where ships would start clipping back and forth inside the Starfarer. Hopefully you guys are not seeing that so much these days, but it was pretty funny to debug.
One of my favorite classic bugs was way back in Arena Commander days. I think this predated the PU. Ships like Hornets would just explode randomly. Sometimes they would explode after two minutes of flight, sometimes after eight minutes of flight, and it was so hard to replicate. Some people could fly forever and be fine. Eventually what they determined was the old flight suit had a flashlight that hung on the belt. And because of the physicalized nature of the thing, when you were doing certain moves, hitting certain Gs, the flashlight was dinging the side of the ship for one point of damage, one point of damage, one point of damage, until eventually the ship exploded. And there was no predicting it. It was impossible to track because everybody flies differently and pulls different moves. So that was my awakening to, holy crap, these things can come from anywhere, even from a stupid flashlight.
I think we still have that one, but for mining ships: the mining consumables that you can put on the heads tended to detach without inheriting the speed. So if you were cruising through the Yela asteroid belt after mining a rock and suddenly one of your modifiers expires and tries to detach itself from the ship, you would suddenly have a collision at a thousand meters per second. I'm really sorry for all the mining players out there.
It's been pretty great. For me, I was working remote ever since I joined. I hadn't been to the Wilmslow office either. So it's great to get in and finally actually meet everyone. I joined during the pandemic, and I've been remote the whole time, so now I get to actually meet everyone and chat and see people who I've only seen in Teams.
TL;DRBoth say the new office makes quick in-person chats easier than messaging, which speeds up solving small issues and clarifying bug reports; Guillermo adds he dislikes meetings.
Y
YaroGameplay Programmer, EU PU team
Yeah, I feel like it's way easier to have those small chats when I have a bug or something and I wouldn't normally write a Teams message because it's just whatever thing. But if Guillermo is sitting right next to me, it's easier to just be like, okay, what do you think about that? And I feel like it speeds up stuff on some things.
Yeah, you get a lot of that kind of collaboration now. I'm going to say I don't like meetings. Maybe there's somebody in the audience who likes meetings; I'm sorry for them. But on the other hand, talking to people, just going to them, as long as they are not in the middle of something more important, works for solving a lot of the small issues we have: figuring it out, understanding exactly what they mean in one of their messages on Jira or on Teams. Things like that, I think being in person works better for me at least.