Star Citizen: Around the Verse - Pillar Talk

So Alpha 3.3 is going live tomorrow, which is really cool. And 3.3.5 with Hurston and Lorville, part of it, is coming to the PTU in short order as soon as we go live on 3.3. We had to get 3.3 out live to people before we could move the next release into the PTU phase. So that's a really important step and people will be able to play a nice stable 3.3, but also explore Hurston, even if they're willing to put up with a few crashes in the PTU. And that all gets us closer to the next thing on that list.

I mean, it's a little later than we want it to be, but it's a lot of content. And the most important thing is the object container streaming technology is now stable enough for us to go live. And that's a big, big thing because we've been working on that for well over a year. And it's the tech pillar that's going to allow us to scale the rest of the world on the client side. And then on the technology side, we're really happy because that's passing a pretty big goalpost that we need to get past. It's taken us obviously longer than we thought and it's been a bit more complicated and difficult than we thought. But that is the case with that sort of R&D that you have to do and there's so many issues that go into it that we've already discussed. But yeah, it's good to be done. Good to get that working.

Well, the bad news is some things are going to move out of 3.4 into 3.5. I think people understand or are aware of the fact that 3.3's been running late, so it's been putting a lot of pressure on 3.4, and the biggest knock-on, and this is probably not what's particularly apparent to people, is the fact that each one of our releases, when we make a 3.3 or a 3.2, comes from Game Dev, which is our main development stream. And so it tends to be both a combination of slightly unstable and also full of a whole bunch of content that you're not ready, or you don't want to put in the current release. Instead of excluding things, because we've got so many things, we include things and say, OK, we want these things in this release. And so it takes a lot of time, anywhere from, I think we've never done it shorter than two weeks, but it's more usually like four weeks, because we have hundreds and hundreds of thousands of files. Game Dev itself is almost two terabytes of just the data set of Game Dev itself. And that's not just the archive stuff, that is the actual working set. So most people actually only have a small portion of it, depending on what area they're working on. So we have to make sure that the right ones are going across, and there's only the stuff that you need for 3.3, which then also takes time to stabilize. So if we go back, after we get 3.3, back to Game Dev, and then try to stabilize it and then also test it and get it out, everybody on the development side, and this was something that came up just this week, essentially have said it's going to put us at risk of releasing 3.4 by the end of this year. So we still want to be date driven when we can, when we're not waiting for some tech pillar. And so we made the hard decision to basically stay in the 3.3 branch, which will become 3.4 once 3.3 and 3.3.5 is out, and then move the bits of content and functionality across that we can easily from Game Dev. That means that we can't move everything that we were planning to have for 3.4, and some stuff is a bit of a bridge too far, so we're going to lose some.

Well, I was just saying that some of the things we can move from Game Dev and some of the things we can't. Now, we're going to have the Hurston Business District in 3.4. So we're making sure that's going to be in and polished. We're going to do a lot more work and improvements on the FOIP and the VOIP stuff. The other ships that we had scheduled for coming in for 3.4 will be in 3.4 as well, because it's much easier to bring a ship or a weapon or an item or a gun across. But you'll know in the roadmap that's going to be updated tomorrow what has moved and what hasn't moved. So the biggest one is the female player character, because that touches a massive amount of stuff.

The other one is ArcCorp. ArcCorp has a whole bunch of procedural planet improvements that have happened in Game Dev. We have some shader work we've done for the new city stuff that's sitting in Game Dev, so we can't get that across, which kind of stops it, and LODs for the cities and stuff, so we can't bring that across. And also it's just ArcCorp's big and we want to take the time to do it right. And that's okay, because ArcCorp itself, we've been compressed by how long 3.3's taken, so it'd be nice to really make sure that's... But those are the two big headline ones. On a ship basis, we're in pretty good shape on all the ships, except the 300 series has run up right against the end of the year. And that's not including things like the LODs and the setups for the damage states and stuff like that and the variants. So he made the decision to move that out to 3.5 to give him time to finish all that up properly. But those are the big headline ones that have moved out.

It's not just the fact that thousands of animations have to be done. We have the same issues that you do in the real world, where in your car seat you can adjust your seat if you've got different length arms and different legs, and the female skeleton is 5'8" and the male skeleton is 6'. So we have to have solutions for the female getting into cockpits and not having the hands hyperextended or the legs hyperextended. So there's some tech that comes in there. There's some stuff that happens in the character customizer. Clothes are another issue. So there's a huge amount. It touches a massive amount of departments and there's a lot of work. And people have been working on it for quite a while. So it's not something that we just started. It just is in Game Dev and not in a position to bring it into the 3.3 stream.

We do our Monday morning leadership meetings, and in the most recent meeting, basically production came back, crunched the numbers and said, look, if we go from Game Dev into 3.4, based on if we come into the worst case scenario and it takes us four weeks to stabilize that, we're going to have no time to get testing and PTU and Evocati and be out for December 20th. So basically everyone came back on the development side and said, look, if we do this, we'll be in grave risk of missing a 3.4 release at the end of the year on December 20th.

So it's either no 3.4 for me or 3.4 light.

Yes. But we're a big company and there's a lot of things going on. And we have better tools now to look at how long it takes us and estimate trajectories and make decisions in soon enough time to not have everything, for instance, miss getting out 3.4 at the end of the year.

Well, I don't know if there's a silver lining other than, I mean, we're working on all these things, right? So we try to share everything as it happens live. So really the proper answer on why is it so late is because you're basically learning about it within a week of us deciding that and coming to that realization. It's not something we've been sitting on for months. We were hoping and projecting to get 3.3 stable and out weeks ago, and we haven't. It's taking a lot of time. But it's worth it, because 3.3, and this is one of the reasons why we deviated slightly from the date-driven model, because object container streaming is foundational tech. It's a major pillar for us to be able to have worlds with the detail and fidelity we want on a universal scale. And we have to get that working, or else you just won't be able to load all this extra content in, whether it's ArcCorp or microTech or another star system. You also won't be able to have it perform well if everything has to be loaded into memory. So people have definitely been seeing an improvement in performance because of object container streaming and bind culling, which are two critical parts to make it work. Once we have it done, and we're almost there, we're just about ready to, we're at the goalpost.

Well, our goal with Game Dev is that we're going to quarantine it and we're going to have some downstream development streams that people do their feature development in. And so what will happen if that's the case is they'll develop a feature in their feature stream, and then once it's done it will get reviewed, and then once we say okay, this looks good, it will go through what's called a QATR, which is a QA test request, and it'll get fully tested, and then we decide, okay, is it stable? Does it work well? Does it hurt performance? But if it is stable and doesn't hurt performance and it all works well, then it gets put into Game Dev. So we're only going to put things into Game Dev that are working and have been tested and have been polished, which will mean that Game Dev itself will be a lot more stable, and therefore it will have several benefits. People like artists, who are always at the mercy of someone putting something unstable in Game Dev and crashing the editor. They get the editor tool and they want to build an environment, it crashes because someone's got some other feature that's broken now. To be able to test these streams and have all these multiple, whether it's a release stream and a game development stream and a feature stream, and there's multiple feature streams, the build system has to be able to handle all those streams and deal with it, and what we call CopyBuild, our internal tool that you download whatever build you want with, has to be able to take that. So anyway, it's a lot of work. Everyone's been working on the DevOps side and the tool side on this for over a year. And that's our goal. And we're planning to have this rolling out in the beginning of next year.