Star Citizen: March Subscriber's Town Hall feat. Chris Roberts

So we are working on a whole bunch of new UI stuff, and a lot of everything has been held up because we have this new persistence that we're going to roll out beginning with 2.4, and then more of it will be in place for 2.5. So just the foundations will be in for 2.4 and a lot more functionality comes in then. A lot of the UI and management of stuff is changing around because we're going to have persistence now. So we're going to move more stuff to, say, your mobiGlas and some other areas. So we're still in the process. So that's one of the reasons why on the holotable we decided not to be spending a bunch of time on it until we had the persistence and the various aspects, because the actual end goal is for you to not have to go to your hangar to change your loadouts around. You may want to be able to do it live. Say you've landed on a landing pad and you may want to pull out your mobiGlas and go, yeah, can you please move this weapon from here to here and all this sort of stuff. And so that's kind of in progress. So we'll start to see beginnings of that in 2.4, and it will carry on from there. But we are aware that people would like an easier-to-use holotable, which we are dedicated to doing. I mean, that's something that Paul and Del put together in a week about two-plus years ago. The overall concept of using 3D is pretty cool. It's just the fact that there's a lot of usability issues and not detecting and being able to filter it well and all the rest of which will get addressed. And then you'll have the ability probably to manage stuff from your mobiGlas as well as from dedicated stations ultimately in the game. But our longer-term goal is to never have you leave the base game. So right now consider that Crusader, so we'd really like you to start on Crusader, or Stanton is actually the system it's going to be, but eventually the full PU. And you don't have to load a separate loading to go to a hangar, and then go to ArcCorp, and then go to that. It's all going to be going away. That will all be gone by definitely the end of this year, and probably before that. So that's what we're working towards, and that's kind of one of the reasons why you haven't seen progress on the holotable, mainly just because there's a lot of other foundational work that's happening and we don't want to do work that we're going to have to re-engineer.

Everything. Well, so now this year I'm spending a lot of time... When I go over to Europe, I spend a week usually in Germany and then about two weeks in Manchester. And then I'm back here for two to three weeks. So next week I'm going to go to Austin for most of the week. And then I'll be back here for another week. And then I'll be back in Europe. So generally it's more about spending time with everybody face to face, and really this year the focus is trying to pull all the elements, the foundational engineering parts. So the back-end server, how we scale the game servers so we can have as many people as possible. So there's some ongoing engineering that hasn't debuted into the live environment that will make it much better and more efficient and more reliable than the current system, which is some of the stuff that we've redone, but it's also some of the old stuff. And so a lot of it's held together with gum and wire and tape and all the rest of the stuff. And so we have a completely new foundational system that we think is going to be a lot better. It's very next-gen in terms of cloud servers and everything that we'll do. So it's pushing that, pushing the AI stuff. There's a lot of AI work that we need to have working for Squadron 42 and then ultimately in the Persistent Universe. And yeah, just spending face time with everyone. That's why I'm back here, spending time with everyone here, because you can do Skype meetings all day long and all the rest of the stuff, but actually being there and having that one-on-one iteration and conversations makes a big difference.

