Paul Reindell

Well, this is the very, very first part of the question is before server meshing is PES per server. And as I kind of touched on the previous answer, yes, persistent entity streaming is per server. But as you can take items out of the server database into your global database, and we made sure it's the same exact database, the same data structures, there will be more persistence. So you can take persistence from one server to another server by putting items into your inventory and then taking them out of the inventory into a new server. Your second question is, how do we get back onto the same server? For 3.18, we won't address any matchmaking changes. And it again comes back to we want to get at par with what we have so far before we start to adding the new features. Also, matchmaking changes will become a part of our server meshing work, which we will start, obviously, right after persistent entity streaming hits. So for the very first version of persistent entity streaming, you will just use the same matchmaking logic you have right now. That means if you start up your client, you get randomly matched to a server or a shard. I can use those terms interchangeable at the moment because they are pretty much the same thing. Obviously, it's the same as right now. You can play with your friends, so you would join the same instance. If you crash out of a game, we reserve the slot of your current shard. So that means if you crash out, you will be able to have, I think it's 10 minutes, to lock back in and get connected to that shard so you can recover anything. And as I said earlier, all items which you take into your inventory, that's what you will keep with you, which you can bring to any shard. So that is your way to basically make sure the stuff you want to really keep, you can keep by just putting it into your inventories.

Well, as, as we hinted earlier if you take a coffee cup and you unstow it or you drop it on the floor in a shot, it stays on that shot. And it stays there as long as we will talk about the, the cleanup process a bit later, but it will stay there basically forever. And everyone can go there and pick it up. And if it doesn't matter if, if, if the player is locked in or out who dropped it, like the moment where you bring something into shot, it's part of the shot and will stay there with the persistent shot forever

Benoît: Yeah. That was one, one confusion I saw throughout the questions was the, like, it's important to notice that it's not like you log into the game world and all of the items you've placed in the world are now suddenly overlaid in it. No, when you put something in one world, one shard, one server, it's in that server. And, and so whether you're online or not at that moment, right? So the, so yeah, that's the confusion. There's no, if I log off, is my coffee cup I placed on Clio still there? Yes. Doesn't matter if you're online or not for that specific, for, for items placed in the game world.

We're going to, I think the, the only, the only expectation, the only exception to that is that when you log out, obviously your player gets stowed back into, into your player inventory. And if you do a ship that log out, your ship gets stowed together with you into your ship, into your player inventory.

Benoît:And that includes items that are in the ship as well.

It's always, yes. If we talk about stowing and unstowing, it's always the entire, the entire current state of that object, including everything, which is, you know, I talked about the scene graph and the hierarchy earlier. If you look at a ship and all items placed inside the ship, you can imagine that as like a tree, the hierarchical tree of items. And if you take the, the top, the root of the tree and we put it into an inventory, everything which is under it follows it.

It does not replicate to other servers at the moment. The only, the only way you can bring something. So the first, the first fundamental point you have to understand is every single item can only exist once, right? So you can't have a copy of the same exact instance of an item in multiple charts. If you have your ship and you bring it to chart A, it is in chart A. That ship can't exist in a different chart. And there's a good reason for it. If it would exist in multiple charts, what happened if in one chart, someone shoots the left wing off in the other shot, someone shoots the right wing off, right? We can't, we can't allow that to happen. So what that means is if that ship is in a chart, it's locked to the chart. It is just part of that instance. If you take that ship and pay, bring it into your global inventory, that's then your way to take this ship and bring it with you to a different chart. And every, every, every shot in this very first iteration is its own isolated instance, basically.

And then drawing that line forward to server meshing, server meshing isn't about replication either. Server meshing is about bringing all of these things to all of these servers together in a mesh. And it moves, it transitions, it doesn't replicate.

