Star Citizen: Calling All Devs - Idris and Multicrew

So probably we should start explaining what it is before we explain where it is at the moment. So yeah, we mentioned two things there. There's the Gen 12 renderer, or Generation 12 renderer, and then there is the fact that we're going to primarily use the Vulkan API. So the Gen 12 is just the name we came up with for our renderer, which is going to be utilizing multiple CPU cores more than the previous renderer, which mainly only runs on two CPU cores. Obviously these days we tend to have eight or 16 cores or more. And there's a lot of focus on pre-computations, so the runtime is much faster. So that's the Gen 12 renderer. And under the hood, it's going to use the Vulkan graphics API. In fact, initially, it's going to use DirectX 11, which is what the current engine uses, and Vulkan. And then once we've got the Vulkan support to be better than the DirectX 11 support, we'll drop DirectX 11 and move fully over to Vulkan. And Vulkan is a more modern API. Lighter weight, much faster. It's much closer, a thinner layer of abstraction over what the GPU actually does. So that gives us a lot of performance boost, but it takes a lot more time to program for. So it's more initial investment, but then we get big performance wins once we get over the initial hurdle.

And where are we at? So it's complicated to answer, but we have multiple mini teams we've set up in the graphics and engine programmer departments, and they're tackling six separate areas. So I'll talk for each of the six and where we're up to. So the highest level one is the pipeline, render pipeline we're calling it, which is the way we structure a frame: first we render some shadows, and then we do some render to texture work, and then we'll get on to a depth pass, a color pass, then we'll do the UI and such. That pipeline is the framework that glues it all together. That bit is starting soon, but we haven't actually needed to do that bit first. You would have imagined we'd start there, but actually it's the opposite. We've started at the other end of the system.

So at the other end of the system, we have the Vulkan device. This is the lowest level part of it, which is where we actually issue our draw commands to the GPU using the Vulkan API. So that's actually the first thing we started on, the very lowest level, the most difficult part. And we've got a couple of guys just working on that one section alone. And then in another studio, we've got some people looking at the DirectX 11 equivalent, so what we're going to use in the meantime while we get this renderer up and running. And because we already have DirectX 11 support, that's pretty much done. There's not a lot to do there. There's not a lot of concerns. So that section is OK. And then above them both we have this common layer. So there are differences between DirectX and Vulkan, and by having this common layer above we can abstract that and hide that difference, so the higher level rendering code doesn't need to worry about whether it's DirectX or Vulkan. And again, that part of it is pretty much done, and that's not a particularly complicated bit.

And then the real work comes down to two remaining topics. So we have the post effects and we have what we call the scene submission, the scene rendering. So the post effects are our bloom, our lighting, all these things, the general effects, and some of the effects that people hate, motion blur and chromatic aberration and those ones as well. But the ones that people don't hate so much as well. That's a big chunk of work, and we have two guys just working on that. They're getting quite far through that. I couldn't give a percentage, but they've made very good progress. They've started with the hardest ones intentionally so that we prove the system, and then there's going to be a bit of grunt work to get through the more trivial ones afterwards. And then the final big topic is the scene submission, which is getting basically the geometry into the game, into the renderer. So our shadows and our color pass, and just getting all of this geometry very quickly and efficiently into the renderer. And that's probably one of the larger sections, and that's just about started.

So at the moment we've got good progress on the Vulkan device, the DirectX 11 device, the common layer that binds them together, and we've made good progress on the post effects. And then the main large areas that are still to be started or to make significant progress on are the scene submission and the overall render pipeline that glues it all together. So yeah, it's hard to say where that means we are.

If this is the timeline, from beginning to end, where are we?

Somewhere in my head it's in the middle. I don't know. It's hard to give a... Each of these six things are extremely big and complicated in themselves. We have lots of designs. There's endless discussions on each of these topics. So even when programming hasn't started, we can be many weeks into work before we've even got to that stage. That's progressing well, though. And there's a lot of resources dedicated to this internally.

Two reasons. The first reason is performance. We get the ability to use a more efficient API that can spread work over all of your CPU cores, which will result in a much, much faster rendering process on the CPU side and much lower latency as well. Latency is quite important to a lot of people these days. And the second side is, because it's a more modern API, it opens the door to many new features that we didn't previously have access to, which are things like ray tracing, VRS and async compute. And there's a lot of things we couldn't do locked to the previous API. So performance, then features afterwards.

So it seems like a big part in letting Star Citizen realize its full potential.

Yes. We don't really have a choice. This has to happen. This is the next logical step. We can't really achieve the performance or the visuals we want without taking this step first.

Want to put a date on it?

No, do you?

Nope. Just figured I'd ask.

It's our biggest focus this year. There's nothing else that we are putting anywhere near as much resources in, for the graphics team. Just the graphics and engine team.

So the exterior of the Idris is mostly there, which is why we're going to be putting it into the PU soon. A lot of the damage is set up for it, the exterior artwork, all the thrusters, et cetera, which is why that can happen. But the interior is still fairly work in progress, because in Squadron 42 it's very much a work in progress there still. Any reworks that go in, any changes to the PCap or anything, need to be updated within the Idris. The interior is still very much in flux. And in addition to all that as well, it's a big multi-crew ship. So as these features get implemented, we need to obviously refine what's present inside the ship. So currently as it stands, the ship interior isn't in a state where we can give it to the public, and it probably won't be for a while.