Persistence is the ability for your game state, the state of your items, your inventory, your ship, your person to persist beyond the game session you have. And so up until now, that really hasn't happened. So you have a set of items, but really that's what you've pledged for or backed and you have sitting in your web account. And then every time you load into Crusader or you load into Arena Commander or into the Hangar, they're instantiated there, but if you take your ship out and it gets damaged, and then you leave the game and come back, everything's pristine, it's not damaged. You don't really have the ability to have reputation persist or money really that persists. We have the REC implementation in Arena Commander, but it's kind of slightly hacky because you earn it in the game and it gets written back to the web platform. And then the web platform communicates with Arena Commander when it comes back. Getting persistence in is a pretty massive step. In the next full patch we release, all the temporary stuff goes away and it's communicating with a persistent database that's sitting in the back end in the cloud. And we will be serializing out your states of what inventory, what's equipped on what item port. And that will persist. Because right now, you can kind of change things around in the hangar, but that just writes it out to a local file. So if you went to another machine and logged in with your account and did it again, none of the changes that you made on the original machine would actually [be there]. And so all those things will now persist. So whatever you set your loadouts, how you set your ships, that will persist. So there are several levels of things that we plan to persist. I'm not sure if everything will make it in for the next release, but over the next few releases, it will happen. But we'll be persisting your money. So we're going to go with what we call Alpha UEC for the initial period. So that will be money that people can earn doing missions and doing other stuff. And they can use that to buy in-game items, so eventually the Voyager Direct store on the web is going to go away and you'll be buying those things in the game. Not all of that will happen right away because we have to implement the shops for that, so we'll have some of the shops and then more and more will come online, and once we have the full set then the Voyager Direct will go away on the web. So you'll be able to buy and sell. And then states will persist. So if your ship is damaged or your item's damaged, you've got to repair. So we'll start to move to a game model where if you fly, you've got to pay for it. Right now, you get rearmed and refueled for free. And so it actually affects gameplay. So the intention of the gameplay is things like ballistics or missiles should be actually pretty hard-hitting and powerful, because their downside is they're finite. You're using ammunition or you're using your missiles, and so you have to go back and buy some more. And so that's kind of the idea where ballistics are a little harder-hitting. They go through shields. But the downside is that you have a finite amount of ammo, whereas an energy weapon may do less damage or gets deflected by the shields, but you have essentially an infinite supply of the ammo there. So what you ultimately want is, when you're flying around in space, you would switch to ballistics or use missiles in a case where you need to quickly inflict some damage, because if you don't, you may be in trouble. Because it's a commodity that is expendable, right? So you have to replenish it. And so that will actually change player and combat behavior, because that doesn't happen right now. People just fire all their ammo and then they can go to Cry-Astro and get it refilled for free. If they're in Arena Commander, when they respawn, they just get their stuff back. So the idea would be to manage your belongings in a way that you would in the real world, which would be, OK, make sure that my ship's repaired. Ultimately, we're going to have age and wear on the ship, so you'll have to keep them maintained. Like right now, if you owned a jet or a helicopter, you would have to rebuild the engine every so many hours of operation. So we'll start to move all that towards persistence, which will actually start to change the gameplay dynamic. It'll be much more like a real universe. But we can't do that all at once, but it will be starting to come in over the next X number of major patches that we're going to come out with. And I think that will be big, because then you'll actually have things to work towards. We'll open it up so you can start to use Alpha UEC to buy ship components and even upgrade ships or buy new ships. And the way it's going to work is Alpha UEC, which means that we can wipe at certain periods, because what happens if there's a bug or there's an exploit or something that we do? So the downside of Alpha UEC is what you've worked towards at some points will potentially go away. We'll probably make it so you can spend your normal UEC that you have, and then we won't wipe things that you've got in that case, and we'll probably allow you to take your regular UEC and also sell those items back, whereas with Alpha UEC it will be more like the final game implementation where if I buy a car, I drive it off the lot, and then I want to come back and say, oh, I don't want this car anymore, they're like, well, OK, but it's depreciated or whatever, where that probably wouldn't happen with the regular UEC in the alpha. But we'll start to roll that out, and all of a sudden that will start to change the feel of the world and the universe very much. So persistence is very, very important, because you can persist reputations or relationships or what you've worked towards. And so that, hand in hand with... we're working on the back-end server tech to enable persistence, to allow you to have seamless handoff between servers. You can have more people in one area, like if you're in the Stanton system, and there'll be dedicated servers in different areas. And if you fly from Port Olisar to Port Correa, you'll be handed off from the server that's managing, say, Port Olisar to the server that's handling Port Correa. And you won't realize it on your client side, because it'll all be seamless to you. The authority is the server over at Port Correa. And so all of that will open it up. And then the universe that you're playing in, starting with the Stanton system, will feel like a living universe and more persistent. So persistence is huge. I mean, that's persistence and then server transition, so you're not just on one instance like you are right now. Those are the two big things that make it a proper, fully fledged living MMO.

No, that's not going to be in the next patch. I'm just saying what we build towards. But the most important thing is the base systems are in there. So there's actually a very, very big change that's happened in the code base that people probably won't notice. It will mean that the hangars will behave differently, because the hangars are part of the persistence. So they're going to be right in with the persistence. There'll probably be a little bit of bumpiness, whatever turbulence you want to call it, in 2.4, 2.5 until we get the hangars back to what you're used to now. Because what will happen right now is you'll just pick what hangar you want to start in, and you'll only be in a base hangar. And then you'll be able to place around some objects and items and say which ship you want sitting in your hangar. Because the persistence database has no way of knowing the setup of your hangar. And ultimately our longer-term goal would be for the player to customize the hangar, so this is the beginning of that. But you'll lose some of the functionality of having the big massive hangars right away until the UI and some of that stuff comes in. But that is now possible, so every player potentially can, instead of it being some algorithm that's figuring out, oh, we have so many pads and these are the ships, and you do something on the web platform, you'll be able to set up your hangar the way you want it. And that will completely persist, just the way your ships will persist. And so I think people will like it. So it's a big, big, big change. And the fundamental aspect of that's in there. So everything's persisting. So we had to change everything over to that. So everything that's done the old way has gone away in 2.4. Very confident there will be issues and bugs and all the rest of the stuff in it. But it is the foundation that builds the proper full living universe.

