Star Citizen: Reverse the Verse LIVE - It's Chris Roberts, Y'all!

That's obviously a one-word answer, isn't it? What we have right now isn't what I'm happy with. So we are actually, a bit of a spoiler, working on some stuff, a little Skunk Works thing that I'm doing to address some of the issues that I have currently with what we're doing. This is always a difficult one because everyone has slightly different opinions or visions of it. A lot of stuff is being informed by things like Star Wars, which is essentially taking World War II aerodynamic maneuvers and having them happen in space. And when we started Star Citizen, I pitched this idea of having it physically... we have Newtonian mechanics and everything operates inside that, and it does in the current system too. I know people feel like it doesn't, but that's mostly because in a lot of the ships in the current system the amount of... So I actually feel like we have overpowered the maneuvering. And you always do a balance between this, because if you have more realistic forces from, say, your maneuvering thrusters, it means that you will move and turn slower. So there's a TV show, I think quite a lot of people have watched, called The Expanse, which actually does a very good job of being real science about it. And I wouldn't say that I want to go all that way, because at a certain speed it would take forever to turn around and all the rest of this stuff. But if you watch The Expanse, it does a good job of showing the realities of it and also gives you an idea of why, for instance, you would want to keep your velocity low when you're doing radical maneuvering in a dogfight, because if you want to change your heading by 180 degrees and you're going too fast, the amount of G's that would take on the human body is life-threatening, basically.

So what I really want is I want to have the dogfighting work within the parameters of proper physics. I want to bring back the balance on the ships in terms of not overpowering the thrusters, because there's all these different people who want their six degrees of freedom and they want to be able to strafe up and down and do this and they want to be... So what I feel has happened in the past is everyone's had all these competing things they want to see. People want to see their World War II style dogfighting and all the rest. And so there's been too much of it coming in, and to fix one thing for this one particular point of view has stomped on some other stuff, and I feel like everything's become a bit too much of a mismatch and everything's become a bit too overpowered. And so what I want to move towards is more distinct personalities on the ships. And I don't want ships to be so powerful that they can adjust their course as quickly as they currently do. But we don't want to go too far in the other direction, because otherwise people will be like, "Well, I turn and I'm still going this way and I slide forever." And that's super frustrating too. So it's a balance. And I also want to make sure that the allocation of your power, whether you're overpowering your thrusters, has an effect on its heat output and also whether that thruster may misfire or not, or if you get your thrusters damaged, that could also affect your ability to maneuver. And all that's not particularly done or simulated very well.

So we've been working for a while on the new version of IFCS that works inside the new item system, which is all fully multi-threaded and batched and everything. It's not ready to deploy yet. It's what I'm hinting at that we'll be showing; perhaps we'll show a preview at CitizenCon, but we'll see. But it's on our schedule for the end of the year. And it has a full, holistic design as far as this goes, to deliver something that's closer to what I like, which is basically I want trade-offs. I want pro and con to doing certain things. So you could potentially overpower your thruster to be able to exert a bit more force, to be able to turn a bit quicker. But if you're doing that, you're potentially overheating it, which will definitely wear it more and could potentially cause it to misfire. So there's a balance. There's a model, there's a couple of modern, current plasma thruster designs. So that's kind of what we're doing. The idea is that you basically need power and you need matter, which would be whatever, hydrogen or argon or whatever, that you would then turn into plasma and then eject by magnetizing it as fast as possible out. So therefore your power input, or the power that you can pull to your thrusters, helps the amount you can thrust, and then also whatever you're storing is your raw matter that you ionize and eject. So we're running on all that. It will hopefully have a lot of nuance and a lot of trade-off and balance. But of course, on the basic level, we'll want to make the simple IFCS handling within certain parameters easy for someone that's just getting in and playing the game. But if you're an expert, you're pushing it, you're learning how to fly, I think you'll be fine-tuning your power output and thrusters, balancing them and running them as you're going along in a manner that could potentially give you that little bit of an edge in a dogfight. So that's what we're going for.