If we talk about replication, I mean, obviously if I talk about replication, I probably have a different thing in my head because in server meshing, we do replicate objects between different servers because multiple servers will eventually simulate the same chart. And obviously in that case, you might have two servers and they replicate the same object between each other for simulation reasons, right? So we don't be like, it could be that server A simulates one area and server B simulates another area. There's overlap. In that overlap, you have objects in that overlap area replicated to both servers, right? That's why for me, replication is a bit different word, but you can see a shot again, as it's unique individual instance. There's no cross-shot replication plan. We do, once we talk about player basis and so on, we do have discussions with design right now, how we can do that for like, if a player builds a base on a planet, for example, we kind of want to show that on all charts, not just on the one shot the player's in, but those discussions are still happening.

Benoît: Right. So in the case of, so you have a ship, let's start from the beginning, you go to the ASAP terminal and you unstow a ship. So the ship lives, is first in your, in your location inventory, and it's in the global DB. You, request the ship shows up on a landing pad. That's that actually behind the scenes unstows the ship. So it moves from the global database to the shard. Now you can, you can, now it's being actively simulated by a game server. And so there's thousands of updates on it, right. To keep it up to date in the DB. You go in it, you start flying it out. You put cargo in it, you drop some items in it, whatever. Then a 30k happens, right. Server ran out of memory or, you know, something like this happens. Now when you come back to the game, the, that ship is still in that shard. All right. It's still in the persistent database of shard 24, for example. And so if you come back and you're match made, most likely going to be match made on another server because shard 24 is not available at the time, especially if you log in rapidly back in. When you enter your new shard, that ship will not be available for sure. Right. So, but it will be available for insurance claims. What we are looking at, at this moment for this problem, because we know that's a problem, obviously this is not cool, right. Is that when a server crashes, well, we have a dedicated recovery mechanism that we're actually putting in place right this moment. We're working actively on this right now throughout our current stability testing, which will auto stow back the ship into your location inventory. And so what that means is we don't want you to be stuck with your ship stuck in a shard. That's no longer available, right? You were actively playing with that ship. It's got cargo in it. We want you to be able to grab it. And so in the case of a 30k, your, your ship would get auto stowed same as your player, because there's no difference between a ship and a player in this instance. So, that's the goal that we have for 318 is to make sure that that case doesn't happen. So that in the case of a 30k, your ship is just stowed back in, in the exact state it was in at the moment of the crash. You keep your stuff, right. That's, we don't want you to be, you know, stuck with a ship that's unavailable. And then you need to find the shard again. And listen, you know, that's like a guessing game. So we don't want you to be stuck at that.

I do want to add though that eventually, and that's a great feature of persistent entity streaming, if that server 30ks with persistent entity stream before persistent entity streaming, that means this, this whole world would be dead because the memory is gone. Everything is gone with persistent entity streaming. However, the shard and the state of the shard still exists, right? The server crashed because it ran out of memory or there was a game code bug or whatever. It's always game code bugs, by the way. Yes. It's never the core tech. Anyways, when that happens, we can actually start up a new server, and it can load back that shard and then continue simulation for exactly where we left off. Again, for 3.18, because we don't want to address matchmaking just yet. Um, we will do what Ben just said, where we try to take, locate all the ships and we stole them into your location inventory. So you don't lose your ship and the progress on that ship. However, the ultimate goal is that when a shard server crashes, that we restart a new server for that shard and that matchmaking will allow your player to reconnect to that shard and then matchmaking will be able to do, to resolve the slot for that exact shard. So you start ultimately or not in a next iteration, you will be able to start your client. And there will be a little dialogue, which telling you, do you want to wait for your old shard to come back online? Because obviously it takes a couple of minutes before shard is back online and then you will be able to join back to exactly where we left off. Um, and then eventually the final goal, once we have, uh, complete, uh, the, the server matching and the replication layer and the gateway layers all separated at that point, when a server 30 case, you won't even notice you will still stay connected and we start a new server, or we have a fleet of servers already running, which can take over that work. But that's obviously fine in the future. So what we, uh, what, what we're saying is in this very first version to be on pause, what we have right now, server crashes, we take player and you take the ships, put them all into your inventory. So you don't lose progression. And you do, and you will get exact the persistent state back from the ship at the moment, the server crashed. So you don't lose anything. Um, in the next version, we then try to revive that shard and let you let matchmaking allow you to come back to that shart. And then, ultimately in the, in the final version, it should be all, almost transparent to the player.

