Star Citizen: January Subscriber's Town Hall feat. Sean Tracy

There are so many challenges. Wow. That's a pretty broad question. So I guess I'll pick a couple points that we're dealing with right now. One of the hardest things to deal with, obviously, is the physics of this. So not so much in terms of the scale, but... Okay. So the way physics really works within the game, you've got a bunch of render mesh, and then you've got a physical proxy, which is a way, way lower res representation of whatever you want to collide with. The reason it's got to be so much lower res is that you are doing so many more calculations on that than you are on a render mesh or something like this. Eventually you'll just render it, but in physics we're interacting with it, we're shooting things at it, we're crashing into it, we're doing all kinds of different things. So the problem is with a planet of 10,000 kilometers or something like that, you cannot possibly load that entire physics mesh all the time. And even worse, even if you tried to do that, the sheer count of that, even if it was lower res, would be so high. So what we have to do is dynamically load this physics. And we've got to load it on a sort of a per-client basis, because typically on a server you'll actually load all your physics data all at once. You'll have it all just sitting there. You won't stream the physics in or out. It'll just be sitting there. And obviously we can't do this on a 10,000 kilometer planet that has mountains and hills and all sorts of different things. So that's one of the biggest challenges that we have, but we've already got it working, which is pretty neat to know. I don't know when we'll show that, but we've got something quite nice working for that. We'll calculate it on a per-client basis. So that was one of the biggest hurdles to actually making this playable for the players, because obviously if you don't have physics on a terrain, you fly right through it and it'll kind of ruin the whole experience. So that was one of the bigger ones.

On top of that, of course, is just the visuals of the planet itself. How does that look? And again, the scale is just insane. How does it look when you're 300,000 kilometers out from that planet? You've got to go from this planet just inheriting one pixel on the screen, to it taking up the entire screen, to it being like you are inside of a level. So being able to transition through the atmosphere, making that look hyper real, was really, really challenging.

How many LODs are involved in that?

It's actually way more complicated than that. And I wish I could say there was like six LODs or something like this. No, there are so many different levels of processing that happen on the way in. So sure, there's a bunch of LODs as you're approaching. But once you get in there, it is a dynamically tessellated object. So essentially what you're doing is you're only going to tessellate the objects that are really close to you, or the sectors even that are really close to you. And most game engines have a terrain system that works this way. Unreal has a, CryEngine has a base sort of terrain system that works on this dynamic amount of tessellation. The trick is to get that to convolve around a sphere, first of all. And then second of all, is to be able to synchronize this all over the network. And again, that's got to lend itself to physics. That's got to go across different clients. There's a lot of challenges when it comes to this.

And then maybe the last one that I'll talk about is the actual objects on the surface itself. Now, I'm not talking about procedural objects or trees and rocks and things like this. I mean landing zones. To give you an idea, Area 18, that level right now, we're talking four to six gigs of data within that level. So imagine flying up to one of these planets, which is pretty heavy by itself, and then also having to load that landing zone on the way in. To be able to stream that amount of data, you can absolutely do this, but can you do it seamless? Can you make it look like it's not just pop, pop, pop, pop, a bunch of objects sort of streaming in? That's a huge challenge. So that's something that we're working on on the engineering front with these things that Chris talks about on occasion called object containers and these sort of things. So we've got a very unique game where we basically have to be able to stream everything out and everything in at runtime. So it's a very, very challenging thing to do. Very few level loads, so you can't just sit there and load everything behind the scenes.

Challenging, but we have our plan in place, and it's starting to work.

Yes, absolutely. Carl Jones, our CEO here at CIG, we had a saying when we both used to work for Crytek, and that was: difficult takes a day and impossible takes a week. So this one is on the level of impossible, but we're absolutely going to achieve it.