Well, push and pull is just an extension of what we're doing with the physicalized EVA. So the idea is that you'll be able to grab onto things or push away from things. Pushing away is a physical impulse that you'll push away, and grabbing onto things will be a constraint on the articulated body, the human body that we're simulating. So when you grab onto something, like if you're going this way, you'll swing and you'll be constrained by the point. So it'll be fairly physically accurate. It's something that's going to require a lot of playing around with to make it usable and fun. So we'll probably do things like you can reach out for a grab point, and if you're close enough to it, we kind of let you grab on and push in. Because otherwise, if you actually have to be exact on everything, it's going to be really difficult. But the physicalized EVA is stage one of what the push-pull is. So it's one of the things that's on the plate of what we call the FPS internal team. So we have a group of people that are just working on you running around on foot, and that's the FPS team, and they're handling all the player motions and actions, the state machine for the player. I think in 2.4 we'll have vaulting. I'd have to double-check, but I think it's in. But all things like vaulting or sliding and mantling and all the rest of the stuff. So ultimately, the FPS side of things will be 100% equivalent to anything you'll see out there in the best of other FPSs. You'll be able to do all the same kind of things. That's on our roadmap, and one of those things will be the push-pull. And I actually do think the EVA and the zero-G aspect of the game is one of the things that sets it apart, because you just don't get that in other FPS games. So our goal is to have everything else be at least as good as any other FPS, but on top of that, have this extra dimension. It'll take a while to get there. It's a lot. I mean, we've got about four engineers on that team working just on the FPS and a bunch of animators supporting them and some tech designers doing it, but there's a lot of stuff to implement it right. We're trying to do everything in a very systemic way, so there's a lot of very specific stuff that, say, CryEngine does a certain way because it knows you're only in first person, you're only on foot, and so it handles everything in very specific ways for a gun versus... Whereas with us, we're building a much more generic system. So gun and grenade aren't necessarily concepts that we want to have specific different code paths for. And so there's a lot of refactoring that's been going on to make it a much more extendable system, so that down the road, when we decide to create new weapons and new items and new functionality, it's pretty easy to do because we've got a system. So we've talked about Item System 2.0. Well, that encompasses both personal items, stuff that you would use yourself, like armor you would wear or a gun or a grenade or a hat or clothes you would wear, as well as items that are on ships, like a gun on a ship or a power plant on a ship. Or a seat is an item. Doors will be items. So everything runs with the same systemic code base. They all connect to each other. Doors need to be connected to power. So there'll be a power plant. It should be the same on a space station, where a power plant would give power to, say, the doors and the lights. And if someone destroys the power plant, then the lights go off and the doors don't function. You have to manually open them. Everything in the engine [works] with that. And ultimately, even the spaceships themselves: right now we have this concept of a vehicle, and then we add all the items to them. And the items deliver most of the functionality. Thrusters deliver the ability to move things around, and the power plant delivers the power. So really, right now, a vehicle is kind of a hull, and it can't really do anything until these items are attached to it. People will know when items go away, then suddenly the ship stops moving and working. So we're actually going to take that one step further, and instead of it being a vehicle anymore, you're basically going to have a hull item. And so you'd have a hull item, and then if you want a car, you plug in four wheels. So it's basically like a chassis item. You plug in four wheels and an engine and a steering wheel and a seat, and that's a car. If you want a spaceship, it's a power plant with thrusters and an IFCS avionics system, and it flies around. And the nice thing about doing that is we unify vehicles and items. So the way damage is handled, the way all these things are handled is one system. So it makes it much easier for us to optimize and make sure there aren't bugs. Because a lot of times you have problems in games when you have two parallel systems that kind of do the same thing, and a lot of code. So you change something over here, but you didn't change it over here. And then if there's a bug you fix here, but then you forget to fix it over here, then there's still problems over here. So we're trying to bring everything down to this new design, basically what we call Item System 2.0. It's ultimately almost going to be what you would call in game programming the core entity class. So it's a core concept, and then we just take the item and the entity, so to speak, and we add these components to it. So the components you add to it add the functionality. So it adds the render mesh, or adds the physics simulation, or adds the network component, or adds certain behaviors. Like an item port component adds to it, and that allows the ability for other items to plug into it. And so that's kind of what we shift to do. That is the current, the next-gen way game engines are built: very componentized. CryEngine was built quite a while ago, so it doesn't quite have that implementation. So under the hood we've been completely re-engineering all that to a very different [approach], because that's basically the way you would build an engine in today's world, and it allows us a lot of flexibility. And because we have such a big world, and we want a space station to have all this functionality where the doors and the lights and everything work and security systems work, but have the same on an Idris corvette, where you as the captain could shut down areas and do all the rest of the stuff. And even if you're wearing your armor suit, it's powered or you've got a life support system on the back. And if someone shoots the life support and damages it, then you won't get any oxygen to your helmet and you may asphyxiate. So all that systemic behavior has been built in, and it kind of comes with Item System 2.0. So there are little bits of that in the game right now, although we won't be fully across to it probably for another couple of months, because there's a huge [amount of] engineering stuff, and they've been working on this for close to a year now on this whole build and refactoring of what we've been doing. But when it's in, there's a lot of functionality that you don't have in the game now, a lot of systemic behavior. You'll be able to do all sorts of really cool things in boarding or defending a boarding action or on a space station. There'll be more than one way to solve a problem. And I think it'll be fun. And it will pay off in Squadron 42, definitely in the Persistent Universe. So I'm actually really quite excited. We have quite a few internal prototypes we've done of the stuff, and it's pretty cool. You guys may have seen the little space station prototype that was done. So yeah, there you go. That's probably a longer answer than you asked.

