Star Citizen: Pillar Talk - Staggered Dev

Working on the project, we've adjusted a few times on the development side in terms of working out what works, what doesn't work. We noticed in the last two deliveries we missed it by a couple of weeks each time because basically some features were coming in late, and so we couldn't get the proper QA time to go in.

There's no point having a thousand features in the game if half of them don't work how you'd expect them to. You're not going to have a fun time playing in that game.

So the idea is rather than trying to get it done and squeeze it all into three or four weeks, we actually give ourselves plenty of time, so when we're delivering these features we have more time to develop and make sure they're right, we have more time to really polish them, we have more time to really make sure that they're fun, they work.

Essentially the same process, just over a larger time frame, which just makes each of those individual gates a much more achievable set of goals.

You want to keep a quarterly delivery, but why do we need to force all the teams all the time to be trying to hit this quarterly delivery?

It compromises, especially on the dev side, when in your mind you've got the first week of a quarter, you're doing your planning, you know what you're going to do, you execute on it, then you prepare it for the patch and you go out to Evocati, PTU, and you're doing your feedback, and then you're expecting a date for it to be gone and you start again. When it goes past that, the other date doesn't tend to move, so you then have to pinch that time back somewhere. Do you take it out of planning? Taking out planning is usually a bad thing, because then it makes executing it worse.

The content teams already run to a different cadence. They're not delivering every quarter. If you're working on, on John's side, ships...

Yeah, they're out when we're happy with them. We always used to go towards: here's the quarter releases, we'll do things for the year, split up the ships between them, go in. But then it was a case of, well, this ship needs more time because we're not happy with X, Y, Z on it. Rather than just release a ship at a date, we'll release it when it's ready, like the Defender, the 890.

Same with a lot of the environment work. If you're doing a big landing location or planet, that's not something you usually can fit into a nice tight three-month quarterly period; it goes longer. But on the feature side, generally, yes, we had some features which went a bit longer. Mining was one of them. The original set of mining went through, and that took a couple of quarters in the background. But since that period, we've really been trying to just fit everything into a quarterly release. And the reason you do that is because, as a team, we're all trying to show as much new stuff and new features and work as we can to the community, and we're trying to just put all that in.

Aside from obviously giving us more time, by doing it as a six-month or longer block, you strip out those multiple planning and, not testing, but preparing for releases. If you're doing the feature in a quarter, you lose time for planning for that quarter and for testing that quarter. You string them together, you can strip that middle bit out and spend that on development instead. And it helps move away from developing features as a checklist of features, like 'we want to do X and Y in the game'. If you do it in this very specific order, knowing these caveats, you can do it, but that doesn't make it a fun and exciting experience. And we've got a huge amount of features in the game that, if we tweak and polish those, will just work together so much more nicely, and then the whole overall experience becomes a lot better.

When we put new features in now, we don't have the time and things break and it's frustrating; we want to get away from that. Now when we deliver, my huge drive is to make sure that from now on, every time we deliver, it is better than the last quarter you had. We felt like the last quarter or two, because we pushed some stuff in, it wasn't quite as good as we'd like.

And some of this comes from the community, some of it comes even from the developers internally. A lot of times we do a lot of postmortems, we do a lot of feedback gathering, and we ourselves know these things, but how can we make the experience good for the developers, for the community, but then also get the game to where we feel like it should be?

Like I talked about earlier, you're moving away from just ticking off a feature and saying technically it's done, that feature works, but you have to work around it by doing this, this and that. It allows people to have more pride and just a great feeling about doing this thing: this is a feature that I've worked on for six months and it works great, so now I'm happy for people to play it. Rather than: I was told I had to do this feature, and this is what was provided in the time, and I know it's not... this is all I could do at the time, we wanted it out.

And a lot of that is about getting stuff in. There'll be a lot of different cool stuff: getting the economy working properly, getting a bunch of missions working properly, getting the AI working properly, getting lots of locations on the planets with all the different feature sets we have for creating. We've got this wonderful planetary tech, which allows us to basically just create everything on the fly, and the locations on the fly. Get all that stuff working. If we get that stuff working, then we have an amazing gameplay experience, and then we can provide features and content and gameplay for years to come to really make this incredible universe we're doing.

John works on everything as well, but it really should help at the end of the day. This whole situation means that there's less downtime for people who are doing the Squadron work and have to support stuff in the PU. We have the longer development cycles, because all the Squadron features are in the PU. It's a shared codebase. So this whole thing should really help everybody in what they're doing.

The people that are working on missions for Squadron are having to work with the same stuff that goes out every quarter. Obviously they get it as it comes in, but if people are struggling to do a certain feature in the PU, spending longer to fix it means that the Squadron team gets that fix in a better state sooner, so it helps them.

In terms of our long-term roadmap, yes, I think you will see some changes to that. We're going to basically break down exactly where we're going with all the features and so forth to get them to where they need to be. And we'll be sitting here in a year's time and we'll talk about some other improvements we want to do and so forth. You can't stand still. You have to learn from your experiences and look at what worked. If you just blindly do the same thing over and over again, then nothing's going to improve. In CitizenCon last year, our plan is, when we have persistence, when we have some of these core features in, like the orgs working properly, which is part of this drive as well, when we have server meshing going, at that point we feel like we have a game. And that's what we want to get to. So while all this is going in, we're cleaning everything up, we're polishing, we're making all these features work great, we're adding all the sub-features in there and so forth. And at that point, we have a game that people can just play and really love. And then after that, every quarter, we give them more. We give them more. We give them more. We're then going to basically just keep on building on this for years to come.