Erin Roberts

I actually think it's great. I think it's great putting it out there and everyone can see it. I think the process of us sharing exactly what we would like to do on the development side compared to actually what gets achieved is one of those things. But I kind of like the fact that people see that, because what's happening is basically what happens in every company, just behind closed doors. And so you set up a very aggressive schedule. You basically work very hard to hit it. Things come along that change stuff in the way and process, you evaluate, you change stuff around because basically you want to go a different direction. And then that, of course, reassesses the roadmap. So in terms of that kind of stuff, the roadmap's changed because you might say, well, actually, we want to go do this. We're going to make this feature. And then, as we did at the beginning of last year, we looked at this and we sort of said, okay, actually we want to do these features, but I actually want to put focus back in on making the game a bit more fun now, because we're trying to get through a bunch of features to deliver to the community, but we knew we needed to, obviously, improve the frame rate. We knew we needed to go and make features we created, and maybe go back and spend some more time on them to make them enjoyable and fun, to get the better user experience. And so that's some of the stuff we then changed around, and we made a change to do that, which meant that we pushed out some feature work to basically make the experience better. And I actually do feel it was completely the right decision, because if you look at the play experience now compared to a year ago, it's fundamentally different. And because of that, that's absolutely the trajectory that we're continuing on: we are still focusing on improving the frame rate, on improving and focusing on the gameplay of the features we put in when we didn't finish, stability, all that kind of stuff, to really make sure what we have and what's working now, and there's so much stuff you can do already, that that is a great experience, while at the same time plugging in the features as they come along to basically fit within that.

We do plan very aggressively, and a lot of times some features... The biggest part of that is it comes down to: when we make a plan at the beginning of the year, we also include when we believe we're going to get new headcount on and when we can build teams to make that plan work. And so we basically create this roadmap and say, okay, well, right now we have these resources. And then, of course, you have to take into account... you think, well, I think we can manage this. But then, of course, we're trying to deliver, and then it takes some people off to fix bugs and so forth, and so you don't actually get some work. But on top of that, if we don't hire the people we need to create the features we thought we could later on, then obviously that feature's not going to be worked on. And so that's when I say aggressive: yes, we try and be sensible about, okay, how long will this feature take, and does it feel like there's some period of time. But if resources get reassigned because of something that becomes more important, or we just don't hire the resources we thought we were going to, then those features will get pushed back or drop out. And then sometimes, as I said, we'll just look at where we are. And I think that's one thing I'm actually really proud of in Cloud Imperium: we actually don't just march relentlessly in one direction. We go back, we look at the feedback we get from the community. We look at what's fun, what's working. The whole team really spends a lot of time checking out all the cool videos, looking at what people are really enjoying doing. And then we reassess, and we sit down, and we like to be really agile about this and say, okay, no, actually we're going to change direction here, because doing this and this and this is going to get us to a situation where people are really enjoying the game a lot quicker than if we just carried on. What you would sometimes do in a traditional thing is you try and get a bunch of features in and then you try and pull it all together. Then you'd really spend some time trying to polish it and just fix stuff and so forth.

I think that ability to reevaluate our progress every quarter, every half year, every year is one of the hallmarks of Star Citizen's development. Famously, when the PU development first started, we were pursuing the Terra system, for instance. And then we realized that the Stanton system would actually give us the vertical slice for everything we need in Star Citizen. So when we had that realization, a lot of people might have been too timid to switch gears at that point, but not us. We switched gears, and the results have yielded themselves.

We make the right decisions for this kind of stuff. Is it painful sometimes? Because no one likes letting people down. But then I do feel like, because of what we're doing, we actually are going to get to where everybody wants to be much faster, because we're at our end goal of having this incredible experience in this huge persistent universe, as well as actually really helping Squadron really become an amazing game.