Benoît: First of all, that's a bastard move. Right. So not entirely related to PES, I understand the mental link between persistence and spawn points and out the four-ing and stuff. There already have been some changes in the game related to combat logging, which is basically out the four-ing while in combat to save your FPS items. Already the ships stay in the game world in 3.17 and then they basically get destroyed. Basically, that move sort of allows you to save your weapons and armor where you respond outside. So PES is not going to solve that because that's driven by game rules. So even though we have persistence, that's the thing I wanted to stress out, even though entities persist, the game rules and the game code can still decide what to do. They can override any values. If you think about respawning or things like that, same thing for logging. So for combat logging more specifically, which is a problem, obviously. It's something that we're going to want to tackle at some point, but the real fix for that is not a new persistence system. If PES solved all the world problems, that'd be awesome, but it's not the case. The real solution is a proper logout timer, where if you decide to out the four or to kill your client or whatever, you stay in the game world for that logout timer, which will allow your assailants to basically finish the job if they have to. And that makes the game fair. Most other games also do the same thing. So that's the idea that we have on the table now. Obviously, we're not tackling this specifically with PES. Even though there is persistence, it's not going to affect combat logging specifically.

I would add, though, because of PES, the login and logout code has to change slightly. It gives the game code teams actually the opportunity to address this issue. And as Benoit said, we're currently discussing some of the login logout flow. And as Benoit said, adding a proper logout timer to that would be a good opportunity right now to do. Another question I also saw asked a lot is, when I log out with persistent entity streaming, will I log back in where I left off? And again, to our point, let's get back to feature parity. For 3.18, we will keep our current logout system. So when you log out and you log back in, you log back at your last landing zone location. However, PES does enable all of that cool stuff. So with PES, it would be very trivial for game code to change their systems to allow you to log exactly back where you left off. However, it always comes back to how much risk do we want to add for 3.18. And also, the devil is always in the details. If we want to have game code now to completely change, okay, you log back in where you log back out, then that doesn't mean, okay, we have the tech right now, so we can just enable this feature. That means a lot of design work. Like how does it work, for example, if I am suffocating and I log out? I think the design wants you, for example, then to run a timer. And eventually when you log back in, you would be dead because you were suffocating at that moment. You want to spawn back in hospital and so on. So there's a lot of design consideration coming into play. And then also game code systems which need to handle that properly. For example, what if I log out on a planet and then on the next day I log back in? And that exact position is another ship landed at the moment, right? So where game code would need to probably do some position resolving and all those kind of things. So in order to not tackle that right now, we would just keep the log in log out flow how it is, however, as I said, with persistent entity streaming, game code teams now have all the tools at their hands to fully persist whatever they want at the state and restore at exactly the state how they left it