It was, and we pulled it out, actually. So we pulled it out on purpose. It looks like it's definitely going into... Well, I say definitely. I am so going to not say definitely. It's in our branch for 2.2 right now. So it's basically the same as where we were at with 2.1. However, there's been a ton more work that's been done on it. One of the biggest problems was, it has nothing to do with crashes, has nothing to do with performance, has everything to do with the way it feels, the control of it. Because fundamentally, we changed the way that the character is getting locomoted around when you're in EVA. You are now, we call it a driven ragdoll. It's a similar system to, if anybody's seen these animation systems called Morpheme, or FIFA actually is a really good example. They use a very similar system, where there's a level of driven ragdoll. We call it an articulated entity. So basically you're a set of rigid bones that is getting driven around. But you've got to blend animation on top of just physical impulses that are moving it around. Whereas the older EVA, and what everybody's using right now, is an animation-driven EVA. So we say entity move here, entity move here, entity move here. The animation just plays based on how you're moving. It's actually pretty simple. You're moving forward, well, animate like this. You're moving backwards, well, animate like this. So with driven ragdoll, it's a lot more tricky because of all the physics that gets involved with it. The reason we want to do driven ragdoll is we want the body to react to things in zero G as you would expect them to react.

Now, I think a lot of people saw some of the fun videos that came out of the initial implementation of it, where we hadn't tightened up a whole lot of the limits. So somebody could go near a ship and if it hit their head, their head would bend almost all the way backwards and things like this. So again, it was all about scaling those physics impulses and those sort of things, but really getting the control better. Because our frame of reference changed so drastically between the old EVA and the new EVA. And what I mean when I speak of frame of reference, and it's something I talked about before, is where we would use the origin of the character. Say, this is a character, and this is the feet of the character, and in the middle of the feet is the origin. We've just got zero, zero, and that's where our origin is. But when you're in EVA, actually, your origin changes. Your center of mass becomes dynamic, which is quite cool. Usually it's around the hips. But because it moves around a little bit, that makes controlling it really tricky, because you've got to have something that is saying, OK, this is my forward direction. Which way is forward? Which way is up? Which way is down? These sort of things. So there's been a lot of great check-ins on it, and it feels so many levels better than it initially felt. So will there be bugs? Probably, but we'll have to cross this bridge when we get there.

Well, that's what we had before, was fake EVA. And everybody was happy with that. I'm not saying that it was awful. But visually... okay, visually I thought it was awful, because here's my problem: when you pitch or you sort of rotate, you were rotating around the feet. And again, we only had some limited free flight, and even in the mini PU, are you really sitting there staring at a guy doing a lot of EVA? Not so much. But let's say you're in a gunfight with a guy and all of a sudden he presses E and he starts rotating around like this. It just looks stupid. It looks fake, and that's not what we want. And most people would say, okay, how about you just offset that origin to the hips and then just rotate around that. Well, that's a little bit tricky, because actually the animation system is assuming that origin is between the feet. So it's better to go change it to an articulated entity, get all these bonuses of actually being a driven ragdoll, so flying into stuff and your arms reacting, your head reacting, and mostly your legs reacting, than it was to just continue to fake it, if that makes any sense.

The other big win that we get out of this is another system that we worked on sort of in concert with the physical EVA, and we called it fall and play back in the Crysis days, but for us it's more like fall and play and fall. And the implementation is going to get a little bit bigger. As you transition in and out of gravity is kind of our big thing. Right now how it works is, as soon as your pivot comes within some sort of gravity volume, boom, we just drop you down and you land on your feet, whether or not you were coming in head first, whether or not you were coming back first or anything like this. So what I wanted to do with it was basically give you a range that you would be able to land on your feet, essentially. So right now, I think we've set it to 20 or 30 degrees, and it's like a little cone. So again, if you consider the pivot of the character, you can be rotated, I think it's 30 degrees, you can be rotated sort of 30 degrees forwards, backwards, sideways. You're basically within this cone of 'I can land on my feet.' So when that happens, you transition into gravity, boom, you're able to actually land. But if you come in head first, what do we do? Now, we could try to animate a bunch of different directions, but this gets really heavy to maintain, and also it doesn't really look right. So instead what we do is, when you transition into gravity, we set you to ragdoll, driven ragdoll. Well, you technically already are if you're in zero G, but we kind of take the control away. You already have mass, so we put gravity to you. So what will happen is you lose control a little bit, but if you came in head first, you actually ragdoll, you're under gravity's effect, and you will fall, blam. You land on the ground in ragdoll, and your arms will go all over the place or whatever. And then what the fall and play portion of this is, we will blend whatever pose you've landed in into a getup animation. So we have eight different getup animations, and they're just sort of different ways that the body could land. So on the belly, on the back, on the side, sort of crouched down. And then we will blend into a getup animation and you will just get up from your fall.

