Star Citizen: Reverse the Verse LIVE - Alpha 3.0 Q&A

I was in Austin. I flew to Austin on the Wednesday, actually. Before that, I was in the Manchester office, and at the time, that last week is about trying to solidify the build so you have something which you feel you can go live with and also publish to a larger group of people. From my level, it's about making sure that we have builds which are stable, that basically we feel can be used as backup candidates for going live and so forth. Because specifically, if you go back a bit, 3.0 is such a huge amount of work. It's not just what people can see; there's a technology we had to build to make everything work. So there's a huge amount of work that was going on behind the scenes. So just getting the base of work before you even talk about some of the gameplay features, you've got to get this base of tech working to support the features and get the features working. And so all these things have to come together, and then you want to get it obviously to the community as fast as possible because you want to have all that feedback and that ability for people to get out there to see it.

Specifically the Christmas period is a great period for us, for two reasons. One is we love getting a version out then because we can get loads of feedback over the Christmas period. And then we've got that for the new year when we generally kick off: okay, it's a new year, this is what we're going to do this year. And secondly, it's great for us because it's the only time that CIG actually shuts down as a company. Every studio shuts down between Christmas and New Year's and everybody gets some time off, just after a hard year, to regain some focus. And it does mean a lot, because obviously people take holidays, but if you're on holiday and you've still got 200 emails coming in a day, sometimes it's kind of hard. So it's a good thing. So we really pushed hard to do that. And so it's all about managing the process so we know we'll have something we can go live with.

And it's a process that we've done before. We released 2.6 the last holiday season, and I believe 2.0 was the holiday season before that. So it's kind of an established rhythm for us at this point.

It is. And also it's a hard target. Because you basically want to get this done, you want to get it out there, and so it's a nice target for the team to go: let's get it out, enjoy your holiday, and the community gets to check out all the latest great stuff.

Well, certain things happen. Yes, you have a candidate, you feel pretty good about it. I think in the case of what actually happened, we had one issue, and so we had to rebuild for that one issue and did the testing to make sure it was fine. And that's why we pushed to PTU to everyone on the Friday and then actually went live on the Saturday, because we wanted to give it a full cycle of PTU with a lot of people in there to make sure it's good to go live. And then on the Saturday we felt good about going live. But during that period of time, while QA is signing off, obviously the LiveOps guys are making sure it's all ready to go, getting all the information together that we have to do. And of course there's a whole community side of making sure we deliver the letters out to everybody, letting them know this is all coming and so forth. So typically, while this build is going on, every now and then the build might break. And so you sit there in those last moments going, well, we're kind of out of time, hopefully this build will be fine and there won't be any issues. That's what's going through your mind.

Fortunately, just to talk about stuff we've done this year that made a massive difference to our development flow: the build system used to take us three, four hours to get one build done. And now, because of all the great work the guys have been doing, we can knock builds out in less than an hour. And that makes a huge difference. So rather than doing one or two builds a day and clogging up the whole system, now we can just churn out builds. And that makes a massive difference to the iteration and getting stuff done for everybody in the company, and also getting stuff out to the community.

I think that's something that's sometimes lost, that we're not just making a game, we're also making the way that we make the game.

Look, we're building a company, we still are, while building technology, while building a game. And so all the time we're refining our processes. We'll do something and go, that's too many steps to get where we want it to be. So we basically then go back and say, okay, we need to create a pipeline or a tool chain that makes it easier. For instance, to get a character in the game it has to go from this person to this person to this person, and you go, well, that's crazy. So how do we get this automated to knock out as many steps as possible, so why can't just one person do most of this and then maybe hand off? So all the time those discussions are going on, and this year we have a huge roadmap. We did loads last year, we've got even more this year, because the idea is we want to get much more efficient, so as we're bringing more content, it involves fewer people who can get more content out there.

Typically, if we're just chucking out another patch, the way the process works as we're going through the year is we'd basically have a meeting and say, okay, are we good to put another patch out for the PTU? And typically I'd be in the UK time zone and I'd say, okay, if this is all good and this is working fine and we feel this build that's going to be tested in Austin is good, because I'll be in the UK at this time, then you've got my go-ahead to ship. And then it'll be a production call in the LA time zone, which wouldn't really involve senior people, because it'd be like, hey, that sounds good. So when it came to the live one, I basically explicitly just said, okay, Chris is going to make that call.

I've been here for a number of these larger patches and this one definitely felt a little different. This one felt like the accumulation of a whole lot of work.