We've talked about a lot of this in the past. I feel like the current system never really delivered that because it was trying to do too many things, and it was also very designer-driven, in terms of the designers saying, "Well, I want it to roll or rotate or strafe at this rate," and then the algorithm figured out, "Well, you need this much thrust." And then you'd look at it and go, "Well, there's no way that this ship should really exert this amount of thrust from one of these maneuvering thrusters. That's ridiculous. You couldn't do that on something this size." So my big direction is: look, we need to make sure that we're realistic on our masses, we're realistic on the amount of power or thrust impulses we can exert on the ship to maneuver around, within a balance, so it's not fully like The Expanse, because I don't think that would be quite fun. But we're walking the line between where it has been, which I feel is too overpowered, and something that's more realistic. But underneath it, it's all underpinned fully by physics. And the physics system itself is going through a major refactor, which is still a few releases away. But again, we're refactoring a whole bunch of stuff under the hood in the physics for better performance, better scalability on the server and on the client. And we're looking at a different rigid body simulation that's going to be more reliable than the old one. So I think all these things added together ultimately will provide a much better experience. So there you are, that's my one-word answer.

So it is part of the plan. So the atmospheric flight modeling, where we will model drag and lift and wind forces. And part of the previous version of IFCS was it kind of lived in its own little world and wasn't as integrated with physics as I'd like. So the newer version is much more integrated and utilizing the physics, so we can make sure that things like the wind that we would have on a planet that would blow the trees around would also affect your ship as you're moving around. And we're doing some other stuff, like our cloth; we've got a whole new cloth that we're working on that we may show you in the future, perhaps at CitizenCon. Again, the big drive is to unify the systems and try to make them scalable. So the simulation in atmosphere right now isn't as realistic as it could be, because it doesn't model some of the things that I just mentioned. Again, the thrust amounts are too high. So we kind of want to have ships where, if you're flying an aerodynamic ship, you'll get a benefit from the lift that you'll get from the aerodynamic ship. Or if you don't have that, you need pretty strong VTOLs to keep you up. But the days of ships having six G's of acceleration in any particular direction are something that I want to put in the past. And I want more of a distinction. So the Xi'an ships, which are really built in such a way that maybe they can strafe, are a great strafing ship, but something like, for instance, the Hornet should be flown a bit more like a traditional, kind of, yeah, the Star Wars style that you would think. So I want that distinction that you fly different ships in different styles, and depending on how you like to fly, you would pick your ship. Because right now I feel like they all do more or less the same thing, other than their size, and you go, "Okay, I'm in a bigger ship, it's going to do something slower." But I want this ship to go, "Well, this ship is much better at rolling and pitching. So instead of yawing, I'm going to roll and pitch, because I can achieve my goal faster than if I yawed." And some ships may be better at yawing and some ships may be better at strafing. So we want more distinct personality in the ships. And I think that's good for the game, because we have a lot of ships, and I really want people to have a ship that fits how they like to fly and what their personality is.

No, I do like how the quarterly releases are working, because I feel like it gives the team a focus that is near enough. Because the problem is when you work on things that are way in the distance, it's very easy to think you've got lots of time, and then all of a sudden it rushes up on you and you're like, "Oh, we haven't done all this stuff." So it's making us much more disciplined and much more focused about delivering the features and also being more honest earlier on about whether the feature is going to make it. Because the thing is, best laid plans of mice and men, you'll say, "Okay, we're going to get all these things done," then you get into it and you find out, "Oh, well, this is taking longer than we thought," or there's some tech that we didn't realize we needed to build, or this developer got sick and so he's now put us behind schedule. And so things definitely move, and having the discipline of having to get a release out every quarter I think really helps. It also keeps the game much more stable, because, for instance, when we had 3.0, and it was essentially almost a year of development, there was a lot of work that had to go in to just get it stable. And even when we released 3.0, it wasn't nearly as stable as it should be. And if you look at 3.2, it's much more stable than 3.0 was, and even more than 3.1. And so I think releasing frequently helps with the stability. And I think people like to see the progress. I think it's good for the community. I definitely see there's this cycle where [a new release] comes out, everyone plays, amazing screenshots, great videos, everyone's super excited, positivity everywhere. It doesn't matter where you are, on Spectrum or Reddit, it's amazing. And then after a little while, people get bored, and then there's concern threads and all the rest of the stuff starts to go. And then, of course, the next one goes to PTU and people start to get excited again. So I prefer to have the get-bored section be much shorter, and people get to play and engage and see the regular stuff. And so I'm a big fan of it. I think it's caused the development teams to have a lot more discipline. So yeah, I'm really happy. I know Erin's happy. I think most of our development is pretty happy, because you feel like you're making progress. You're getting things out there.