Yeah, totally. And in fact, one of the things we want to do on the bigger ships is to actually give a lot of roles for people to do besides just being the helmsman or manning a turret, right? Or being the weapons officer and figuring out we're going to fire missiles. And so on the bigger ships, as they take damage, what's really going to happen is we're not going to have this big explosion anymore. Parts of the outside get damaged, and they propagate damage to the interior, and there may be a subsystem [that] explodes, and that damage would now damage another system inside. And so there actually will be, hopefully, a fair amount of gameplay when you're damaged, where players can run around. It'll be like an old sub movie where they're sealing off the leaks or whatever. So you'd go and say a power node's gone down on the right side of the ship, and so the turret in the back's not working, and you go there and see how it's blown. You take the fuse out, put another fuse in, power is now restored. Or perhaps if you're the engineer, you'll look at your node layout and reroute the power through another node. So we're building the big ships with this power plant and then kind of nodes, where the various systems come off the nodes, and think of each node as a router box or a fuse box. And maybe some of those nodes could have a battery in them to store power. So if they lose power from the power plant, they've got like an hour's charge or whatever. Some may not have, but these are also the systems that get blown or damaged. And so there's gameplay that would involve, as your ship's taking damage, you're going, quick, go back there, fix the fuse, or work on the engine. So we want to have gameplay on the bigger ships where players are moving around and interacting, and the ship itself functions correctly. So it's not just about the items attached on the outside of it, it's also the items inside. So the avionics module is really kind of like a computer motherboard. You put cards into it that give you this different functionality. You plug them in. And that's that whole idea of the modular item system, where you can plug items into other items and you can just extend out functionality and behavior. And each item brings its own rules and functionality of what it does.