It was really one of those where we've been working on it for a long time. There's so much going on under the hood that it was really important that we got it out there, because now, having it out there and having information from that, we have a great roadmap of all the stuff we want to do going forward, not only in terms of features and content, but in terms of all the work we need to do on optimization and other stuff, because we have this feedback. Just going a bit off question here, but a lot of the stuff that happened when we went live over Christmas, we hadn't really seen before, even though we were with Evocati and on PTU. It's when people got in and started doing stuff in certain ways and playing that these issues came up. Now, fortunately for some of the worst ones, because we have our backend side, we can actually make changes on the server side.

Like the interdiction.

Exactly, all that kind of stuff, to fix those issues without having to do a new build. That's great for us, because doing a new build, as we've talked about, is a big process. It requires people to go in, you have to do a new build, you've got to test, you've got to look at this stuff. But on the backend side, we can just tweak parameters or turn things on and off. So that helps a lot.

Mostly we didn't get in as much of other features as we would have liked. Typically we felt like there were one or two more steps we could have taken. But you have to get to a period of time, and this ties into what we want to do next this year, where if we're serious about getting 3.0 out, then you've got to make certain calls. And so there's some stuff like that. The only feature I can think of, and there's probably one or two more, but just off the top of my head right now, is the character customizer. That's one we'd have liked to put in, we didn't make it, and obviously we're working hard on that now. And there were one or two other things. We made a big call at the end. There's been a lot of work going on in the damage system to make it a lot better. And it was ready, but it became ready literally two days before we were going to ship. And we just made a call: putting that in right now is going to be a bit silly. Let's put it in after Christmas and then have time with 3.1 to make sure that there's a whole new system so the ships damage and blow up better, all that kind of stuff.

Okay, so I have to go back to last year. Last year we had, as we talked about, a massive amount of technical work as well as feature work to get 3.0 out. And that was just something we had to do to get us where we are. A lot of that work was about getting the basics.

The foundation.

Yes. And yes, we wanted to get it out a lot earlier. And one thing that we want to do regularly, because it's important to us, just as much as I'm sure it's important to the community to have regular updates, is because we want that feedback. We want to get versions out there. That's how we get that iteration. And iterating is really important in game development, whether we're doing it with the community, which is awesome, or internally. Usually in a normal project there's a huge amount of iteration that you'll never see: you do something, internal test groups give you feedback, all that kind of stuff. So last year, doing all this work was a big deal. And so what we talked about is, as soon as we get 3.0 out, we want to change to a completely different model. And the model is going to be date-driven, not feature-driven.

So this means, yes, we have a number of features, bug fixes, polish, whatever you call it, we want to do for a certain timeline. We set it up, and that's what the team works towards. We give ourselves a period of actual development on feature work, and that development is going to run typically to about 50 to 60% of the available time. And once we get to that level, hopefully, and it won't happen every time, just so you guys know, but we're going to work very hard on it, the vast majority of the features we want to put in are worked in that time. Then the team moves to a completely separate model, which goes from feature development to close-down: bug fixing, polish, minor bugs and so forth. So we get to this point and we go, okay, which features are done? Great, all those are in 3.1. Any features which have not made it, we go, okay, you're now going to be in 3.2, you're going to be in the next patch. And we're going to take everything that's done now, we're going to polish it, we're going to optimize it, we're going to do everything we need to do to make it much better. And then we release in our date time.

And it should be very doable and predictable that way, because what kills you is when you turn around and say, I really want that feature in, and it hasn't quite made it, but another two weeks and it'll make it. Another two weeks? Well, we'll polish here, but we're going to keep this feature going and hopefully make it. The problem is, as you're developing that feature, you're creating more bugs, more issues. The people who are typically doing the feature work are the same guys you want fixing bugs. So it creates this perpetual cycle of things slipping. And so we're going to be very hardcore: did it make it? Did it not make it? No? Close down, move on. And so you're still going to see the same features, but it may be that sometimes they slip to three months later. But the beautiful thing about this is that as a development team, we get great progress building it, and we also keep stability, because we're on a cycle where we have to keep GameDev stable, because we have to use it to keep going out and publishing live to the community. And it means the community then gets regular updates. If you're in Evocati or the first waves of PTU, you're probably only going to go from a live release six to seven to eight weeks before you see the next build. So people are seeing new stuff come online, they're seeing the delivery of that, they're seeing results a lot quicker, rather than us going away for a year to do this massive feature set and people going, okay, well, I've got nothing to do for a year now. And it's not just really cool for you guys in the community, but internally for the dev team it's a massive morale boost when we're getting stuff out there and people are playing it and giving feedback, good and bad.

We're also putting a lot of time and effort into making our predictions better for what we're doing. One of the ways we're doing that is by not trying to do so much in one go. Don't get me wrong, we're not going to cut back, but we've been very sensible about making sure that resources in the company are focused on one thing and not split between lots of different things. So I think we're going to be a lot more predictable about what you'll see and what we'll advertise will be in the patches. But like I said, yes, one or two things may slip. One or two things may not be quite as good as we want and may move on to the next one. But the point is, it'll be an ever-improving cycle. And I think this new system will mean that the predictability and also the basic delivery of content to the community is going to speed up.