So as I mentioned on the resource side, the one thing we're, as a company, really focusing on is making sure we push Squadron and get Squadron out as soon as possible. You see the roadmap, working very hard towards that. It does mean, however, that resources that we would have used on the PU now plug areas in Squadron where either there's a shortage of resources, or let's say one or two people leave; then basically we use resources from the PU on Squadron to make sure that we are going full speed ahead with that. In terms of what it means to Star Citizen, one thing we wanted to do is, we obviously have this focus on making it fun and we want to keep on doing that, so we're keeping up the polish on the user experience and that kind of stuff. But it means that a few of the features that we may have planned to do on the PU get pushed back slightly, some slightly, some a little bit more, while we then focus our PU resources on making sure that it's a fun experience, it's fast, and so forth. And then we look at what Squadron's working on, and as the features come online with Squadron, we then take those features and move them into the PU. So then we sort of get led slightly by cool features in Squadron. They come on, we use them in the PU where we can. And then the other side of it is, we do have a lot of people still working on the PU, but a lot of those people are working on stuff like making sure persistence is really getting there, because that's the big thing: we want to get to the stage where people load into the game and they start and then that's it. And then they're playing their characters and there's no resetting. So persistence, getting the economy working properly, really getting this proper economic system working there, so when you go to places, it's on supply and demand. That's work that's going on right now. And also, with that, the side of the degradation, all that kind of stuff that goes with it, as well as obviously the big one for us, which is when I feel the game's going to be ready for prime time, which is when we get the server meshing in, when we can put a bunch of people in one system.

It's one of those things, I think, that gets lost sometimes. Even with 500-plus employees spread around five studios around the world, and you mentioned hiring and still upscaling those teams, there's still a finite amount of resources. You can only work on so many things at any given time. And there's this constant juggle between priorities, working on this, and this thing is a prerequisite for this thing, all these dependencies. It's quite a juggling act.

It's huge. And also, the quality level that we require to work on this game, and that we expect: we won't hire people unless that level is very high. And so finding those special people around the world to come and work at a studio takes a lot of time to bring them in, get them in, and then get them used to the engine and then also get them working productively as well. So sometimes you set, like, oh, I think we can find a couple of these people a month and so forth. Sometimes you don't. Sometimes a busload comes through in one load. Not very often, unfortunately. But the point is, this sort of happens. And so in terms of what we're doing, we've got lots of work to do. We've got a large amount of open headcount to try and fill to get this stuff. And so every day we're making decisions, calling priorities and how we're going to use that.

I answer this question a lot. Basically, the scale of what we were trying to do at the beginning, what Chris was trying to do, is very different. And the main driver of that was actually the amount of backing support we got from the community, and the amount of people who really wanted to have not only the Squadron single-player experience they had with Wing Commander, but also the big universe they could live in. As it became very evident quickly that there was a massive amount of support in that, and also a huge amount of money came in to support that, it just became very obvious that we weren't going to be building the game that I think Chris thought of originally, where he was going to do something which would be much more like the old-school stuff. Obviously nice story and so forth, but not the full first-person dynamic universe. We didn't even talk about the planets and the procedural techniques, all that kind of stuff. Now it's in the game and people are loving it. And it's a matter of trust. Because we believe that every single penny that comes in is going to be spent on development, and that's what we want to do. We'll build this incredible experience. And it just became obvious that we need to build something to support something that's going to be groundbreaking and change games in a way, not only how we funded it, but how we built it and everything like that. So it just came to a realization that we had to basically go and make something better. What comes with that is you can't just suddenly go, oh, okay, well, we'll build a few more ships, we'll do this over here. You actually structurally have to change the way that all the tools and tech work. And that was what happened very early on: we said, right, well, if we're going to support doing this, we're going to make this incredible first-person universe in which you can do all these different things, you need to then go in and really spend a bunch of time doing all the work, which the community sat through with us. People know we went through and changed the physics system. We got the local physics grids working, which is a big, huge deal. We changed to 64-bit. You probably forget, but there's been so many huge things. And then, of course, the object container streaming came in last year as well. And you've got all this work that goes on behind the scenes that you need to do, because you can't just do something and say, okay, it's kind of ready. And then when you want to get more dynamic and make it better, it just won't work. It won't scale. The only way you can make it scale is by having the underlying technology and the tools to support that. And so we basically said, all right, screw it. We're going to go and invest in the tools, in the tech. We're going to do this work. And the beautiful thing for me now: it's paying off. And as you said, it's been a few years; people have stuck with us. But the beautiful thing is, because of all that work, now we actually move pretty quickly, and I think people can see it now with the quarterly releases: we're getting more content out, we're going to get the feature stuff, and you can see how the game moves along. And it's not just a normal experience. It isn't like a cool old-school space combat simulator. It's something which is completely immersive. It's a huge world. You can see how it's all going to come together.