Well, when we were talking about quarterly releases, we didn't think this through fully. We just thought, "Oh, we're going to do one every quarter, which is cool." But when we started to look at our planning, like, okay, we're going to CitizenCon and we obviously have some stuff that we want to show that won't necessarily be in 3.3, but some of the stuff will be kind of 3.3 stuff. And CitizenCon is always quite a big endeavor to pull everything together. And getting a release out is also a pretty big endeavor to pull everything together. And we're just like, okay, it's crazy. We're going to have this massive rush to get everything out for September, and ten days later we also have CitizenCon. And so there were quite a few people on the development side that were about ready to have meltdowns, like, "How am I going to do all that stuff?" So we took a look at it and we decided that it would be better, in future, our plan would be that CitizenCon and the third release of the year should always kind of align with each other, and you make CitizenCon the celebration and the beginning of the release of that. I'm not sure we'll be able to go live at CitizenCon, but we'll probably definitely be able to go full PTU to everyone by CitizenCon, because in some ways you want to go to CitizenCon and be kind of like, "Hey, here's what 3.3 is," and do stuff like that. But that's our plan, just to align them. And if we'd thought about it when we first said, "Oh, we're doing the quarterly schedule," we would have said that. So this is us just looking at it and looking at the logistics. Because the other thing is releases and things like CitizenCon take a lot of focus. And so we're trying to also make life and distraction for developers fit inside certain boundaries, so they're not always feeling they're getting pulled in 20 directions.

And to be honest with you, I've seen people complain, "Oh, look, the AtV doesn't have as much content." Well, it's not like we're deciding, "Oh, hey, haha, we've got loads of content, we're just not going to show it to you guys." But what happens, for instance, when we release 3.2 or 3.1, at that point the team goes into full polish and bug fixing mode, so they're not doing feature development, and then it takes them a bit of time to get back into feature development. Of course, we have some teams that are off cycle working on features that aren't coming out in the current release, so we can show some of that, but it definitely is the case that there is a bit more of a content drought for us to show things as works in progress for AtVs around the release period than there is once we're much deeper into the release period. And the reason why last year was so great in terms of AtV content was because we weren't releasing anything. And so we had loads of stuff to show because we were working on all these features, whereas now everyone's getting to see the features and actually play the features, which I think ultimately is a better thing. But that doesn't mean you're going to get 20 or 30 minutes of AtV full of beautiful, juicy B-roll all the time, because that's, A, a lot of work, and B, it requires everybody to be working on new features that they can show that for. With our new release schedule, we've always got quite a decent amount of the team that's working on the bug fixing and the polishing of getting the current release out.

The analogy I've always liked is it's a lot like statting your character in an old pen and paper RPG. If you put 20 points into strength, you've got to take them out of intelligence. If you put 20 points into charisma, you've got to take them out of wisdom. You can't have 20s across the board. If you want more frequent releases, we have to start pulling points out of...