So with 3.1, we've got 3.0 out there, we've got the feedback, so 3.1 is all about a big drive to solidify all that stuff. There are one or two new features we're going to push for. But mostly it's about the biggest one, and we're focusing on it already: performance. Getting all of the 3.0 stuff, all the different base tech, and just getting the features working was a massive deal. And what we're doing now is we've got some of our more senior guys really taking the time out to go in and do these huge optimization passes. We know where we need to optimize. There's a lot of stuff where, when you're doing the feature creation side, we now need to focus people on the optimization. So that's a big one. So the plan for 3.1 is that it should be much faster than 3.0 is, and it should be a much better experience for the community. We have our goals for what that's going to be. Hopefully, at the top end of our goal, everyone will be happy. But the point is that the experience, when it comes out, will be a lot better, because there are a lot of things we do on the network side, on the rendering side, and also on the gameplay side in terms of the way we do multi-threading. There's a lot of code we know is basically redundant and needs to be changed and fixed or thrown away and rewritten. So that sort of work is going on. That's one of the big things.

We're also going to be polishing up a lot of the UI, because that's a big, important part, the readability, so you can use the HUDs a lot better. We have a bunch of work we'll be doing on combat and on space UI as well. We're going to have a bunch of work on the economy, because right now there are a lot of exploits, so we're going to do work on making that better. And we want to obviously balance interdiction better. And then one of the features we really want to get in, and hopefully we get this in, is this: now we have interdiction, so let's say you're on a planet, or you get interdicted, or you're in space and someone attacks you. It's called the service beacon. We just want to get the first level of it, which is basically the ability for a player to communicate to anyone else who's near them or in the system and can get to them: this is where I am. And if they're under attack: help me, I'm under attack. And they can send basically a nav point for people to go to to help them. So that could be whether you crash on a planet and you've got no way off and you can say, hey, I'm here on the planet, someone come pick me up and save me, or I'm being attacked by pirates, please come and help me. And this will be the first element of it. Now, this whole system will build into, I'm sure Tony's talked about it, the ability for players to make missions for each other, because then you'll go, hey, I'm here, I'll pay you 500 UEC to pick me up, or whatever it is. Don't quote me on prices, I'm just throwing them out there. But that's the idea.

Okay, so yes, we'll be improving it. We've made adjustments to how thrusters work and so forth. A while back, we purposely slowed combat down to combat speeds because we wanted a more visual experience. When you're in combat against AI, we don't want you just fighting with pixels, because it's not fun, and we want the AI to act intelligent. So we'll be putting a lot of work into that. Yes, we want the ability for a player, if they're just cruising down to a planet and it's boring because they've got 1,000 kilometers to go, to use afterburners on the straight line so they can get down there faster. But I think when you're not in a straight line, we're going to have to make some adjustments. And also the way the AI actually flies and what they do, to make that experience against the AI more interesting. Which means there'll be work on the physics system. Obviously there'll be more work on combat over planets as well, because we're going to be improving the atmospheric flight. But yes, making the flight AI better, those are the games I've worked on, and that's something I take a great personal interest in, making sure that experience is better. So there will be improvements for 3.1, absolutely, but this is a process which is going to keep on going. We plan on making it better and better. So think of this as a first step, and then the next version comes out and it'll be better again. The team isn't going to stop working on it. So you'll see this as an improvement through the year, where things just get better and better, because the team is still there. We have our flight AI team and they'll just keep on going, and we have our physics guys and they'll be doing the same thing all the way through.

And the great thing is, as we go out, we see how people are playing. I'm sure we've mentioned this before to the community, but our developers spend a lot of time looking at the videos that are made by the community. It's a very collaborative experience. You might throw some questions in about this stuff, but actually the stuff you're playing and showing when you're flying, that's the stuff our designers and our programmers will download and look at, and they'll go, okay, that's not how it's meant to work. This stuff is really good info for us, not just if it's entered as a bug in the system. Literally we go to YouTube and just watch what's going on. And that's brilliant. We have that with the community; other businesses do not have that at all. We can make this game in that sort of way and with that support, and it does make a massive difference.

And of course, ship combat is not just a system that helps Star Citizen. It's obviously a system that's going to be very important for Squadron 42.

Absolutely. But likewise, I don't want to throw too many promises out, but we're not that far off from getting FPS AI into the PU as well, to really make missions more interesting. I'm not promising this for 3.1, but when we have that, when you can go onto a planet and do stuff, then all of a sudden there's a bit of danger: you go down to do a mission and someone might attack you. And likewise, while we're making these changes here, the Squadron guys are also very much focusing on the FPS side. As soon as that's in a state that we believe is good enough for a tier zero implementation in the PU, we'll put that in, using a lot of the work that's come from the FPS team as well.