So there's a lot of gameplay that can come out of this. And I know this sounds like you wouldn't see the direct impact of some gameplay with this. But consider things like an FPS level, or even within a station that has gravity generators. So let's consider you've got two different teams and you are fighting in this sort of area. Now, if you are in communication with your team and you control some sort of gravity generator or something like this, you can use this very much to your advantage. Let's say we have a hangar and a gravity generator. You've got the other team in the hangar, and they're flying around all over the place. They're going to town on your guys because they've got zero gravity. They can go upside down and all these sort of things. You get that other team way up in the air, and you tell your other guy to throw on gravity. Guess who's all falling down, and they have to get up. And you've basically got about five, six seconds of just picking them off as they're getting up off the ground. And then additionally, there's other things that we could build on. I'm not sure if the designers have really fleshed this out yet, but how much better are you at transitioning from zero gravity to gravity? Is that 30 degrees actually for you more like 40 degrees? Is this a character progression thing? Is this something that you can have an item for? Do you have thrusters on your suit that can help you with this? Are you like a cat? Can you always land on your feet? There's all sorts of little bits of gameplay that can go into this. That was a really long-winded answer for kind of what's going on with physical EVA. But again, it's a real exciting thing, because I don't think it's been done before. Not like this anyway.

Really well. There was a great thing that happened about two months ago. Our animation director, Steve Bender, had gone out to Frankfurt and did a lot of direct work with our animation R&D programmer. And just so you guys know a little bit of history on this, too, we did work together at Crytek: the R&D animation engineer, Steve Bender and myself. And there were a lot of guys within Crytek, and we had tried to unify this for Crysis 2 and even for Crysis 3. And we were all pretty much set in the way that you can't. You just can't. There is no way to do it. You're always going to be chasing your tail. What looks good in first person doesn't look good in third person, and vice versa. But we made a change. I've got to leave a little bit of magic, so I'm not going to say exactly what it was, but we solved the problem. And by we, it was really Ivo Herzeg, the Frankfurt engineer, that with really kind of one line of code solved it. And it was interesting, I made a little meme for him, like, 'a thousand man hours I do in one line' or something like that. But yeah, we solved this.

The nice thing about it is it feels like an FPS again. It feels like the weapon is in the right place. It's not bouncing around. If you go look at the older videos of the FPS before any of this implementation went in, the weapon's bouncing around everywhere. It doesn't really look like the solidified first-person shooter. At the same time, we didn't want to have a static weapon. We just don't want to have a floaty weapon. Chris talks about it all the time. He just doesn't want a weapon sitting there floating in your view. He wants it to feel like you are holding it. But at the same time, it's got to feel super responsive. And the real problem with it is that in a first-person shooter, the weapon is the only thing that communicates your movement to you. So if you're turning, for example, that weapon needs to cant and things like this. A good one is cover. So when you go into cover, you can't tell if you're sort of poking your head out or if you've just moved the weapon. So it's the only thing that really informs your movement in first person. So if you're juking, if you're doing things like this, the weapon needs to move, and that needs to translate to, oh, okay, that's how my character is moving. A third-person game doesn't have this problem, because you're staring at the character. You know exactly what he's doing. But a first-person game definitely does, because you don't know necessarily what your feet are doing, what your whole body is doing. So it gets tricky in cover.