Well, short-term plans, we're trying to address them. So part of the issue is... I mentioned this in the 10 for the Chairman that I recorded yesterday, but no one's going to see it until next Monday. But one of the reasons why there is some desync is because the server and the clients don't run at the same frame rate. So we can quite easily have a server come under significant load and drop all the way down to five frames a second, whereas someone could be running on their machine at 30 frames a second or 40 frames a second. And so one of the big things that we're trying to do is fix some of the server behavior. In the last few patches, we've added some more functionality in places. The more AI you fight... the AI is all simulated on the server. That actually stresses the server more than it would stress the client, because on the client side, it simulates your local [ship]. The remote clients all come from other clients that pass up their information to the server, and then the server simulates all the AI. So every client normally does the IFCS simulation for one ship, but the server will do the IFCS simulation for all the AI ships. So if you suddenly have 50 or 60 or 70 AI flying around, that's 50 or 60 or 70 IFCS simulations, and the IFCS flight model simulations are pretty heavy mathematically. So we're looking at some stuff to optimize how some of the stuff is done, because more and more functionality has been added to it, but we haven't really spent time optimizing it, and that's one of the reasons why the frame rate goes down. Then we have some thread contention issues between network and the physics and the main thread on the server. And so we're just trying to fix and address those to get better server performance, which will help with the desync you see. But the real answer is the full-on back end, the full-on new serialization method that we're going to use, which completely junks the old CryNetwork setup, which we're fairly far along with, and that will be switching out. And that hopefully will just make things much... there'll be less bandwidth going over the network. Because right now there's a lot of bandwidth. When you spawn a ship, there's a massive amount that goes. And also it just ends up sending more data than it needs to. Like if you have a position change, well, the way it's currently set up is these things called aspects. And there's only a limited amount of aspects that can be sent for any ship. One aspect could be your movement, which would include your position, your velocity, your orientation, a bunch of other data. And so that could be, I don't know, a 60-byte or 100-byte chunk. But if you just change the position, it has to send that whole blob of data. But really, you shouldn't have to send that much data. So our new system isn't limited that way. It basically only sends the bits that change. And it's not limited to 32 aspects or anything like that. It's much more flexible. And so that will reduce the data. The other big thing that would reduce the network data is when you spawn a ship. We have very complicated ships. So you have even a Hornet, which isn't a big ship. So imagine a Constellation or something bigger like a Starfarer or Idris. But say a Hornet is a vehicle and then it's got about 60 items attached to it. So what happens right now is the server will spawn the vehicle, the Hornet hull basically, and say, spawn this to all the clients. So that message goes out to all the clients. And then one by one, it starts adding all the items on and sending a message saying, spawn this, spawn this, spawn this. So you're basically sending all this traffic about the Hornet to spawn, and it's going back and forth, there's a lot. And the simple thing would be just to be able to send a message to say, I'm a Hornet, here's the 60 things attached to me, you go spawn it. Rather than one by one, spawning, doing a handshake between servers and clients. So that's what we call a spawn bundle, where you basically just deterministically say, here is the ship and here's all the entities attached to it, you go build it. And then the remote clients are all just doing that and it all happens. And that would greatly reduce the data, because something like a Retaliator can end up being about five megabytes of network traffic just to spawn a Retaliator. Whereas in the method that I'm talking about, you're only going to be passing your entity ID. So in the case of the Retaliator, I'm not quite sure how many things are attached, but that would be the equivalent of, say, no more than 150 times 64 bits. So basically, a lot less. Don't ask me to do math. So those things will [address] the desync problems. And we're aware of them. So what we're trying to do is fix what we can on the current system, because our new system's not that far off from us starting to deploy it. So we don't want to do too much work fixing the old system, because the new system is going to be much more flexible. But the new system comes in with the Item 2.0 stuff. But yes, we definitely want to address and fix those issues. So that's what it is.

Well, the procedural tech's definitely going to be used for what we would call planetoids. So basically a planetoid is anything that has enough mass that it will end up being spherical. We're not going to use the specific procedural tech we have right now to do small, jaggy-shaped asteroids, because it's not really built or designed for that. But for instance, we would probably have what you would consider a moon or a very large asteroid that could be particularly spherical [and] use this. So one of the first things... when we have the procedural planets, there's two things we're really going to use them for. One is the landing area. And the second is that's going to be our first iteration of mining and mineral collection. So these are fairly large and procedural. So one of the things we can do is you can fly around and we can sort of... So when we get the procedural planet stuff in, which is not too far away, the things that we'll have are the landing and the mining. We'll probably do the landing first, and the mining will come in right after it. But we're pretty focused on gameplay that will let you do some other things besides just combat. So doing cargo runs, doing some mining, as well as doing some combat, and creating a very basic economic system that's going on, and we build that from there.