It's good. It's a good feeling. It's a lot of work. It's a shared code base, so Squadron and Star Citizen are basically the same game. Obviously we're doing more of a single-player version of it. And so basically we're able to get a lot of the stuff. But the thing with Squadron, it's all about the storytelling and that very in-depth feel. So a lot of time had to go into getting the characters, the shaders, the stuff, to really give it a beautiful cinematic feel, and then actually now start to show off these big structures. Like the Shubin station you see, I think it's like 12 kilometers long. You can see how big the Idris is compared to it. That's the level of things.

It's great getting it together and seeing it all together. Not just externally, but internally for the team, it's great to actually be able to show it after all this time. And also, once again, it's a great case of, okay, a lot of the work is making the tools work the way they need to. When you're putting together cinematics, there's a huge amount of work behind the scenes of, okay, we can get this working, but that took way too long; we've got to get this down to taking half a day, not a week. And so all these conversations are happening in all the areas. But the beauty is with Squadron, when we have all that tech as well, we can start thinking about putting some of these story elements into the PU at some point as well.

The Delta Patcher, anyway: if you're just waiting for a live patch, then quite a bit will change between builds. But if you're Evocati or people going to the PTU, when you're downloading a new patch every day, it makes a massive difference. So I guess if you're only downloading it four times a year, it's probably not such a big deal, but the change was a massive deal for a lot of people doing that kind of stuff. But just because we're doing four large patches, which is the plan, it doesn't mean we won't do a smaller patch if we need to for a reason. We plan to get the patches in a good state, but it may be that we want a patch because we want to introduce some new ships or whatever it is. So what we're saying is, we're planning a quarterly patch. These will be nice, big changes. But that doesn't mean we're not going to say, well, actually, we might have to do a hotfix. Or, you know what, we've got some cool new content we can put in where the gameplay systems themselves won't change; it's just adding some content, because adding a ship, we keep it in the same branch.

And this is one of the discussions, the reason why it was important to get 3.0 out last year, because we'd been in the 3.0 branch for a long time. But our main development branch is actually GameDev. And so the longer you're out in 3.0 trying to get stuff working, you can't go back to GameDev. All the new optimization work, all the new tools, all the new content is sitting in GameDev. And so if you just stay on 3.0 all the time, then you can't get out. So we needed to get 3.0 out and get the feedback from that so we could go back to GameDev and take all the information from there. And then once we go back to GameDev, the next step is we take all these changes and fixes and branch for 3.1, which we'll do sometime in February. We've taken all the goodness and put it back in there. And then we polish and bug fix to get 3.1 out while the work on the other stuff continues in GameDev.

We basically plan to, we're still working on the star map and how that system works, and that's also one of the things where it's great to get the feedback on what we're doing. The thing about blind jumps is obviously fuel, so I guess you could do a blind jump, but you'd have to then decide to bring yourself out at a random location or just run out of fuel. But for me personally, I think that would be perfectly fine to do. Technically, it's not a huge challenge. It's more about whether you want to let players do that kind of stuff. And I can see, as a player, you might just want to do a blind jump because you want to get away from someone, Battlestar Galactica style: you just jump away and hope the Cylons don't find you.

Also for folks to potentially discover new jump points and stuff like that, you'll have to be able to.

You can go and explore and so forth. And also, like I said, we want to bring the ability for players to create nav markers for other players as well, so they can say, okay, hey, come here, this is where I am, this location, which is important.

Oh dear. No. When I joined, it was 2013. Chris convinced me to come on board. We were going to have some plans, and obviously things have definitely grown way beyond my expectations. In terms of getting Star Citizen to where it is now, a lot of the stuff would have been different. That's one of the things I'm sure Chris has talked about before: a seamless transition to planets and being able to wander around planets was never part of the original plan. But because of the advantages of having such great support and working with such talented people, now all of a sudden we have these amazing procedural planets, so you can actually go down and land. Whereas in the old days, the original thought process would have been more Wing Commander-esque. But now, no, you get to go there and walk around and go to different rooms and all that kind of stuff. So we're definitely building this level of immersion, which I hope is what people want. We have so much support because we want to build almost a second life: you have your ability to just go in and lose yourself in this universe and do these incredible things that you can't do in real life. It's that immersive quality. That's what we try to do, build that realism into it. If you look at everything we do, we want it to look right and feel right, and get the tech to make that happen. And I wouldn't have been interested in joining if we were just trying to do an also-ran game. We're here trying to make something, and now we're getting a lot of stuff in place and you can really start seeing it. It's something that no one else has done before and no one has been given the opportunity to do before. It's to create something that's amazing.