I would say that it's going really well, probably better than it ever has been, especially since that change, because we've made a bunch of adjustments based on that that will make developing stuff even easier. A good example of this is we've added an extra layer of animation. There's actually like four or five different layers that are happening when we're in first person. But one of the big ones is this weapon hands overlay. It's a clip that we can put on. So essentially what it does is, we have very similar animations for rifles, but we might have different sizes of rifles. So we might have a sniper rifle, where actually I can't hold back here, I'm actually going to have to hold over here. Now my hand poses haven't changed dramatically, but they've changed enough that actually we have to do something. So what you'll see is we've got this extra layer of animation where actually all we do is we just put one animation to move that hand to that location. We link everything up with IK and we're good to go. So what this all means is that we can make more weapons faster without having to uniquely animate every single one of them. That's a big, big win.

And sorry, I know I just keep talking on and on. The start-stops have made super good progress. So this was some interesting stuff that Steve Bender actually came up with some really good ideas on. And then the jukes themselves are still a bit of a challenge. We've got them, and they're responsive now. And so everybody knows, in the original implementation, the jukes felt super unresponsive. That was our really biggest problem with it, just being totally open about it. I'm a mouse and keyboard guy, so you'd be playing on mouse and keyboard and you would be strafing right, and then all of a sudden you would press left and something would happen, and then eventually you would end up going left. And even having six frames of delay or seven frames of delay was enough that it felt super sluggish. That was the problem. And that was one of our concerns in releasing it, because if you didn't see what was happening in third person... it was awesome in third person. If we were making a third-person game, we would have been done. That was easy. But in first person it's so much harder to communicate that movement, and most people are so used to Call of Duty or Battlefield or something like this that has this instant response, and we have to keep that instant response, because otherwise it's not that fun. You feel like your character is controlling you rather than you controlling your character. So there's been some great stuff on the start-stops.

Then additionally, you probably saw that there's new locomotion sets within the mini PU. So those are working really well. The other thing that's kind of exciting about them, and it depends who you are to see how exciting this is, is that there's three cycles within them. So these are three-cycle runs, three-cycle walks. And what I mean by three cycles is left, right, left, right, left, right. The reason that's good is that we can actually make it not completely symmetrical. So basically the second step on that has just a tiny bit of a shoulder dip in it or something like this. They tend to look a lot more realistic than just a single-cycle run, because a single-cycle run is perfect all the time. You never, ever see anything different. But if you go into the game right now, the one that's the most obvious is the backup, and it's probably a little too obvious, and we'll probably chill it out. But when you're running backwards, you'll notice that the shoulders kind of dip down into it. It's only on one of the cycles, but it looks really good, I think. It looks a lot more real, is the point.

A lot of testing, really. So we're trying a lot of different ideas. Chris has a really good direction on what we want to try, and this is something that we're just doing internally right now. The turrets as they work right now, you sit in it, you've got a crosshair, and you are moving the crosshair, and that's how it's moving with you now. The problem with this is that it's actually not like anything else in your ship. If you're sitting in the pilot seat, you've got a nice floating reticle, and everything sort of follows up behind that. What we want to do is implement that, have it sort of like a floating-type reticle that the turret will sort of catch up to. The problem with that is the responsiveness. You've got to make sure that that moves fast enough. And if it moves too fast, it feels super fakey. If it doesn't move fast enough, it doesn't feel responsive enough. And there's no promise that we're going to do this. We're going to try it internally and we're going to see if that feels any better, is the thing. The other thing that I think will help a lot is just a little bit of feedback on where your ship is facing. And this has everything to do with UI: which way your ship is facing, which way your turret is facing. That's pretty much all I know right now on the multi-crew turrets. But I know there's guys in the UK really looking at this pretty hard right now. I'm just not super involved in it, that's all.