Well, it's going pretty well. I think you're going to see the first part of it in 2.4 when it comes out. So our goal is... we've shifted the characters over to this new item system. So everything you wear, if you wear a sweater or you wear a T-shirt or trousers, a watch, they're all items that are basically attached to your character. So basically, as a character, you're a naked male, or you're a naked female when you have the full female motion sets in. And then you basically dress yourself just like you would. It's like, oh, I'll put my pants on and my shoes. Or if you're wearing armor, you put an undersuit on for the armor and put the armor pieces on and stuff like that. So it's going to be pretty cool. You have a fair amount of customization. We're going to have a lot more clothes and items and variety down the road, but I think at the beginning, we'll just have a certain number of shirts and jackets and different colors. As far as the face customization, that's still a little bit of a ways off. Probably the first version of that is: we have 16 NPC archetypes right now, so 8 male, 8 female, and you'd be able to choose one of them for your character. And I'm not sure if that's going to be in 2.4, but it wouldn't be far after. And then the longer-term plan is to be able to take the archetype and mess with it and give yourself a bigger nose or whatever. But things like changing the color of your eyes or changing the color of your hair or hairstyle, that's all pretty easy on the base archetypes. So that would be your first [stage], so you'd have to choose your [archetype], then the next level would probably be choosing eye color, hairstyle, hair color, potentially skin color, I don't know. And then the final stage of that would be to be able for you to actually move the geometry around, kind of what you're used to in an MMO. And that's really going to come in with this in-fiction idea of going to, whatever you want to call it, the future version of plastic surgery. You pay some money and you can get your face redone. And it's actually part of the story of Squadron 42 at the beginning. That's how, in fiction, you get horribly burned and hurt in the opening, and you get the opportunity to reconstruct your face however you want to be. So that's how, inside the fiction and the story, we get the player to make his avatar be them. Or make her avatar be them. Him or her. Whoever they want to be.

Yeah, well, we're going to push some more. So the plan is to maybe debut a new spacesuit for 2.4, and then we're going to have some more. So you have some player options of: these are my spacesuits, or an environment suit, or perhaps you can buy some armor. Because everyone right now is running around in the light marine outfit, and it's the old light marine outfit. The character models now aren't close to the fidelity that the final game's going to have, and not close to what Squadron 42 has. Our new character tech and shader tech is a whole level beyond what's currently in the game, and I think beyond what we've shown anyone actually. So I'm really quite happy with how that's turning out. Definitely on a par with anyone out there. So I don't look at Uncharted 4 or anyone and say, oh yeah, they're better than us. Or The Order: 1886. We've got some really great stuff coming. So I guess I like it.

The next profession design doc. I don't know. I know everyone's quite keen on the profession stuff. I do know that one of the things that we're going to put a system in place [for] is the kind of recovery system, and we're building it in such a way that it's not just recovery, it's the ability to broadcast your position to your friends and everything else. So it's going to be a lot of the same system. Because people do this already in the game, which is pretty cool, that they go and pick up people that are stranded via chat. And so what we need to do and want to do is start to build that into the system so it actually can be a job, right? So someone can say, oh, I'm stuck in space, pick me up, and someone can get paid 1,000 Alpha UEC to go and rescue someone and deliver them. Persistence just becomes more and more [important], because when the Starfarer gets around to flying, there'll be refueling that will come with the Starfarer. So we're starting to add in functionality, and we'll want to be expanding out the systems themselves, like the Stanton system, and add more areas to it and give you more things to do and reasons to travel differently. So there's a lot of cool stuff that's all happening this year. It can't happen fast enough for me or everyone else probably out there. But I'm pretty excited, because when it's all there and it's all going to be working with the level of detail that we've got, there's no game that's ever going to be like it. And to be honest with you, I think it'll be pretty hard for someone to try to do it and compete. I think maybe the Rockstar guys could, because they've got the resources. But it just takes a lot of work to build something at this fidelity and level with this many possibilities and options. And we get to do it because you guys really allowed us to do it. So thank you for doing that. But it's going to be an awesome experience when it's all done.