Okay, that's a good question. With our old system, we had this, it's called lifetime management, and it would arbitrarily remove entities once they hit a certain cap. And we realized that's not really great for play experience. For example, I think at the moment, players can only spawn up to three ships. If they spawn another ship, the old one gets removed. For persistent entity streaming, we actually revisit that problem. And we decided, okay, how can we make this a nicer for the player, but also be how can we make this actually work good for persistent streaming and also for server meshing, where maybe it doesn't make sense if if a player has five ships spawned and they're all separated in open space and streamed out, they don't really cost us performance. So why do we still need to arbitrarily limit that? And for that, we have the guys in Frankfurt developed a new system. It's called density management, and it operates on relative cost of an area. So the idea is that instead of just taking arbitrary numbers on objects, we look at areas and we look at the amount of items in that area. And we only start to remove items the moment the relative cost of that area becomes too high. So as long as you spawn your ships in different locations and they're all spread out, we will never touch them or remove them. However, if like now everyone goes to the same spot and you start spawning ships and spawning ships at the same location, that's when the system will find out, OK, now the performance goes down because our relative cost in that specific area goes too high. And then we will start deleting items, which also follows a certain rule set. So we will delete oldest items first. We will also have a relative priority on items. So a player ship, for example, is a very high priority item. So we would not delete a player ship versus a coffee cup, for example, would be the first item to go away. And then with that, we try to get the game to where it's not very invasive to you. So you don't just see stuff disappearing out of the air. Exactly like the approach we're taking is that most of this cleanup will happen during stream out. So if an area streams out, that's when the density management will make a first initial pass and will say, hey, in this area, we had 50 coffee cups and that's too much. So we start removing them. And then we only go into the more aggressive policies once it's really becoming maybe an area never streams out or whatever. All players decided, hey, I mean, I kind of expect that right once we go get PSL probably everyone will like, let's all go to Port Olisar and drop all our coffee mugs on the floor and keep doing that. That's what you guys will do anyways. So basically the system will take care of this, but it will be a smarter system. It's a smarter system than what we have right now.

Benoît: One thing to add to thedensity management too, is that it also has this concept of references. And so for example, if an entity, because this also covers NPC entities, right? So like AIs and whatever else. And so if a specific entity is actually being referenced by a mission, active mission or active player, for example, then there's a ref counting, a reference counting system that will prevent those from being actively reaped. So that, again, I think the goal with density management is really to make sure stuff doesn't pop out of your view and break your game experience. But we still need a density management system to prevent overloads. But that's the approach in general.

I mean, I guess you can answer that question. I mean, we go to 3.9, the stuff that you've heard so far on 3.8.2.

Me, personally, I think it's a big step in the right direction. We can lose some in-game persistence, but we can't really lose people's earned UEC or their items they bought and the ship they bought in-game, right?

And hopefully we've cleaned up some of the initial glitches of it. I mean, of course, if there's an exploit and someone's figured out a way to get a couple billion credits, we reserve the right to either individually edit those people's accounts so we can just take the money or the items away from them.

Or apply a general cap.

Or just do a general cap, as Paul says, or even occasionally we may decide, well, we need to just reset the database and do a general wipe, which we're going to try not to do if possible, but you never know because we're constantly adding new structures. The next stage on the persistence, which Paul can probably talk about, is the iCache side of it, which is more fidelity in the persistence. So what we have right now is saying, well, these are the items you have, and we're storing those in a way that can survive the patches, but we're not necessarily storing every item. We need iCache for the foundational, that sort of micro persistence, to do the physical inventory, and that's a big thing. And the other thing that opens up, which is sort of the next stage, which is sort of bigger things, but it would be now because we can persist anything. You can be a player or an organization, you can go down onto a, like all those beautiful shots that people share of microTech and go, I'm going to set my homestead up here. Well, with that technology, that is what we need to be able to do there and that is our plan. So when that's online, we're working on the aspects that would include sort of what you would call base building. So you would go there, you'd have to bring in the right resources and sort of create your little homestead or your base. So organizations or players can create their own areas of interest and essentially will help sort of build out and populate the universe as much as we on the game design side. So as we get these things on, as we get closer to that, we get closer to this sort of completely dynamic universe that you can sort of go anywhere, leave things, build things, destroy things, pick things up. And I think when we get to that, it's going to be pretty amazing.