So I don't know too much about PureHair. I know that they've released an update to TressFX, and we evaluated TressFX. And here's a little bit of history again: when TressFX 1.0 rolled out, I was part of the Crytek team that did the implementation originally for TressFX into CryEngine. So basically AMD had come over with all their work on Tomb Raider, and we had done a tech demo called the Ruby tech demo. You can look it up. This is something I worked on with IllFonic, actually. Now, not to at all speak badly about the tech. It's very, very cool stuff. However, we've got so many characters on screen, and for us to go with just one character having ridiculously granular simulated hair, and then everybody else in the scene kind of having crappy, poly-soup kind of hair, doesn't really make a ton of sense to us. The other thing that is a worry, of course, is just the performance implications. So in all the games that have used TressFX, and again, I'm not saying it's a badly performing system, but it is not a system for 40 characters on screen. It's not a system for 60 characters on screen. It's really a system for the fur of a hero character. It's really a system for the hair of a hero character. And again, in something like Tomb Raider, there's pretty much one character on screen. You may have enemies and stuff like this, but generally you are only looking at one person. Do we need super advanced level hair simulation? I would argue probably not. I would say that there's things that we can do now with the item ports and these, we call them skeleton extensions, with pretty advanced rigging, that will make it a lot easier for us to do a lot of hairstyles without having to resort to a GPU hair or a TressFX or, I think, NVIDIA HairWorks or stuff like this. So I can't say no for sure, but we have evaluated what was there, and it just wasn't suitable for what we wanted.

And the real trick with those hair systems, and it's just from past projects having worked with them, is getting the hairstyle you really want. It works real good for long flowy hair that's real straight, or even a ponytail or something tied back. But as soon as you want some sort of real retro cut or something that looks very unique, it gets tricky. It really does. And the other thing that we have to consider is the zero gravity of all of this. So TressFX deals with that, but it looks a little weird, if I'm totally honest. How it ends up simulating is not what you would really expect. So that really matters to us. With all that said, we are going to have hair. We do have hair on the characters right now.

And there's one little other limitation in this, and that's the character customization. Because we want to have characters customize not only their hair color, maybe the style, maybe the length. There's a really great Korean MMO out right now. They just released their character creator, which is one of the best out there. And not to plug them or anything like that, I have zero involvement in it whatsoever, I'm just very impressed with the level of customization that they brought it to. It is called Black Desert. In terms of hair customization, I've never seen a better system. Could you do that with TressFX? Sure, it's shiny hair, but look at all the stuff you can do to it. You've got control points, you can pull out the hair, you can make it longer, shorter, you can crimp it, you can do all these things with it. And it's hilarious me talking about hair, because I've got very little of it, and my expertise in hair is pretty limited. But we want the characters to be able to customize it. And again, there's so many settings on the TressFX hair that we would have to then persist and serialize. It's probably just too much.

It's important, because all these systems won't exist in a vacuum. It has to be how they will integrate with everything else that we're doing.

Yeah, and that is the classic tech director role, that we've got to make sure it works with kind of everything. And you can be the buzzkill, unfortunately, and you're a bit of a killjoy sometimes, where it's like, ah, this would be an amazing feature in this one little situation. But okay, what's it do here? What's it do here? What's it do here?

Not really. Well, little bits and pieces. I work with Jason Ely on some of the game-side stuff. But there hasn't been too much going on. And that's actually not a bad question. Really what we've... and I'm not even sure if it's in yet, is the Elo rating. And it's funny, because a lot of people think... just a little bit of trivia for you, the Elo rating is actually a guy's last name. It's not an acronym. It's not E-L-O. It's a guy's last name, the guy that came up with it. So just so you guys know. But Elo rating is pretty important so that we can actually matchmake between similarly skilled players, because that's kind of the biggest concern, so that you don't end up with a bunch of beginners in with the super expert guys. So I expect that to come online, but you'll likely see that come online as Arena Commander makes further progress. But again, the real focus is the mini PU, really, right now. And once we've got simpods within the mini PU, then I think you'll see a lot more work and a lot more game types in Arena Commander.