Yeah, I don't particularly have an update as in it's going to come tomorrow or anything, but we're definitely working on it. That is the plan. We have a complete revamp of the content delivery plan that we're going to do. So people won't have to download nearly the amount of data that they download now every time we do a patch. Because right now it's just very inefficient, because basically the data is all broken up into two-gigabyte pack files, and if just one byte changes in one of those pack files, you have to give them the whole two gigabytes. So we're changing to a completely different structure that is only going to be about delivering the files that changed, and then the pack files are all built locally on your machine. So we'll actually have the ability, and this is also for our developer side as well as the front-facing delivery, that essentially every time a developer checks in some code or checks in an asset, it's getting built right then and there and added to what they call the object store in our system. And you'll be able to just say, okay, give me the build of this change list, and it can look up and go, okay, and it can just build it from all those. So essentially, it's almost like a, whatever you want to call it, Perforce or a Git of every asset, as it's getting checked in it's getting built. And so what will happen is when we deliver builds to people, the turnaround is going to be a lot quicker because it's basically getting built as it goes. And also we can look at what they have on their machine and just give them the bits they don't have or the bits that have changed. And so it will greatly reduce the amount of data. I think we did analysis on a few of our older patches that were like 30 gigs and determined that using this new system, it would have been seven megabytes. So the system when it's built, and this is the new patcher that's going to work with that, so everyone's working on this. But when it's done, it means our turnaround times will be a lot faster. Right now, when we want to kick off a full build, actually a full, full build where we build every single asset, it's about 12 hours. The reduced builds are about three hours or so. And if we do a code-only build, it's about an hour. But that doesn't include the amount of time to stage it for the QA department to sanity check it and test it and make sure it doesn't blow up. For us, when we're trying to get a patch out, a lot of times there will be fixes that won't make it, because we're like, if we rebuild it now, it's going to be four hours later before we can deliver it live. And that's assuming nothing goes wrong. That's assuming that QA doesn't get it and something that we thought was fixed is broken. And so with this new method, that could turn around way, way quicker. So I think quality of the patches [will improve], the turnaround will be faster, and data use for everybody will be fine. So it'll be better for us, because we spend a lot of money every month. I don't think people realize that. I know that everyone thinks we're still in development and all the rest of it, but we spend a lot of money every month on both data delivery and running the servers that we run. So we kind of behave like a live game in terms of some of our operational costs, which is cool, because I love the iteration. I love the feedback. And I think people definitely out there in the community can see that there is stuff that we only ever see when it goes to PTU or it goes to live that we cannot see internally. To be honest with you, I don't know how all these other big online games do it, because it's not like... we've got world-class people, and there are just things that you don't see until you're under scale. So whenever there's a big launch by whatever big publisher it is and it all blows up, I'm like, yeah, probably because some of these things you just don't see until you get to scale. So the way we're doing it, I think, is going to make a much better game long term. And people are asking about performance and desync issues. You normally would never even be worrying about that in development this early on. But since people are playing and using it, we are constantly having to keep our house in order, so to speak. And the new patcher and the whole build and data system is the next evolution of that. So it's in progress. I don't have specific dates when it will come out, but when it does, I think it will be really good and it will be a better experience all around.

No. I'd have to talk to Tony. It's part of our roadmap. My goal ultimately would be to actually have your hangar be in Stanton or wherever you were. You're not going to a load screen anywhere. It's like you're just walking out of your place, flying out the hangar door, and you're flying out in space. But in terms of visiting other hangars, I would have to coordinate with or ask Tony on that. But I think the way we would implement it now will ultimately go away, because how it would be implemented now would be just enabling the hangar to be a multiplayer mode, just like you're in Arena Commander multiplayer or you're in Crusader multiplayer. Whereas really everything's just going to be sitting inside essentially one big universe, with the possible exception of dropping out into Arena Commander. But even then I think that'll be fairly seamless. It'll stream in the Arena Commander assets and then just hand you off to an Arena Commander server, and you won't see a loading screen like you do currently.