Exactly. And iCache is obviously one piece of the puzzle, which is our internal high-speed database to store all that data, because obviously that's a lot of data, right? Every single bottle can be persisted and restored. iCache is just one piece where server OCS is a big part of that too, right? So something needs to take the data and stream it in and stream it out and restore it properly. There's a lot of tech under the hood developed right now, which obviously people won't see, like all the features you talk about, they come eventually, people won't see them in 3.9 just yet, but we built a lot of the foundation. And like the server OCS on the server, for example, when we rolled it out in 3.8, which was a big win for us. I think people out there, they were like, oh, we expect it to be like better performance or whatever. But in reality, it is one giant building block to get to this full persistent universe. Right now, without other tech, which is not there yet, you don't really see the benefits yet. But for us internally, it's a real big milestone to get to exactly that vision where we can store every single object and we can stream that area out and we push all the changes the player did to that. We push that up into the database and then when someone else comes back to that area, we stream it all back and it comes back in the exact same state.

If you have the iCache and you have the server streaming, which we have, they work together. Those two are necessary for the server meshing. In the server meshing, because we can have tens, hundreds of servers all communicating with each other, we just need to be able to save out any arbitrary area with its full state, which means whatever items were there or not there or whatever, to some back end so that when we come in, we can stream it back in, whether we stream it out on this server or this server or this server, the state is the same between all of us. And then you also should get much more of the performance impact. So yes, like Paul says, while you don't see the front end feature yet, getting these things in are actually quite exciting for us technically because once they're in, we know, okay, now that enables this next stage. And once we get these several stages in, then all of a sudden all this great, sort of dynamic, tactile universe with state that you can go to with many, many players all together in the same areas becomes possible.

There's just so many layers of it. And we talked about it in the last Pillar Talk exactly, and it was all theoretical. But I did mention one other benefit during that last Pillar Talk that absolutely was in place. And Paul mentioned it, but the load times. Generally now, by default for a developer, it's about seven gigs when it loads up. It's so light in comparison to the 45 that it was.

Before, it was loading the entire universe. And now, as a developer, you usually have one server and one client, and I'm the only client. And I see a lot of benefits. The server starts immediately.

Big, big benefits behind the scenes for us.

Quality of life can mean a lot of things as far as the player is concerned. So from my standpoint, a big focus has been, and it's mandated from Chris and Erin, the player experience, the quality of life of playing the game. So there's no frustrations, there's no annoyances. They can do the things, they can play the way they want to play when they want to do it, basically. In an intuitive way. But I think it also goes down to a more technical level, which is sort of build stability.

We're definitely trying to have a stable build and try to at least be as stable as the previous build or even more stable. And we're willing to hold the build before it goes live for a little longer to get to that stage. So we'd rather not push it out and say, oh, we've made exactly this date, but it's crashing all the time.

There's always the balance between, obviously you can't spend too much time on it because that takes away development time. But it also needs to be enough time so people can actually enjoy the game and start playing the game.

Sometimes it sort of goes up and down a little bit because, for instance, server OCS, that actually was a massive fundamental change in the back end because parts of the universe just would not exist in the server anymore and they used to. And so we would see issues with that that we would never see before. And so I think when server OCS came in at the beginning, we took a little hit on the stability, but we've been fixing and moving those things on. In general, we're doing lots of little things. I think also, by the way, in this 3.9, we've reduced the latency, the rewind time for the FPS stuff. So Star Marine will be much better. It's going to be way snappier. And so will the PU.

And the PU, but the PU benefits a little, and I think, when did I talk about this last on ISC? I can't remember when, but the PU benefits a tiny bit less than Arena Commander because it's really good when the server performance is perfect, right?

30 frames a second on Arena Commander, great. Everything's great.

Once it gets a little cratery, to the fives or so, I guess it does still happen sometimes when the players get all spread out, but anyways. Yes, it's in there, and yes, there is an improvement, especially for a fresh server when it's running really fast.

So the attachments UI, it's pretty straightforward. You go into a mode through the personal inner thought system. You can go there or there is also a shortcut to it where your weapon comes up. It's basically like the inspect mode that we had when you were going shopping for the weapon. So you could take a look at it and you've got attachment points on it. And within those attachment points, you've got a barrel one, you've got an underbarrel one, then you've got the scope one. As you mouse over each one of them, you'll get a list, or actually not a list, it's going to be a grid. So within that grid, you can select the actual options and then you just go.