It totally could. And that's a really good question, and we've talked about this a lot. And let me take you through... I always turn these into a story or a history. Okay, so the best way I can explain it is that with the g-forces, there was an initial implementation of how the pilot reacted to g-forces, and it was pretty crappy, if I'm honest. The next thing that we did was re-implement it, or refactor it basically, so that it uses a blend space. What a blend space means is that these g-force reactions are parametrically driven, which is super cool, because you can pass the g-force data, whatever the value is, to a single animation set, and it's just going to blend based on whatever that might be. The question that came up, and this is now a little bit more on the actual topic, the question that came up during that is: what happens in a local physics grid ship like a Constellation? Does the pilot sit there reacting to the g-forces whilst he's got a co-pilot standing literally right next to him, not doing anything? And what we ended up coming up with was that within the local physics grid, no, you would not actually feel any of this gravity change. I'm not a physicist by any stretch of the imagination, but when you're in a ship that has artificial gravity, it's going to compensate for this effect.

Star Trek called them inertial dampers.

Inertial dampers, right. Now, there is kind of a problem with the design here. When you're a Constellation pilot, you still red out and black out, but yet you're not doing any real g-force reactions. So does that really make a lot of sense? Not really, but it's balanced, is kind of the thing. What we do want, though, is damage reactions. Star Trek, shaking in the seat, whatever. But then we want people that are standing there to have some level of reaction. We can't take control away from the player, but have some level of character reaction to the damage and the things that are going on within the ship. Do we have inertial dampers or anything like that? Not really, not right now. And how it all works is just, if you're within that physics grid, you basically don't react to those things.

Yeah, absolutely we're going to fix that, because of course we want combat on the ships. And I'm thinking more of larger ships rather than the Constellation and Retaliator sort of thing. But we want combat to be able to go on on the ships. If somebody's trying to board your ship, you want to be able to defend it. If there's people on your ship hanging out in a seat that you want to get rid of, then you get rid of them. Here's the trick, and it's interesting, we just had a meeting about this this morning. What we have to implement is a pierceability system for our item components. So this is something that I'm sure Chris will talk about, where we have shield, hull, and then the component within there. And we need some level of pierceability for the projectiles. The way the pierceability system works in the engine right now is basically: can I go through it or can I not? So if I say, yep, you can go through the armor, well, all of a sudden I start getting lasers in the cockpit. I've got the pilots getting shot out every two seconds. So basically we had to reel that back. And we've got to put a deeper system in place with the pierceability, not just a logic check where it's 'can I go through it or can I not?', where there's actually a thickness to it. There's going to be certain areas in the ship that we just won't do that with. A good one will likely be the cockpit. I can't confirm that for sure. I'm not a designer by any stretch of the imagination. Literally the end of that meeting was, okay design, go off and figure out exactly how you want that to work and come back and let us know, and then we will put it in as such. So that was kind of a quick fix to make it so that you weren't just getting shot out of your seat. The really annoying one to me was when you were sitting in a turret and somebody was shooting at you with a pistol or something like that, and that would shoot you out. And that's really cool in Battlefield if you've got an M50, a .50 cal sniper rifle, and you shoot through some glass or something. But I would think that space glass is pretty strong if you're going to have it. You heard it here first: space glass is pretty strong. So the long term to that is, absolutely you will have combat within the ship, but we don't want you to get shot with a laser from outside into the ship just randomly.