Oh, yeah. And it's the same stuff I'm talking about for the server in terms of better performance, better scalability. The server and the client have a lot of similarities, other than the client's doing the rendering and doing more input-output, because it's having to stream in rendering assets and sound assets. But yes, part of our focus is scalability, so how we can utilize more cores as we go. I think I've mentioned before, in the server case, it really can make a difference, because the actual physical servers we run on have 16 physical cores, or 32 logical cores or threads, if you want to think about it. We run eight game server instances on that. So each one gets two physical cores, or four logical cores, the way you think of it. And each one of those right now has a 24-player cap. So if you just took eight times 24, if you could just have one server instance use all 16 cores, even with us still needing loads of optimization, you're close to 200 players just on one server there. We do run close to 200 players on one physical server right now. But the way the engine's built, we can't scale it that way. We can't just add the cores and all of a sudden it scales better. So we have to refactor a bunch of stuff. It's partly, again, some of the stuff that I'm discussing that we're doing in the background. The new item system, which is really a new entity system. Some of the serialization stuff that we're doing. And we're redoing [things] on the physics side. [We're] optimizing the current physics, but we're actually building a whole new, more scalable physics system, which isn't going to debut [soon]. It won't be for Squadron 42, but Squadron 42 doesn't really need it, because it's really more a single-player game. But we are building one for Star Citizen for the scalability reasons. Because really, physics is the thing that the server does the most. What it does the most is physics and network stuff. And so if we can make that more scalable... the current CryPhysics tops out at, say, three or four threads, and beyond that you're not really getting much benefit. But if we can get that scaling all the way out and more parallelism, then we can just put everything all on one physical instance, which would be much better, because then you don't have these different virtual instances all contending for, say, the same disk access and all the rest of stuff. So it will be good. So we're doing that, and the work for that is the same kind of approach and work for the client. And we're doing stuff on the rendering side for more scalability. So we're starting to put the pieces in place for the move to the next-gen APIs like Vulkan and DX12, as well as cleaning up the whole DX11. The problem with a lot of DX11 implementations, including the CryEngine one, is they really were DX9 implementations that then had DX11 put on top. And DX11 actually operates fairly differently than DX9. But because they had to deal with DX9, they couldn't utilize all the... So there's a lot of organization in terms of how you do things that you can do for DX11 that is also what you want to do for Vulkan or DX12. So we're not doing DX9 [anymore]. So we're basically getting rid of the old stuff, refactoring a whole bunch of stuff down on the engine level to allow better parallelism and stuff. So it's an ongoing task. A lot of that's been done in Frankfurt by the guys that essentially wrote the engine many years ago anyway. And this is all stuff that they wanted to do for a while. So we are working on it. It's just an ongoing slow process, but I think down the road you'll have a very fast and beautiful game. You take a look at what Star Citizen looks like now, what it looked like in 2015, what it looked like in 2014, what it looked like in 2013. There's big differences, and you'll continue to see that.

I would say not too far in the distant future. It won't be the next patch and probably not the patch afterwards, but maybe after that. Because with things like the Starfarer flying around, you're flying around in large ships. And so then there's going to be that whole aspect of boarding and, with persistence of course, taking a ship from someone else and all the rest of the stuff. So that is gameplay that is important. So we actually want to add in gameplay that allows you to lock the doors, and then someone else that's trying to get in has to hack them or use a charge to blow them open. And so all that kind of comes with the new item system. So when the new item system is all fully functioning, all the doors, all the rest, they're all interconnected. They all talk to each other. And you can implement security and states and all the rest of the stuff. So really, that side of it is waiting on the remaining aspects where we're closing out Item System 2.0. But I would say it's in the near future. It's not in the far future.

So I would say that on the paint system, not particularly. That's lower priority for us right now. I'd rather get these base functionalities, stuff that I've talked about, like the item system and locking stuff down. But the way you'll be able to customize, say, your hangar is not different than the way you could maybe customize the interior of a spaceship. Oh, put a couch here. I'll not put a couch here. I'll put a picture on the wall. I'll not put a picture on the wall. In terms of the external livery, our plans are to allow you to place some decals around, put a name down, and then if the ship's set up correctly with the shaders, then you can change, say, your primary or secondary colors or something like that. But it becomes kind of complicated on the very big ships, because they all use modular parts. So at a certain level, we're probably going to restrict it to picking your primary and secondary colors and doing decals, rather than doing very custom paint jobs with flames left, right and center. I mean, that could be done with a decal, but I'm getting totally crazy. But right now the system's in there, right? You need a second UV set to be able to enable that. And if you play in Crusader, you'll meet some pirate ships, and they've got a different livery than other ships have. And that's done with the paint system. So what we really don't have is an ability to expose that to players, like, oh, I can get this skin and that skin. But we are going to implement the various skins, the Electro Skins that people pledged for quite a while ago. So that would be the first stage. The second stage would be to allow further customization by players. But again, there's a mountain of tasks and there's a whole bunch of stuff, and there's certain things like... I think people would rather have cargo working before they can paint their ship, right, I'm guessing, or mining working before they can paint the ship. So it really comes down to these choices that you just make. It's like VR. Oculus sent me my Kickstarter Oculus set, which I think you tweeted a picture of. The box. Of course, I'd like to get all that working, but the same brilliant graphics engineers that would have that all working, which we can because we already have code in it, are also the same ones that are working on things like getting a procedural planet in a shape that everyone in the community can use it. That's everybody can use that, versus just a subset that have the Oculus Rift. So that's the hard choice you make: well, let's get that base technology that everyone can use first, rather than something that's super, super awesome, super cool, but maybe 10% or 5% of our community can use. So it sucks, because I like all that stuff too.