I think it was very easy to see somewhere around mid-2016, quarter three 2016, we definitely hit content phase. We weren't done building tools by any means. We're still building tools to help us make the game. But we got to a point where we could really start cranking out an actual tangible game that people play, and the experience that you see on YouTube, on Twitch, at Mixer, is vastly different today than you saw.

Yeah, and it goes for Squadron as well. It's the same thing. When you make those choices, the same technologies are in Squadron as in the Persistent Universe, and so I'm sure there's the same discussions about, well, Squadron has been delayed as well. It's the same deal: you've got to get the technology, you've got to get the tools and stuff to make that work. So even though early on we actually had a bunch of the missions working, once we went and changed up a lot of the tools and tech, we actually went and revisited those things and remade them.

No, it's going really well. We've got their roadmap. We're focusing the resources on it. There's always going to be the odd issue and stuff we go through. But basically, as a group, we meet two times a week. We look at the progress. And then it's just about really working through all the issues: obviously there's artwork coming in, and getting that artwork through, working through the AI issues we have and so forth to make it look better. And the great thing is, like we talked about before, as we're following what Squadron does, as the AI gets better with Squadron, people then start seeing that in the PU as well, in different missions and so forth, because that's one of the main features we take across. I'm not trying to change the subject here, but in the PU, when we have green zones, I want it to be a green zone because there's a bunch of security there who'll shoot you if you do wrong things, not just that you can't use your weapon and so forth. And that's the sort of thing that'll start coming in over the next few quarters.

Those diegetic solutions, not a fancy zone that you can't play in.

Exactly, not just that you can't have your gun and so forth. It's got to be: if you do a criminal act, okay, these guys will come after you. And that's part of the law system that's going to start coming in as well over the next few quarters.

We went back in and redesigned them, simply. We had better tech. We had other things we wanted to do. The procedural planet system came online. There's so many different things and so forth. And we didn't feel like the levels were where we wanted them to be. And so we went back through so much of the stuff. Some of them were changed, some of them were moved around and so forth. But it was basically just a decision, because Squadron is not coming out until it's literally the perfect game. This for me is... I'm getting long in the tooth here, and this is probably the last thing I will work on. And I know people like Chris and other people feel the same: when we do this, it's going to be absolutely amazing. And so if it's not right, then we're going to make sure it's right.

One of the things that I really enjoy in educating our backer community is that game development is not a linear line. It's not A to B to C to D to E all the way to Z and you're done. There are review gates. There are points where you go back. Most famously, I think one of the Metroid games just recently announced that they're going all the way back to the beginning, starting over. We're not doing that by any means, but it's a good analogy to the type of review and step back and reevaluation that happens in all game development. And so when Squadron was in greybox in 2015, that was the expectation.

It was a different game. That's what I'm saying. We went back. We looked at tech with the support we had and so forth. And we knew we were pushing it. And so we really looked at what we wanted to do. We changed up a lot in terms of just the tools and the shaders and stuff, the way we do the art. There's a lot of different things we could do, so we wanted to change that up in terms of the characters, the way we do them, the way they live and all that kind of stuff. How we want to make certain events play out. All those things have a big effect on stuff. We're not here to make something average. If it's not amazing, then it's not coming out of the studio.

Well, obviously we're going to have new locations coming through. We have some this quarter. I think also we're going to spend a lot of time on creating more detail on the planets we already have. We have cool stuff like tunnel systems coming along. We're going to have more locations in space, places to visit, sort of way stations and so forth. And also in terms of the gameplay side and feature side, we've obviously got a new flight model coming very soon, which is really exciting. It's going to be really cool. It's not only cool because it's just better in terms of flight in the atmosphere and flight in space and so forth, but another cool thing is it's a lot faster. It's very quick, which means that actually it's a big performance win as well. So people should see that when they start looking at stuff, because when you've got a bunch of ships and they're all using a system and that system's expensive, it all multiplies up. And this system's a much quicker and much simpler system. And the great thing about it is it's simpler to use for design as well, to get the work and the changes they want to do out of it. We have the female characters coming. We have the ability for characters to actually create their look in the game. And then once again, we'll be taking a bunch of features through from Squadron, so the improved AI will be coming through. There's a lot. With this release of the roadmap, I have very much made sure and asked the team that what we put in there is what we can achieve with what we have right now, specifically also with the fact that people may be pulled onto Squadron, and we know that there's basically this work. So although there's a really good set of stuff in there, my hope is we'll be able to add some stuff to the roadmap. But what I've done this time, rather than last time: last time we said we think we can do this, and we had it in the roadmap. This time we put in what we are pretty damn sure we can do. Okay, so now I'm signing up for this. And then, hopefully, if we do build a team and get more people, then we'll actually be able to add stuff to the roadmap. So with a bit of luck, towards the end of the year we'll be able to actually start adding stuff to the roadmap rather than taking it out.