It's a great question, a great comment, and he's right. There was just never a need for the idea of subframes, or basically a picture-in-picture, which is kind of what he means. We want it, absolutely. And inherently in the engine, there is stuff that's doing something very similar. And the reason I say something that's doing it very similar is that stereo does something very similar. Stereoscopic rendering, or more specifically the post-stereo technique, not the dual rendering but the post-stereo technique, doesn't render the scene twice. It renders the scene once and then actually generates that second image based on all the stuff in that first frame. So we could do something to this effect, where we're taking that stereo render, whatever the second image would be, and actually map that down to a poly. The trick is that, now that we're doing camera-relative rendering, there's so many camera-based and screen-based effects that we do, post effects on the screen, that won't work very well if you're trying to do a picture-in-picture sort of thing. So you can't do these full-screen post effects on this tiny little thing. But that's okay, because there's other games that get around it by not having any color on that, not having any normal mapping on that. You can make another image with fewer render passes pretty quickly. We really need an implementation case that makes a lot of sense to do that with.

One of the biggest things I want to do this with, and this hasn't come from any designer, but I've talked about it a million times, is that I hate the fact that as a pilot, I don't know where my gunners are looking. I have zero idea. And if I had a tiny little picture-in-picture of both turrets, or even one where I could select where the guy was looking and I got some sort of remote view, that would be amazing. So we're going to move in that direction. It's really to get better teamwork going in the ship, so that you know, one, that you have a gunner, two, where he's looking, so you can actually pilot in a way that makes sense. And three, we need things like security cameras. It'd be really cool, if you're on a transport ship or something like this, to have a security camera in the back so you can actually monitor your ship. Capital ships are absolutely going to need this so that you can actually check different areas of the ship, or boarders and stuff like that, without actually changing the full-screen render. And then a further example of that is maybe a cockpit that's completely closed. How does that work? So there are ways to do it. It is absolutely not inherently supported in CryEngine. It's not something that it ever had the idea of doing. But there have been other licensees, not just CIG, that had interest in that and have done it. A good example of a licensee that did it was Big Red Button when they did Sonic Boom. They actually made split-screen rendering. So that is the exact same concept as having a little picture-in-picture. So it's all about using all that data that you get from one frame and compositing an image based on some of the information that you can reproject onto that new one. In any game, they're usually a frame delayed. They're usually one frame behind. Whether or not people notice, that's a different story. So I hope that answers that.

Oh, sure. And I totally write that off like it's an easy thing. A lot of the voice chat stuff does that already. TeamSpeak is a great example, actually. In TeamSpeak, you can set any of the users to be in a different 3D sort of area. So if I'm playing with you, I have you behind, or over the right hand, or wherever. For us to know where the other players are that are speaking is super easy. We know that pretty much all the time, and within your vicinity we know it even more accurately. So absolutely we can do this. CryEngine already has a voice over IP system within it. The quality is not really where anybody's happy with it right now, and actually the bandwidth is pretty high. So we had talked to a couple of vendors that have different tech for this kind of stuff, and really in the end, we've just kind of decided that we'll just do our own. It makes a lot of sense to just do our own. Now, will it support the 3D positional audio? That's going to be a must. So it's definitely going to have to. If you're piloting a ship, and again, the Connie is a good example, you've got two co-pilots, and this guy says something, it has to come out of the right ear. It's going to sound absolutely ridiculous if it's just a disembodied sort of voice. Where things get even crazier is some of the ideas that have been floated around about runtime facial stuff, where the guy is talking and you look over and his guy's lips are flapping sort of thing.

Yeah, your webcam is recording your face as you move your mouth.

Exactly. There's little bits and pieces of R&D on this, and it might surprise you to know that a lot of our facial animators will just capture their own faces a lot of the time when they're testing stuff, just with their webcams. Actually, in the Bishop tech demo, there's a big range of motion that he does. That was all captured by the facial animator from his webcam. So all that tech exists. It's just, what's the priority of it? Not that high right now. We know we can do it. It's going to benefit the players more when there's a better party system, when that's a little more clear. It's a bit cart before the horse right now. So do we know how we'll do it? Yeah, we have a pretty good idea.

