Erin Roberts

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.

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.