Yes, that's the truth. I think the last time we were on, we talked about how there's always a trade-off, right? Yes, we would like to do everything, but even with the amount of resources we have, which is probably one of the biggest... There's a few projects that may have more people working on a single game, but there aren't many of them, right? So we've actually got a lot of resources, but still, even with all those resources and all the things we want to do, because we are literally trying to simulate a whole universe from a first-person view at incredibly high fidelity, you always have to make some choices. And some of your choices are things like polish or bug fixing. A great example is the turret stuff, right? So the turret stuff still isn't what we want for 3.2. The turrets need to be better. It's a major part of multi-crew. But they schedule it out, do the sprints: "Okay, yeah, we should have the turrets working." And then you're like, "No, they're still not good enough." Well, that has to now go back into a schedule somewhere, which will bump that team; now they won't be able to do something else they were scheduled to do until they finish the turrets. And so those are the kind of trade-offs you make, where you sometimes say, "Well, what is the most important thing?" And what we're focusing on mostly now is making sure that the current game experience is getting as good as possible. And it's going to take some time to dial that in. But that does mean that sometimes you push back some other stuff. So we haven't finalized our going-forward roadmap, but in the roadmap, accidentally someone... no, it came out last week. Yeah, so I didn't publish the QA staging; they published it, and we're still trying to vet some of the stuff properly. But that's the case of, well, some of these teams were going to work on, say, some of that profession stuff, but they haven't, because we've had them working on polishing the turrets or some other stuff that we thought maybe we would have had done or dialed in earlier, but it's taken longer and been more difficult. And so that's the ongoing aspect of managing it, but I do think the quarterly releases help you do that, because it gives you short-term goals, that you have to get your stuff out and get it in, and so people can see tangible progress, and the team itself can see tangible progress, rather than just all working on a big mess of stuff and then doing a release once a year or whatever it would be.

So our intention is to get the ability to rent ships and purchase ships in. I know that we are working on it for 3.3. I don't want to make a promise that it's going to make it, because it's one of those features where the team's working on it and they're saying, "Well, we're right up against the edge." Because we have quite a few features where, once they start to get into it and we're assessing where they are on their sprints, they start to flag the feature for us and say, "Well, this feature, we're coming in past your cutoff date." Because what we do when we have the release is we have a cutoff date, a month before we want to go live, and the features should be feature complete then. And then what will happen as we get into it is some features will start to project that they'll be feature complete after that date. And a lot of times we'll be like, "Okay, we'll be able to just push that, or squeeze that in, or make it work." And sometimes we just go, "No, it's not going to get there." And then that's when it would move out. So it is our intention. The goal is to get all the item purchasing and ship purchasing and rentals into the game as soon as possible to create the proper loop for persistence that we're going through. Personally, depending on how we do on our economy balancing, I don't want to be wiping the database every time we do a new patch. That's more for if we had something that was horribly unbalanced. We may not be there soon enough, but our goal is to get to a persistent state in the game as soon as possible, where people can earn money doing various things and use that to upgrade their equipment and ships, and be much closer to the final, proper game loop.

Well, I kind of had it in the letter, but I think that in every persistent game that you'll play, everyone seems to treat [it like] everyone's going to be on the starting line at exactly the same time and they're racing to a finish line and there can only be one winner. And that is totally not the vision of the game. That's not what the game has been designed for. And in any MMO that I play, if I go and join World of Warcraft now or EVE Online now, I'm starting way behind people that have been playing it for years. It doesn't mean that my experience necessarily is bad. It's just going to be that I'll be doing different things and different challenges. I have to work my way up. And we already have a certain level of inequality, because people have different numbers of ships. Some people just have one Aurora and some people have got a massive fleet. 150 UEC, 1,000 UEC is nothing compared to an Idris or a Constellation or a Reclaimer. And also people could buy items, so they have as many items and as many ships as possible, but they had this cap. And the real reason why we changed it wasn't because we were all like, "Hehehe, we want to make more money." We actually don't really make that much money from UEC. Most of our revenue tends to be either from new people joining and getting their initial package, or the concept sales that we do. But we didn't want to be in this situation where people couldn't melt the items that they'd bought over the years at completely arbitrary prices, because back then we didn't have any idea. So we were like, "I don't know, that sounds like it's 10,000 UEC or something." And now we have a new model for our economy, and we're starting to bring it in, and that's going to be an ongoing process. But the way we value things is based on the raw materials that are in it; that has a value, the size of them has a value, the quality of them has a value. Then there's a brand markup. There's a whole formula that we have that will also play off in crafting stuff that we'll do down the road. So that means that we're changing the pricing of items. And yeah, if you bought something with 10,000 UEC and now that thing is 4,000 UEC, I would be pretty pissed. And so we're like, well, as we're rebalancing this, and also as we're wiping the database every time we do a release, we kind of feel like we should let the players melt the ones that they've purchased with proper UEC, and then they can buy whatever items they want at the new prices in the new economy version that comes out with each one of the releases. And so the cap was a problem, because there were quite a few people that were over it. And we were like, it doesn't make that much sense to penalize these people when other people have just stockpiled the equivalent of millions of UEC in ships. So for us, it's all the same.