That's a great question, because it's kind of our job to know how each... That's a tough one. I'm going to have to think a couple minutes about that, and in doing that, I'll just fill the air with words. Normally, our job is to know how we're going to attack something. And very seldom do we just jump into something and have zero idea, with a naive level of development. The stuff that scares me the most is the stuff that we don't know that we don't know. And I know that sounds kind of nebulous, but that's the stuff that bites us: when you don't know about a problem that's going to be coming. Because if you already know that this problem is going to come, we can come up with some sort of solution, and we've done that in almost every case.

That's universal to all game development.

Absolutely. All human thought, really. And those are the things that scare me the most. So if I was to answer the question, I would say the stuff that we have not yet seen that is going to be a problem, that's the stuff that I'm the most worried about, and that I don't know how to solve, because I don't know what the problem is.

That's one of the reasons why they call it game development, not game building. There's no blueprint at the very beginning. We're not just building what somebody else has already figured out, just A to B to C to D. We are discovering and exploring the solutions and the options that we have towards making the game throughout the entire process, and we will be right up to the point where we release the game, and even after that.

Yeah, absolutely. Most of us want to just keep building up on stuff. If any one of these developers got six months to work on one thing, they would come up with so many different things. And again, it's really about triaging how much time you can allow them to spend on certain pieces of tech.

We all want this. What it'll be is... I can't believe I'm calling this a smaller scale, but it will be on a planetary scale originally. So as you approach a planet, that's when it's going to do something. The ranges I couldn't even begin to tell you about. Likely what you'll see is that when you start doing the atmosphere entries, that's when you'll be affected by that planet's gravity. Now, are you going to be affected as you just approach it? Is there going to be a station orbiting? Not out of the gate. There's a lot of problems to solve in there, and one of the biggest ones is just relative velocities. Because if you've got a space station orbiting a planet, the space station's moving at whatever, 13,000 miles an hour, and your ship only really moves at 300, how do you ever get to the station? It will always outrun you. Things like this. Unless you then have some level of gravity that will give you a gravity assist, give you the velocity to actually catch up to that and be in that same frame of reference. But it opens up so many problems. So originally, out of the gate, you can look forward to the planets, yes, having some gravity that will affect you as you get close. And I'm talking pretty close, not when you're super far away or anything like that. Now, I said that we've got all sorts of tech online for gravity wells, gravity streams. So whether there's a nebula that has weird gravity within it, whether there's a black hole that sucks you in, there's all sorts of different things that we can do with gravity right now. We just don't have the designs really solidified for what they all need to do, is the thing. But we've got all the tech online to do that stuff with.

In this context, i.e. solar system scale, no. Even originally, when I was demoing the engine for Chris years ago, the scale of the game was smaller. We never expected to do a solar system scale or anything to this sort of effect. I'm super impressed with where the engine has gone with this. And in fact, there's still CryEngine in there, but there's so many improvements across the board that I'm really impressed with. I say super a lot. One of the biggest ones is the local physics grid stuff. It's a unique selling point within Star Citizen. It's a unique feature that I've not seen in any other game. And that by itself, just experiencing that, was really, really cool to see. Additionally, there's so many changes around there. The 32-bit inverse depth buffer stuff, so that we can actually render out to that sort of distance. And then when I first loaded the procedural planet, when it had terrain streaming working all properly... the scale I've gotten so used to working on, they're small now. An eight-kilometer level to me was massive, because if you're talking terrain and just running around as a guy, that's a lot of terrain to work with. So the scale just boggled... it's not even mind-boggling, it really screwed up my sense of perception, even in the editor, because I might be working around and I've got this planet there, and it just looks like a little sphere or whatever. And I start zooming in, start zooming in, I'm zooming in. I've got to turn up my camera to 1,000 meters a second. And just to give you an idea of the amount of change that goes on in the engine, we have these little buttons for camera speed, and we had 0.001, 0.1, 1 and 10. So we've now had to add 100, 1,000, and we even have the 10,000 one, but there's no real reason for that yet. It's just crazy, the scale difference, to sort of wrap your heads around. So I'm super impressed with the stuff that's been done to the engine. And no, I never expected to see it at this scale, I guess, is the answer.