Of the things you have that would fit on that weapon.

And it was, we went from a list and now the grid looks great. That works a lot better because you can kind of see what it is rather than seeing NV-TAC 18X whatever. So you can see the scopes. You can add them right on there. You can swap them out as you go. And you can also stow your weapon, which will keep those on it, with an option for later that if you pull out another weapon, you can pull that attachment off that weapon and put it on the other one.

And also, like I said, when we shift to physical inventory and just be more tactile, this is a necessary interface because pulling up your character as a thing, that's like a paper doll, like an RPG paper doll thing. We want Star Citizen to be much more sort of in-situ, tactile. I see things, I interact with them. Hey, I need to put a scope on. I put a scope on. And so we want to shift towards that. And so like you've been talking about in this session, a lot of the stuff are building blocks towards cooler and bigger stuff that's coming down the road. It's got benefit and it's cool, but it also enables some of the other stuff. Without this sort of functionality and features, we wouldn't be able to do some of the other stuff that we want to do that I think ultimately will give you a pretty cool experience.

And it's a great point because all the features that we just talked about, all three of these things, the unified friends, player interaction system, personal inner thought, as well as the attachments UI, it's all done through building blocks. We couldn't have done it without building blocks. Actually, there was one little thing that came out of the attachments. When you're holding the weapon like this, it doesn't do it as much justice as it should. When you have inspect mode, it was cool enough, but really the pose of it, oh man, the guns are cool. It gave me a new appreciation for the way the weapons look because you get so used to seeing them. And also to understand the modularity of it.

They spent all the time to break them up properly, to fit all the sniper scopes properly and all the stuff. And now you can actually see that swap in real time.

I hate admitting it, but I stopped seeing it so much. But then, oh, yeah, that looks so good. I'm really happy with how they all turned out.

I really think on the environmental side, I think some people just think, oh yeah, New Babbage Landing Zone, what's special about that? But I think a lot of what makes Star Citizen special is that our locations, even though we use procedural tools to help sort of create at scale, they're very specifically authored. We have a lore, we have a universe, we have a history, and you can feel it. And so when you visit the places, you feel that. And I feel like that's kind of one of the things that makes Star Citizen special, even though we don't have a billion planets or anything yet, you do feel like when you go to microTech, it is different than going to Hurston, for instance, or when you go to the moons. And as we build tools to allow us to sort of create that stuff a little bit quicker, but still with that same level of quality, it'll be great. But I really love that, and I feel like the environment team did an amazing job on New Babbage, and it's going to be fun to go around there and get your burger or get your coffee or just hang out. And there's another nice thing, which we also showed off on ISC: we have the ability now to sort of change our light states based on the time of day. So it's also the interior of New Babbage. One of the really cool things about it is it's one of the first implementations of that. And also there's a whole area, there's a whole bar with a DJ and at nighttime, there's laser lights and it's the party scene. And during the daytime, it's a bit more of a sort of chill day drinking scene. And it's equally cool. Both equally cool. The three moons, which I think we've also done some ISC on, they actually created those in, I think it was like two weeks per moon for one person. So it was three moons, each one took two weeks, basically. And those look great. I mean, they're some of our best looking ones. And now that team's off doing some stuff in another star system, which is looking quite good, but that's another story. But I think there's going to be a lot of fun. Definitely keep people busy for a while. So I think that's really cool.