And then in terms of the gameplay itself, like I said, first off, a lot of people seem to think of Star Citizen as PvP, "there can only be one" Highlander style, right? I put that in my letter. But it's not. Yes, if you want to participate in PvP or compete with other organizations, we are going to put that gameplay in there. But the design of this is to have 90% of the universe be AI. So actually most of your content in the game will be PvE, and it's certainly going to be fashioned in a way that if you don't want to engage in mano a mano, or person a person, or whatever I should say, the appropriate setup in terms of competition, you don't have to. And one of the reasons why I want a 90% AI population is that the problem with PvP is there is always a winner and a loser, and both those people are players that have paid money for the game, and not everyone is the best dogfighter, or not everyone's the best FPS player, or not everyone's the best trader or whatever. So the great thing about AI is we can make AI of all levels. So no matter what, even if you're a crappy dogfighter, you can still take down some AI pirates and feel like you're the man. It's like, "Okay, yeah, I got him. I took him down." I really want to make sure that that's there so people can have a good time, because if you're only ever competing against other people, then there will always be winners and losers, and if you're someone that's... So I want people that fall into that category to have opportunities to go out there and have fun and whip up on some pirates or do whatever they want to do without having to be forced into head-to-head competition. Based on that side, it's not head-to-head competition, the overall game. The game has that if you want it, and it has something else if you don't want it. So there isn't some master of the universe person that you're going to get to. And we're deliberately building the gameplay to have gameplay for people that want to play lone wolf style, or play with small groups, or play with big organizations and fight over territories; that want to be doing a more peaceful style, they want to mine or farm or trade or something; or people that want to do more combat-focused things like piracy or mercenary or bounty hunter. And we're building all those things to be in the universe and give you opportunities to do them on both a PvE and a PvP basis. And there will be areas where there can be crossover between the two. But it's up to you, whatever you're going to do.

You set your own win conditions.

Yeah. And this is just how I want to play, how I would want the game to be, how I want games to be. And so it's completely reflecting how I, as a player, would like it. So based on those conditions, I don't see whether it makes a difference. Maybe two organizations that want to go to war are all stressed about how many Idrises they've got and all the stuff at the start. But even in that case, it's not a sprint. It's a long-term race. The opportunity to earn money in the game, and even to get items that you can't get outside, is much greater. So it would probably help if people... I think they base what they know on past games, or they theorycraft and they all get worried and concerned about it. But I know what we're building, and it's built in such a way that I'm truly aiming to build a game that hits these different spots. And I think I said in my letter it has a really large tent for everyone, and it's just a destination; it's up to you. If you want to get up in it with other people, great. If you don't, and you want to just chill out by yourself, you can do that. It's really just a destination and a home, and you make it what it is. And in that case, yeah, there should not be a concern.

It's one of the things that first drew me to the project way back when: it's your universe. We refer to it as the first-person universe. You step in. We're building the sandbox. We're building a universe of opportunity. And the players come in and they decide what their goal is. They decide what their win condition is, and how you go about attaining that is entirely up to you.

Yeah, 100%. And that is absolutely the goal and the DNA. And that's the philosophy behind all the design decisions. And not everything is in there perfectly yet, of course; it's got a lot of stuff to go. But if you know that, then I think you should be a lot less worried about these things, because you're not forced into a competitive environment if you don't want to be in one.

Well, I think the most immediate one is the object container streaming stuff, because it's the one that's going to allow us to expand the world in a manageable fashion. So we're working really hard on that for 3.3. It's a lot of work, because it requires every single piece of game code to operate in a thread-safe and batch-safe manner, which is different from how the engine was built previously. So there's a lot of legacy code that we have to rework, and all our new code is being built with this in mind, but again, not all of that was necessarily built with it properly, and we've got to test it and make sure it's all working. So the undertaking to go to object container streaming is as massive as, more massive than, moving to the large world [and 64-bit precision]. It's a huge effort on the engineering side. But once that's in, that's going to open up a bunch of stuff.