One person can technically fly it around like a fighter, but you will be getting barely any of the ship's functionality out of it. I mean, your pilot will be able to fly the ship, but you're supposed to have a navigator who will be navigating where you're going to go to and helping you avoid or go to hotspots. You'll have people manning the air traffic control seats, who, if you want to have any ships take off and fly away, or even new ones flying in, you'll need to have someone to manage all that. The pilot can't do all of this on their own. You'll have weapon seats to handle the railgun at the front. Even a captain who, if someone's being belligerent in the crew, might be able to turn around and demote someone on the fly and say, no, you can't do that anymore. So there's a lot of this functionality that is going to be going into the ship, or should be going into the ship, but it's just not there yet. We don't have it ready yet. So essentially what you would have if you were to release the Idris right now is a giant fighter, and I don't think most people would appreciate that.

It was really tricky. So initially, before the mission took too much shape, one of the first things that came my way was to actually try to balance the Idris around fighting different amounts of ships. So I'd start spawning Hammerhead after Hammerhead after Hammerhead and just having tons of Hammerheads fighting the ship. And then I'd try out maybe throwing in some Retaliators with their torpedoes. One of the first things we quickly discovered was, with the way the ships are currently set up, they've got a small health pool on multiple parts of the ship. And as you take damage, it'll spread up the ship and eventually go to the core location and then kill the ship. What happened with one size nine torpedo is the splash damage would hit so many locations that one would just kill the Idris straight away. So we were immediately like, right, we need to give this thing a bigger centralized health pool and then have the other areas have slightly less, just to balance it out. So there was a lot of iteration just on the health of the ship alone, let alone tweaking the shield generators, because there's things like capital size shield generators, like the 890 has, which make it huge and very difficult to damage in the first place. So there was a lot of base iteration, just making this thing resilient enough to actually require a bunch of people to kill, but not be completely unkillable in the first place.

Yeah, absolutely. Deeper multi-crew gameplay has been planned since the beginning. Some interest has been picking up on it recently. We've had some discussions with CR to refine how we're going to go about things. We've been looking into building this permission system for ships, where the captain can assign item control to specific people in the ship. So he can give the engineer the role to control the power plant and the coolers, and a weapons officer the ability to control weapons, that sort of thing. And the hope is that over time, as we add more and more depth of systems gameplay inside the ships, that, combined with the permission system, will be conducive to more and more deep multi-crew gameplay. Because right now I think all of the ship control pretty much gets funneled to the pilot, and that's the issue that we want to solve in the near term. And then we'll continue adding depth to make the multi-crew experience more interesting as we keep going.

Yeah, it starts with game systems. It's one of those things where we don't want to have this very artificial feeling of, oh, this is what you do if you're this role, and if you're a weapons officer, this is your screen and it's designed for weapons ops. We want it to feel a little bit more natural, where players can come up with these roles themselves. But what we need to do is consider how the gameplay systems in the ship interact with each other, and more importantly, how players interact with them, so that when they get combined together, the natural result will be roles like you see in a stereotypical multi-crew spaceship. And so that's pretty much what we're doing now: reviewing a lot of ship systems and trying to see what we can do to increase the depth and make it interesting for players to engage with those systems. And then obviously, longer term, is adding more features to ships. I think that's probably a discussion for another Calling All Devs.

We don't want minigames, we don't want quick time events. As I said, it needs to feel natural. It needs to feel like this is the obvious thing for that player to do. So take engineer, for example. The way an engineer might go about things is, if we increase the interaction inside ships, maybe we have life support inside the ship failing and you've run out of oxygen or something like that. The engineer might have to walk over to a panel that has an oxygen bottle in it, open the panel, go inside, get this oxygen bottle out, do some actions to repair it. I'm not exactly sure how they'll work. We haven't fleshed that out quite yet. And then they'll go back and put that back in and make sure it's working. And so that's the kind of thing where it's not minigames for a role, it's actions that interact with the ship's systems.

Physicalized.

Yes. Some of them are physicalized. That one is obviously physicalized. But for example, scanning for stuff is probably not physicalized. It's going to be something where you're at a scanning station with a globe that shows you nearby contacts on the radar, that sort of thing. It'll depend a little bit on what the feature is as to how it'll manifest in the ship. But obviously we want some kind of variety.

And the specific capabilities of that ship, because not every ship has a giant globe.

Yeah, obviously. So, for example, a ship that has a medbed might have more gameplay for a medical officer, whereas for ships that don't, that won't be applicable.

Yeah, so captain obviously is the biggest, most interesting one. The captain, first and foremost, has this ability to assign permissions to players, but we also view being a captain as kind of like playing a real-time strategy game, where you will be able to see what's going on in the nearby battlefield, say if you're in a battle, through the globe, and then the captain is pointing things out and giving orders to various people on the ship and trying to direct how things are progressing. So that's the captain, that's the first role and how we see what their actions are. Pilot, obviously, is pretty much already defined. Engineer is a big one. When we get to increasing the depth of the power systems inside large ships, the engineer will be naturally suited to that kind of role. There's also security officers, who can control door access and that sort of thing.

So I think those are probably core pillars. You've got engineer, captain, pilot, and then probably, I don't know what you would call the person who's looking after scanning and radar. Is that tactical officer? I'm not quite so sure.

Or science officer if it's not battle, for instance.

Exactly. I think those are the main roles. And then I think there might be specific roles for certain ships depending on their feature set. And players can also just define their own roles if they want. It's not up to us. If they want to give a certain player a specific set of items to control, they can make up that role however they want.