The other big thing in 3.9 is the prisons, which I mentioned kind of at the top, which I think is a unique consequence when you have something like a law system. And so you now end up in a prison and you've got to do your time. And so there's a consequence to it. And we got some fun stuff, like you can potentially find a way to escape from the prison. You can also go down and sort of reduce your time spent by mining down in the caves there and basically getting what we call merits that will sort of reduce your time. And it's kind of a fun element. And it's also a very beginning building block of fully fleshing out sort of the law enforcement, which would include the bounty hunting side. So we've got a lot more stuff planned for the prison stuff going beyond this V1 implementation we've got, where we'll have the ability to have prison fights and all sorts of fun stuff. And on the other side, the bounty hunting side, we've got some stuff long-term where we want you to be able to track down other players, secure them, put them in your ship, take them, drop them off at the local Advocacy office, and then that person wakes up in the prison, and you'd be able to hopefully track them long-term. So we want you to basically play that Mandalorian-style game. When you watch The Mandalorian, it feels very much like the sort of Star Citizen experience. But anyway, the idea of bounty hunting and tracking someone is stuff that we're working towards. So the prison is one of the elements that's, again, we talk about putting bits of the gameplay there. And of course, we're going to build on top of it. And I think by the time we've finished all this stuff, it will be really cool. The prison system is one element that would add towards making your piracy and bounty hunting and sort of law enforcement cycles all work, and that's one of the elements, but it still needs other stuff and we will get there, and that's kind of our sort of plan. But it's this iterative point where we put another, it's like putting another brick in the wall, another brick in the wall and finally it's there.

It's always the last 10% which brings it from, okay, there's a base system here, to actually now it's a polished feature and you can use it intuitively and it's fun to use.

I think that's the challenge. In normal game development, you wouldn't be doing this out there publicly, but because of the nature of the way the game is, we develop it with the community out there who support us; it's a totally different way. And I actually quite enjoy it because you get the feedback and the early feedback. And we can also make things better and more stable longer term this way. But in the short term, it does present challenges because we always have to make sure that, for instance, we have as stable a build as possible. So we do spend a fair amount of time stabilizing a build that we may not necessarily do if we weren't having to release something every quarter. I think long term, it ends up with a better product because we're iteratively testing it and we're iteratively getting feedback. But on a short-term basis, it means that you always have to spend some time making sure you're triaging your current build and making sure it's working. So that's time that you couldn't be spending on a feature or polishing it. If you're expecting everything to be fully polished and working brilliantly the very first time you load it up, then you shouldn't be playing Star Citizen just yet. But then you would have to wait. That's the flip side.

That's the big advantage: people can play right away. They test out a feature. Not just, oh, I'm part of the last 10% where we polish everything, or I'm a beta tester. You're a part of it from day one almost.

I would say a project of this scale. There's definitely some smaller indie projects where it's very like that, and that's very cool, but a project of this size and this scale, there's not many people doing them, and the people that are, are the big publishers, and the big publishers would never do what we're doing because they just wouldn't want to have to be open to that much feedback early. Star Citizen is never getting canceled. We're just going to keep working on this thing until it is the best space sim, or universe simulator, I should just say, not really space simulator, because it's a complete universe sci-fi simulation game, possible, and that's kind of cool, and it's fun to be working on it, because I feel like Willy Wonka, and it's imagination, whatever you can dream is possible.

Yeah, actually. You decided, I think, two weeks before. They were like, hey, Paul, finish the holotable. And I was killing myself to build up the whole code behind it. The whole interaction, it's not an easy thing. There's nothing standardized. We could use a normal 2D menu, but Chris was always like, oh, I want to have this awesome holographic 3D model-driven table with animations here and transitions there. So I really killed myself to build this out. I think I finished it at 5 in the morning, one day before we released, so it was really super close to get this in. And besides that, I always had to support Dan for all the interactions, like entering the ship and opening doors and sitting down in the seats. I also wrote a lot of code to actually make the interaction of the ship happen. So I always had to switch between, okay, more holotable work, and then Dan was like, oh, and I need this door to have functionality to go on and off. We don't actually have triggers for that. Hacking something in really fast to get this working, then back to the holotable, and just a crazy two weeks.