And then there's a few features beyond that, like the physics I mentioned earlier, because that's one of the last holdouts that isn't properly batched the same way. It's still multi-threaded, but it's an asynchronous model versus a phased model. So an asynchronous model is you're doing several things at once. So maybe you're updating the entities, then you're updating the physics at the same time, and perhaps even rendering at the same time. And then you have problems syncing between them, because the entity drives the render and the physics drives the entity. So the best is what's called a phased batch model, which is you update the physics, and you use every single core you can, and, say you have 10,000 physics objects, you distribute them to all these different cores and they do that simulation, usually in little islands, because any objects that would be interacting with each other would be on one core. And so you blast through that as much as possible, use all the computing power to resolve the physics, then you do the update of the entities the same way, and then you render the same way. So we're moving to that model. But that does require refactoring, and physics is one of the last things. And when we do that, the physics can scale much better, because the problem we have on our servers, which have a lot more cores than our clients, is that physics only operates on four cores maximum. So even if you have a server with 32 cores, you can't scale. And when we can scale the physics, that's when we can really increase the player count on any individual server. And then the final part, obviously, is the server meshing. So I think what will happen is with the object container streaming and then moving to the batch model of physics, we'll be able to get the player count on any one server to at least 200 or so. And then the server meshing will allow us to go quite a bit beyond that in terms of people in areas or instances in the same place. And then that world becomes truly massive, and everyone can exist in the same area and venture around and live their virtual life.

Just gave Ricky a heart attack.

That's on our plan. That's our project plan. I'm just telling you the bits of tech that are going to enable this seamless universe online.

No, so we're going to get 3.4 out by the end of the year. What it really is going to mean is that the third release of the year, the Q3 release, will probably always be the biggest and meatiest release, which it is in this particular case. It's a massive release for us. And the fourth quarter release will probably be the smaller one. The first quarter's tends to be a bit small, because everyone is on holiday for the Christmas holidays, and they come back and it takes a bit of time to get up to speed. So usually the Q1 one has less than, say, the Q2 or the Q3 one. And the Q4 one, we're already working on stuff that will be in the Q4 release. But yes, again, it's not going to be delivering as many features as obviously the Q3 one. But our goal is to get that out for the... actually, it's not even the end of December, because we really need to get it out before everyone goes on holiday, which is usually the 15th or 18th of December every year. So our goal is not to have that affected. It's just basically we'll align the Q3 releases with CitizenCon, because it makes sense in terms of focus and effort, and you can consider that the primo release in the year. And then the second big release would probably be the Q2 one, and then the Q1 and the Q4 ones would still have a bunch of stuff in them, but they wouldn't necessarily be quite as meaty as the Q2 and Q3 ones.

No, it's not coming with it. So we will have oceans. I'm not actually quite sure what we're... I don't know if we're just going to kill you if you get into it. But as part of what we call our backlog, right, our active backlog, we have swimming. Buoyancy for ships and vehicles and stuff is also part of the physics, and so that'll get taken care of. So the ultimate goal is, yeah, you will be able to walk into the water and swim, or drive a little boat around on it, or if your ship is buoyant, it could maybe float on top of the water. But for 3.3, I think it's going to be mostly the visual side of it. We've been working on the shoreline rendering and the wave tessellation and simulation. And the support for the more player-centric things like swimming is in the backlog for future releases. I don't have the backlog in front of me; we just have a long list of things, and a fair number of the actor ones tend to be prioritized based on what we need for Squadron 42, because we're obviously trying to get that one out as soon as possible. And so something like swimming, I think, is pushed back a little bit because of that.