We try and learn, believe it or not. We got aggressive, we did the stuff, and we said, well, this time, let's just put in the roadmap what people feel is completely doable with what we have right now, rather than sort of saying, okay, yeah, but we should have another team built by this time, so we'll be able to get this in. And so my hope is we will get some of the teams going, and that will actually mean that we can push some of the stuff in.

So when the roadmap is updated for quarter three and quarter four of 2019, it may seem less aggressive than it has in the past.

Yes, but I think there's loads in there. I'm not worried in terms of lots of cool stuff for people to do, but my feeling is this is something that people should be able to get. Unless we get to the end of Q2 and we take a look at it and go, you know what, actually we need to change direction, do this or change stuff around. I feel very comfortable with that roadmap because I explicitly wanted to say, let's just get it there. And then, like I said, I'd rather surprise people with some new stuff than disappoint them by taking stuff out.

Yes. There is some stuff we keep off on purpose because we want to surprise people. We like to have one or two little things that go in there. There is a lot of work that's going on behind the scenes, exactly as you said. Like right now, server meshing: a lot of the prelim work is starting and we'll be working on it through the rest of this year, although it's not showing on the schedule right now. It doesn't mean work isn't going on, and it doesn't mean that there might not be some early versions we may be able to get out. There's a lot of longer-term features that we're working on. In terms of optimizations as well, that kind of stuff is going on all the time, which may not show there. And then once we get comfortable that they're coming to fruition, at that point we will plug them into the roadmap.

We did this roadmap two years ago and we've evolved it and iterated on it the last few years. And now we've seen many game projects out there doing similar things. If I can have an opinion, I think it's a great idea. But it's very easy to look at it and think that that's all that you're working on. And that's absolutely not the case. There's so much more.

It's just that's what we think is going to release. Typically, it's the more rounded features that we feel people understand. Like, oh, this is a feature release here, this is a piece of content here and so forth. But there's a huge amount of other work that's going on behind the scenes also, which sometimes we don't put on because we're not sure it's going to make it, and then we'll make the decision to put it on later. And like I said, some of it we're just going to keep because we'd like to keep it as a surprise. So yes, it's really important that people understand there is a huge amount of other work going on there.

The main reason is the difference between single player and multiplayer. Having a system which works for Squadron, which is a single-player game (and we'll have a multiplayer element of it that people will be able to play, but basically it's one big story, which is single player), getting that working is usually much faster. And also the specific needs that Squadron has: it's a military game, so it may be a piece of technology which is military technology that we may not make available in the PU straight away, and so forth. So that's the main one. Stuff like AI: when AI works for Squadron, then you can get it into the PU, but you need to make sure that all the network calls are in there and so forth. And so that's the kind of stuff where you have to make sure the proper stuff's going on. Basically, in single player, you know the AI's standing over there because it's on your client. If I'm playing multiplayer, do me and you see the same AI? If the callbacks aren't going to the server and back to us and so forth, then you don't know. So that's the main reason.

Well, to be honest, it's a blessing, because we have actually quite a large internal test department, but not as big as some, and they cannot manage the amount of tests we need to do. And not just the Evocati are fantastic, but also when everybody joins the PTU and we get that massive surge on the servers. And I tell you, sometimes we think the game's stable and we've gone through Evocati, it feels pretty good, and then we just go to a big open PTU and everything just falls flat. And I know some of the guys have seen that. Having that is an amazing resource to work with. So having people there who are willing to come in and help us do that is brilliant. And Evocati especially. What's really great on the Evocati side is that they're actually willing to get in when the game's, let's say, slightly more broken than usual, or test some feature stuff. Which, interestingly, is one of the things we're actually going to do this time around as well: with the flight model, we're going to basically open up to Evocati probably a number of weeks before we even go into proper testing, just so they can go and fly and give us feedback on that. Because the new flight model is going in, we want more time on it and we want more feedback. If we put it in for the last four weeks and stuff like that... we want to make sure it's balanced well, because it's a big new thing. So that'd be kind of cool. And that's the great thing that Evocati does as well. They're going to go in there. We're going to give them a drop with a bunch of the flight stuff. They're going to go fly, and we can get their feedback, and we'll be able to tweak on that. So by the time it gets to the mass of people in the PTU, it should have had a good number of changes with suggestions from Evocati. But without that group, it would make our jobs very, very difficult. Close to impossible, because you don't release a game this size, with this many people, with about 60 internal QA guys spread over these regions and so forth. And so, no, we're just incredibly lucky to have the support we have.

And I'm going to add, for those who may be hearing the term Evocati for the first time and wondering how you can join it: it's through use of our Issue Council, which is our big QA platform where our backers can find bugs, submit bugs, verify the bugs submitted by other backers, and help us narrow down the sources of bugs that crop up during the course of development.

Basically, in a nutshell, server meshing is going to give us the ability to put everybody in one instance. Right now we have a server which basically controls... we have about 50 people in one area. And that's about as high as we can go. We'll be able to get a bit higher once we do some optimizations, but otherwise you get into problems with, not so much latency, but the servers get so slow that it causes problems to get everything out. So the server meshing means that we will be able to dynamically have servers control anything from a room to a system, depending on how many people are in there. So you can imagine, once we optimize it and a server can actually control a few hundred people, and we know that a few hundred people have all decided to go to a bar, then we can have one server where all it cares about is the few hundred people in the bar. That's it. And that means that you suddenly get this big feeling of, oh, we're all pushed in here, but the server's controlling that. As soon as you walk out of the bar, it transfers to another server, which is controlling the alleyway outside or whatever. And that's the way we basically get everybody in one place. And then they talk up to a system server, which then talks up to a big old database server and so forth, which then scales back. And so they go, oh, there's 200 people over here, let's put like five servers on that. Oh, there's only one person out here, just one server for the whole system. And then it dynamically just scales how many servers control things depending on how many people are in there, and they basically use the power jointly to try and get people in there. So that's kind of how the server meshing stuff works. And obviously there's levels of this. So that's where you want to go to. It's this beautiful dynamic system. It basically brings servers on and offline depending on how many people there are. It's very neat. It's very efficient. But at first, the first iteration will be... at the moment we're in the planning phase right now, and the work will start soon afterwards, and we'll be working on it this year. And obviously, like I said before, this is one of the things that we're not going to talk about a date for until we're closer. But the idea would be that once we have the first iteration, we now have the servers talking to each other. They're not dynamic, but we have, oh, a server is going to manage this area of space, a server will manage this area of space, a server will do this planet, a server will do this location. And then all of a sudden, when you've done that, you can get a bunch more people in. And so the first test for me, and we'll be involving a lot of people, Evocati and PTU, is you start with that stuff. So the first one is more rigid. It's servers passing people to each other when they go through zones. That way we get loads more into an instance. That will be the first one we play. And at that point, I think people start having a pretty damn good experience, because we're not talking 50 people, you're going to be talking hundreds of people playing together in areas, or in one instance, and systems passing back and forth. And then the dynamic side will be built on top of that as well.

All the work that people talk about has all been done to make sure this works. Without this, it doesn't work. So if you want to say when server meshing work started, it started three years ago. This has been planned for a long time. And so you have to do all these optimizations and make all these changes to code. And then, as you said, object container streaming is a big one, because the server has to tie in with that, because we have to know what's been loaded and when, depending on where you are, and all that kind of stuff as well. So all that works up. And what's happening now is we're at that stage where finally we're doing the last assessment so we can actually start the implementation of the servers talking together for all this stuff. And that is the process which is going to start very soon, and which we'll be working on this year.

Are you sure I can't convince you to give me a date?

Unfortunately, no dates. Obviously, we'll push on it, but on that one, once again, it'll be nice to have a surprise.

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.