Yes, absolutely. So the idea is to have a rolling four quarters as we go forward. So we're actually in the process of that right now, because the first rollout of the roadmap was a lot to get all that stuff in, and so some of the later things that we described, we didn't fully break down as much as we do when it's the release for that coming quarter. So one of the big goals production has been working on, that you guys don't see, is their instruction that if we have these things on our roadmap, instead of just having them as a placeholder, have them broken down properly: exactly what are the subtasks, what are the features, what are the time estimates, in a more accurate manner than we've had in our longer-range stuff. And so we're in the process of that, and that's one of the reasons why we haven't officially published a roadmap, because I sat with everyone and said, "Look, I don't want to move these things into a particular quarter without actually being 100% sure that we can achieve that. So break all this stuff down," even if it means that certain things we won't be able to deliver. Because, for instance, for the professions there was a bunch for 3.3, and object container streaming has taken a lot more engineering bandwidth than we had originally thought. A lot of people have been doing this massive change in the engine, and it's across all the game code. So that means all the game teams that work on things like repair or salvage are going and making it thread-safe and object-container-friendly, and all the components they've got. And so they get pushed back in terms of when that can happen. So that's one of the reasons why the stuff shifted out of 3.3. And I just want to make sure that we're realistic for the continuing professions in 3.4, 3.5, 3.6, et cetera.

Yes, so that is my big pet peeve and bugbear. And if you sat in our meetings, you would hear me harass our actor teams, because there's a lot of small, detailed stuff on this. But essentially I want to make the use of suits and helmets appropriate in the same way they would be in the real world. So for instance, wandering around in medium or heavy marine armor, you should not be able to sit in the pilot's seat or an operator's seat to operate stuff. And in terms of doing things and communicating, I want having your helmet on to have an impact on, say, your stamina or ability to communicate. And so what I really want to move to is what we call a physical-based inventory, which is why we're building lockers onto the ships and everything. So you don't have some magic bag of holding where you can have every single outfit sitting there. Literally, if you have your spacesuit, what I want you to do is get aboard your Connie, and then you take off your EVA suit and your helmet, and then get into the pilot seat to fly. And then if you've got to go outside, or if there's some decompression, you've got to run and put the suit on. And you shouldn't be able to operate or do things in cumbersome equipment. Or if you do, the cumbersome equipment makes it more difficult, makes you slower, makes you have less stamina. Other things that haven't been implemented properly yet are what we call the player status. We have a little bit, you've seen the stamina, but the light role-playing elements of having to hydrate, having to eat occasionally, and potentially having to go to the restroom or take a shower so you're not smelly. But basically we want it light, not like in the real world, where it's three times a day or whatever. But I want to have those so it facilitates behavior. Like if you go to a landing zone, you take off your suit and you're walking around and you can talk and communicate with people face to face, versus everybody running around in battle armor or space suits, and it just feels kind of weird. And that's mostly because we don't have the penalties for having those things, but we will.

This is another one of those priority things on the list. It's something we started to play around with, but the physics programmer who was doing it, David Coulson, is front and center in what we're refactoring, the more physics-driven IFCS. So that's on hold. But once we get it done... He first started the prototype, because we have the room system, and so we know what the air and oxygen is. The room system bleeds out, so we know the amount of bleed-out. And here we go, this is a test. When the doors open, there you are: there's a vacuum out there, and then there was oxygen, and the room system bled out to there. And it only happened when the door fully opened, because in that particular test the door was basically saying, "Once it's opened, I'm open," versus, as you opened it, it would increase, which would be something we would fix. This is just a very early prototype, but that's basically applying a force on all the objects that are inside the room based on how fast the atmosphere or the gas was exiting the room. So we have most of the systems to do that. It's just pulling them all together.

There's just so much foundational stuff. I personally have been working on a refactor of the attachment and physics stuff in the engine, which will give us a pretty big performance boost, hopefully, when it's all in. But again, it's refactoring things to think about the scalability of the engine in our use case, because whether it's what we're using, which is CryEngine slash Lumberyard, or even if we were using Unreal or Unity, they're not built to have the size of world and the amount of objects to simulate. So we're doing a lot of work that changes the thinking, because we have to think about how this thing scales with worlds of this size and object counts of this size. And so that requires a lot of rework and refactoring. So there's a fair amount of engineering that always happens where you don't see the sexy results. It's under the hood, but then it enables you to have a much bigger and more immersive world.