Star Citizen Live: Get Rich or Die Tyrer

So the first thing to note is that while my title has changed, my previous role of core gameplay pillar director is still there. I'm still doing that. This is just in addition to that. So the way that we worked was that obviously the company, or Cloud Imperium, is set up into these pillars. And each of the pillars has representative teams that have areas of expertise on that pillar. So the core gameplay pillar essentially incorporates the Actor Feature Team and the Actor Tech Team, the Weapon Feature Team, the Weapon Content Team. And it did used to incorporate Firesprite as well for Arena Commander. So those four teams, as you're probably well aware, are dedicated and focused around all of the character gameplay in Star Citizen and some additionals, because we also have a floating team on the pillar, which is the core gameplay design team. And that's what you'd classify as technical designers and system designers. And some companies call them essentially game designers. But we're basically dedicated to making anything to do with the character design. Like the camera, actor status, but we also own things like physical damage, radar and scanning for both ships and the player. So the way that we worked is that I would always discuss it with Chris: what's the intention for a specific feature, whether that's inventory, healing, actor status, trolley push-pull. You name it. Then I would then work with the teams to bring those things to the PU. But the way that we designed the features is that we would sit down and discuss with the PU leadership. So Todd, Tony, Ian, those guys. And then also on the S42 side, where you've got Nick Elms, you've got Brian Chambers, you've got Nate. And what we do is we generally sit down with the design directors or the game directors and go, okay, and this would be with Chris. And we talk about a feature and I get an understanding of how we want to use it. Because obviously on my pillar, I'm also responsible for the FPS experience. So in terms of how that experience is supposed to be delivered in both Star Citizen and Squadron 42. And that's always been the case and will still be the case in this new change. But the deal was that we'd look at these features and go, okay, how are we going to use these features in the games? So we go, okay, so let's take trolley push-pull, for example, and I actually wrote about this, some of the pitfalls of this development, in some of the retrospectives I did in the last two quarters. But the way we'd work is we get the trolley push-pull system and we go, OK, right, how's it going to be used in the PU? Well, in the PU, maybe it's going to be used for cargo and moving things around and also for what you'd expect, like puzzles. When you go to a mission, maybe I can't get access up high. I need to move something so I can then mantle it and climb up. The stereotypical action adventure type of puzzle. And that's really where it's more appropriate in Squadron, because obviously Squadron has all the same content in terms of the vehicles and the armor and so on. And then Squadron has its own specific things. But how you use these features... we will always deliver something in a systemic fashion. So for example, if we were just making a single player game, you could make trolley push-pull just be a movable physics object and be done with it. Because we know it's going into the PU, we went the extra mile and were like, okay, well, it needs to take into account there's different gravity that you can be in, or other people can jump on that because it's a multiplayer game. And you've got vastly different cargo weights, so we have to take that into account. So what we do is we take all of that information and we distill it down into a system or a game design, what we want. And then obviously my job is to make sure that we're distilling that down and that that fits into the overall vision and experience of the game. Both Squadron and Star Citizen, in coordination with Todd, Tony, Chris, Nick and so on and so forth. And essentially we would then tier it in a way. So we'd start off with a tier zero, and the tier zero would be what is the minimum viable product that we can push this development piece to the live audience to garner feedback and gather feedback and then tweak it. But because we're such a big company and we have such big releases, generally by the time we've released a tier zero, we're already well into another feature. And then the T1 comes at a later date. So for example, a really good example of this is actor status T0. We released it in about 2018. I remember we talked about it at CitizenCon. I think it was the patch after CitizenCon, which was hypothermia and eating and drinking. And then since then, we did a force reaction update, which tied into that. And then now we're about to do actor status T1, which is the next extension. But if you were working in traditional game development, which is not as a live product, you'd probably do them all continuously. You wouldn't do a tier zero, two. You would make it in that manner and you would play it yourself to get an idea of, is this right? Does it feel good? And then work towards it. But obviously because we've got the PU and a live audience, we're able to leverage that community feedback and they go, okay, it's not working in these environments. It's not working well here. How do we do this? And generally a lot of the time on the core gameplay pillar, and again, this is the double-edged sword, is that we release a lot of features into the PU when they're ready to be used, but they're not necessarily fully integrated into the gameplay experience. So for example, melee combat or body dragging or trolleys. They're three really good ones that are fully functioning features. But if they were being used in an action adventure or Squadron or whatever, they would be integrated into, like, you're using them for a purpose. And we've released them into the wild to get feedback, but they've not been fully utilized yet. And generally that's because on the core gameplay pillar, we will work on a feature, and we work towards it becoming functional. And then once we have it, we will then coordinate with a content team. So generally, whether that's the locations team or UPR... so for example, healing needs hospitals, it needs medical beds. Or hacking's another good example: we can release hacking, but that's just the game, the system. We've done all the UI, all the audio, the physical interactions of you putting the hacking chip in. But it still needs to have a purpose in the game, like, well, where do you use it? When do you use it? It needs to have the chips in the shops. So we coordinate with what I call... we have feature teams, which is what my pillar is set up to. We also have the Weapon Content Team, which is a weapons pipeline that does all the weapons and stuff. But we coordinate with the general content team to then push it in or create missions. And so that's how we've always worked, and we would do the same and give it to the level... so the Squadron level design team, for example, is a content team. So we would be there at the top developing these features in coordination with the other leadership, and then we deliver it to the content teams to then execute into the individual projects. The way it works right now is that we would deliver it, maybe before the content teams will have access to it, and then they'll put a wrapper around it. But that's how it was previously. To be honest, it's unique in game development. It's not something that happens everywhere. I mean, it's something that's definitely new. I've only ever seen it at Cloud Imperium, but it's the nature of how we're developing all of these different projects.

So the biggest thing is how I discussed that. You have the feature team and you have the content teams. The biggest thing is that we wanted to create a closer relationship between the people who are making the features and the content, and especially considering I'm the arbiter, or I'm responsible for the FPS experience. So when we had discussions with Chris and talking about it, we wanted to create a closer relationship between the feature teams and the level designers, who are basically the people who are using... they're essentially the client who are utilizing these features. And with Nick, who's the current creative director on Squadron 42, Nick Elms... obviously Squadron's a big project, and because we've got such a good delineation between the FPS and the vehicle side of things, there were two things that we identified. One is that Nick could use some support so that he could really focus on the flight side of things, which is where all of his experience has been, so that he can really hone down on that and really work with John on the vehicle pillar and that side of things and push that forward. And on the actor side was that we wanted a closer relationship between the technical designers and the systems designers, because the technical side can help more on the technical side of things with implementing AI and so on and so forth. So there were lots of these different individual reasons, like a closer relationship with AI in terms of the technical implementation with the engineers, with the level designers, and bridging that gap, which is usually a traditional pipeline. It's just something that, the way the pillars are set up, it creates this two-step process. So that's where I came in to come over. So essentially all of the FPS level design teams and the social teams on Squadron, essentially anything related to do with the character gameplay, they're coming and being absorbed onto the core gameplay pillar. And that's why I said I'm still doing the core gameplay pillar director. That's still a role that I fulfill. I just have a superseding role that encompasses that plus the level design aspect. So that's where I'm coming on to help out on the game direction for the FPS side of things, and skipping a beat, because what would happen is we go, okay, this is a feature that we want to introduce, like trolley push-pull or whatever, or any of the weapons or armor or anything. Any of the other mechanics we want. And then there'll be a step of teaching that to the level designers and what they need to do. But now they're going to be part of that process, which is a more traditional way of doing it. Generally, you would sit down and you would work with the level designers and the system designers and the technical designers. They work together alongside the environment artists and the animators and so on. And they'd work together to create a thing. So for example, let's say I take body dragging. If we were going to make body dragging, generally what you do is you go, hey, we've got a level. It's a stealth level. We need to be able to hide the bodies so that other people don't see you. That's part of the mechanic. And we go, cool, we'll implement body dragging for that level and make it work. And so what we're going to do is start doing that process. So we're going to start implementing these features within Squadron, but still taking into account the PU considerations, because that's still part of my responsibilities. And then they will go to the content teams. But they'll hopefully be more proven and more executed, because we've already implemented them into actual real gameplay scenarios rather than test maps or testing out theories and so on and so forth.

Absolutely. I mean, to be honest, if you took Squadron 42, Squadron 42 is basically a giant mission inside Star Citizen. That's what it is. And the Star Citizen vision is that the flight and the FPS are supposed to be a cohesive experience. And right now in Star Citizen, we have the vehicles and we have the experience, but we don't have the combined experience yet. We have some of it. You can go and do some of the missions, like in the bunkers and so on and so forth, but it's short range combat. You don't have any mid to long range combat yet. We don't necessarily have AI on planets. These are things that are coming and that we're working on and actively working on. But we don't have them yet. Like the Ballista or the tank, they don't have a specific purpose right now. And that's because we're working towards... we're moving all the pieces in. And at the moment you're going, well, I can kind of think where we're going, but what is it yet? And that's where we're going, okay, no, we know what the end vision is. This is what Chris has been working towards. And that's what we're building. In Squadron, we know what the A to B is, because it's less sandbox orientated. And so we can prove out the mechanics in a much simpler fashion on Squadron and make them fit for purpose there, but they can still be accessible and utilized within the PU because they're exactly the same features. There's no change in what we're making, still making all the same things. Priority is still the same. It's just the way that we're going about it and the intentions and orientation, essentially.

Absolutely. I mean, to be honest, it's about greasing the wheels. We're removing bureaucracy, essentially. And I don't mean that in that the previous way was a bad way. More to just, it's like, how do we improve the communication, the flow of that information? With 700 people working on two projects, across five or six studios in terms of location, there's a significant undertaking in terms of making sure that the vision is clear, that the game we're making is made in a collaborative manner, not a designed-by-committee manner kind of thing. And I think there's a very distinct difference there, where it's not everybody voting, and then we're trying to make a singular vision, because that's how you achieve excellence. And that singular vision has to be unified across all of these people and all of these pillars and all of these different disciplines. And that's hard enough when it's just a 30-man team or a five-man team in one location. So when we're talking about how do we improve those communication channels? How do we improve the vision? Because obviously Squadron 42 is still Chris Roberts' vision. Star Citizen is still Chris Roberts' vision. They're still unified in the same plane. And the same information is still being distilled down to the directors and then onto the teams. It's just how are we smoothing that communication pipeline to the Squadron FPS team and having them be more integrated in. Like I said, it allows two things. It allows Nick to really focus on the flight side of things and just worry about that side of things. And then for me to go, okay, well, I know all the features and the mechanics that we're utilizing. These are things that we should be using. We've got multi-tool tractor beam. We've got cutting. We've got all of these different mechanics of body dragging and stealth gameplay and radar and scanning and physical damage and fire and all of those things. And you go, okay, well, this is what we can do. And it starts giving them the ingredients that the level designers can use. And obviously then me helping those guys and supporting them to make these fantastical levels that fit into this overarching game.

Yes, and that's something that I think is very... the way I put it is that the core gameplay pillar, because it's not just Actor Feature Team, the core gameplay pillar, which Actor Feature Team is probably the largest team on, was Squadron prioritized, but PU focused. And now we are Squadron prioritized and Squadron focused, and we will be focusing on delivering those features to Squadron 42, proving them out, rounding them out, and then giving them to the content teams, which we would have done previously on the PU, for them to implement those features into the PU, into the live release. Now, the significant difference here is the timeframe by which that happens, and something I alluded to at the start, which is the tiering. In standard game development, where you're not working on a live product, you don't generally tier. You make a feature that is fit for purpose. And if it does the thing that you want it to do, you test it and you play it and you go, that is what I believe it to be. I'm happy with it. And you then utilize that feature across multiple levels, and that's what you do. So what we're going to do, what the fundamental change here is, is that Actor Feature Team and core gameplay pillar are going to make a feature as we always have done, in the exact same timeframe with the roadmap that we've had for the last 12 months, right? Then instead of it coming to the PU and Squadron simultaneously, what it's going to do is that it's going to come to Squadron first. And in Squadron, we're going to implement it and deliver it to create a final unified experience for Squadron 42. So trolleys or body dragging would go to there, or melee combat would go to there, and we go, this is how we're going to use it in Squadron. This is how it's supposed to work. This is all of the things that we need it to... the player experience. We test it, we play it, go through its approval channels and get to a position where we're happy with it. And at that stage, we're going to go, hey, this feature is solid. It's got final art, final animations, final VFX. It's in really good shape. We will then ship it over to the PU. Now, that doesn't necessarily mean that the PU community can't go, oh, we want to give feedback on it or whatever. It's like, absolutely, because it's still going to have its implementation within Star Citizen, and it will have Star Citizen specific requirements. Now, we will have still developed them with Star Citizen in mind, as we've done ever since the core gameplay pillars existed. But it means that the features will be much more polished, much more well-rounded and probably be in a better state by the time that they get to the PU.

We're doing more. Or I'm doing more.

It's really a change in release strategy, I guess. Instead of popping out of Tier 0 into the PU, then a Tier 1 eventually, then a Tier 2 eventually, now you are going to focus on taking each feature, at least for the Actor Feature Team. And I want to stress right now that we are talking only for the Actor Feature Team here.

Well, we are talking the core gameplay [pillar]. So that is Actor Feature Team, Weapon Feature Team, Actor Tech Team, which is not really a feature team, and the Weapon Content Team. The one thing to note, I think, to discuss that is that we're talking high level here. So this is the general intention of what we're trying to achieve. But I do want to specify some nuances that may be apparent. So if you imagine, some features are what I call truly systemic features. So jumping. Jumping is a feature that Actor Feature Team owns and we did two iterations on. It works regardless of whether there's any content. Nobody needs to make a mission about jumping. We don't need to sell anything in shops. You don't need to buy it. It literally is your character can jump. Now, let's say we added another feature that is sliding, which is you sliding down mountains. Or force reactions or whatever. They are systems that require no content. Now, when I say content, they still have animations, but they don't require content teams to add them to the PU. So if we do anything like that for Squadron, so sliding is a good example, they will just be absorbed into the PU pretty much either at the same time or maybe a quarter later, because essentially they'll still need to be tested and go through QA and PTU and go through Evocati and so on and so forth. But fundamentally, you get those for free. Then there are features that are... so hacking, for example, requires missions and locations to be created to utilize those features. So in that scenario, core gameplay pillar would develop them alongside Squadron 42 level design teams, and we would execute that feature within Squadron 42. And then at the end, we'd go, hey, here's the feature. Here's all the examples we've been working on in Squadron 42. This is how we've used the mechanic. There's some good examples. Maybe you could take inspiration from that. And then the PU content teams, such as the PU mission teams and the PU level teams and the locations team, will be able to take them and then put them in the PU. And that's where you start to maybe get a one quarter or two quarter delay. Now, that's not delaying any of the work. It's still happening in the exact same time frame. The development is unchanging. All it's doing is when we're committing to actually being put into the Squadron release... oh, sorry, into the PU release. And fundamentally, this is something that I've been trying to address. And it's something that I called out as something to improve in the retrospectives, I think for both 3.13 and for 3.12, where I'd see a feature go live, like body dragging, and I'd see people in Evocati and on PTU utilizing them, but they don't really have any true purpose in the PU yet until we get round to adding some of those missions. So I think fundamentally it won't change anything in terms of the PU gameplay experience, but what it does do is that people who are looking at the roadmaps and the delivery maps might go, oh, this is coming later. It's not because it's being made later. It's just because we're proving it out. And when it does come, it should be a better experience, because we are no longer committing to PU releases. It's the PU content teams that are committing to the releases, and they're committing to adding a feature with the content, relevant content. So rather than body dragging coming in Q1, it might come in Q3 or Q2 or Q4, depending on how big the feature is or how much the content is, but it will come with the relevant content to support that feature. So it would be, hey, this is a mission where you've got to go get an injured person. You've got to body drag them back to your medical triage center. So it's the mentality of how we deliver the content and how we deliver these features to the audience.

Absolutely. Get there sooner is one of the main intentions.

The other effect of this is, because we are now taking these features beyond tier zero, we're taking them to T1, T2, T3, all the way to 100% and then handing them over to the PU, it means that situations like you explained with body dragging, where a T0 feature comes out and you're like, well, that's all right, but there's really nothing to do with it. Or here's some trolleys, like, well, that's all right, but I can't load and unload cargo with it, whatever. It means that when the features make their way to the Persistent Universe, they should be more complete. They should have more content with which they can interact and affect. It means a better experience for the PU overall when these features get added.

Exactly. And I think that basically hits the nail on the head. The one nuanced thing I want to make sure that everybody's aware of is that, depending on the scope of the feature... so for example, let's take actor status, because actor status is a really good example. Actor status is an absolutely monumental feature. It covers a huge range of statuses and healing gameplay and Death of a Spaceman and cybernetics, and there's a huge amount. Within there, we still may take a proportion of that and call that actor status T0, but we take all of that up to what we'd expect to be hopefully final and then move to the next one. So we still might have tiering, but not in the true agile development tiering sense. Generally, a tier zero is like what we talked about, body dragging, which is a very self-contained mechanic. That would be, we've released that, but we know that we want to do direct improvements to that. Whereas actor status T0... well, actor status T0 actually was hypothermia, eating and drinking. We don't want to make changes to those. We just want to add more stuff. So in this scenario, we're adding a T1. We're not going back and making those different or improving them, which is generally what you would do in agile development. This is we're adding more stuff. So now we're adding healing and we're adding injuries. And then T2 is like tiredness and hygiene and all the other stuff. So when somebody might say, oh, well, this is a tier zero, but we talked about having final features, there's a nuanced mechanic. And that's why I'm saying we're talking at a high level, as a global. There's always going to be exceptions to the rule. And there's always going to be scenarios where we are just using that terminology to make sense for the tracking. But really, you could call those totally different features, for example. You could call actor status a tier zero: that's hunger and thirst and temperature mechanics. And then T1 is, this is healing and injuries. They're totally separate. But just because we've called them actor status T0 and actor status T1... so it's a nuanced thing. But, yeah, the TL;DR is hopefully Squadron will come sooner and you'll get better features in the PU.

Well, technically, I'm going to make it a bit more complicated. But technically, it's getting faster. And what I mean by that is, while it's not getting necessarily faster in terms of the PU delivery, that should stay the same, because we're still making the same amount of features, still making the same content, still making the same stuff. But on Squadron, because we're making it and integrating it into Squadron as we make it, the iteration and the feedback loops and the communication, that will be gone. Rather than us going here, hand over to them, we'll be going in parallel. In terms of Squadron development, it should speed up. In terms of the PU development, it will be identical. So no change.

The development will be identical, but the release structure will be different.

Will be different, yes. And that's what we're talking about here, really. I mean, that's why we have a very open development with the community. We want to make sure that we're being honest and being transparent. And so the scenario is, if you look at all of the features on the... it's not called the roadmap, is it? It's called the feature tracker or something?

It's called the roadmap.

Well, isn't there a release roadmap and isn't there something else? There's like a feature tracker. The feature tracker for all the teams, that's staying the same.

There's the progress tracker and then there's the release view.

Yes. So the progress tracker, for example, no change. It's going to stay the same. Whereas the roadmap is going to change. The release view is going to change. And that will basically be the reality. So development doesn't change. The release strategy changes.

So on the release view, whereas you previously saw this feature tier zero would come out in this, now that's going to push back.

Correct.

And it will no longer be a tier zero. It'll now be closer to what we intend the feature to be when it's done. So that's the important distinction here. Why we're here today is to explain this difference. The progress tracker, the work continues apace. The work continues as it always has, but more focused and hopefully faster, because we don't have to do these little release steps along the way that slow things down. But the release view means that certain features, and you'll see this reflected on the roadmap the next time that they update the roadmap, I imagine, certain features will look like they go back a quarter. Some may go back two quarters. Some may go back further. No feature has the same development time. So it's going to be on a case by case basis. But the release of those features will change. And so when you see the roadmap get updated, if you look at it cursorily and without the context that we're trying to provide here today, it'll look like, oh, that just got delayed, or, oh, that got delayed and whatnot. And that's not really what we're talking about here. We're talking about a change to the philosophy in how we release these things, and wanting them to be, quite frankly, better than they have been. And that's really what this is about. It's about making the features better and more purposeful and more useful than we've been putting out into the PU in the past.

Exactly. And that's something we've identified for a while, and especially for me, because a lot of effort and time for the teams go into making these features, and blood, sweat and tears, and we want them to come out and be well received by the players, and that they enjoy them and they enhance the experience. So really we want them to be seen in the absolute best light. And this is allowing us to do that, so that we can release them. So you're like, cool, there's not just this new mechanic, but this new mechanic alongside all these new missions or all this new stuff. It actually has a use.

There's actually a reason to have body dragging. There's actually a reason to have carts.

I could keep going on, like weapon zeroing. Weapon zeroing allows you to automatically zero the scopes for your weapons. You can go up to do a kilometer shot. Other than PvP, you're going to a bunker mission. You don't need to zero your weapon shooting somebody from 10 meters away. But really, we would release weapon zeroing once we've released outposts and AI on planets, because then you're going and you're going, cool, I'm surveying this outpost, 1.5 kilometers away. I'm looking at all the guys. I'm like, okay, there's a sniper guy there. I'm going to go closer, take that guy out. And all of those mechanics make sense. I mean, that's the intention, and that's what we want to work towards, to have more of these well-rounded experiences.

Well, the biggest change obviously is inventory is now localized. So when you load up your PMA, essentially you have access to all of your equipment at any moment, anywhere in the universe. If you're on some random moon, you can load up your PMA and go, I want to change armor. I want to change weapons. I want to have access to grenades or med pens or whatever. If I'm in a location, I'm in New Babbage, I can access any ship I want, do whatever I need. Inventory now is going to be localized, so you will only have access to the things that you take with you. If a ship is at a location, it is at that location. If you want to fly that ship, you need to go to that location to fly it. If you want to use the Caldera environment suit because you're going to a cold environment, you better make sure that you take it with you along the way. So that's the big headline on inventory. It's becoming way more tactical.

There's now inventory tactics coming to Alpha 3.15.

And then the other side of the coin is death is going to become more meaningful, which is a step towards Death of a Spaceman. So when you die, you won't immediately die now. You'll go into a downed state or an incapacitated state, which will allow other people to bring you back. So if you're playing with friends, that's a really good... so if they fell off a cliff or they got shot or whatever, you'll be able to bring them back. And we're introducing an injury system where you can have basically semi-permanent injuries, where they are quite severe in some of the cases. So you might have broken legs or broken arms or traumatic head injury or so on and so forth. And they will have significant impacts on your gameplay. So like broken legs, you can't walk. But we will provide drugs and medical guns and medical attachments to the multi-tool that allow you to apply... and hospitals, that allow you to basically mask the symptoms of those drugs, so you can mask the pain for your broken legs so now you can walk again. But they don't cure you. The way that you cure yourself is going to a relevant medical facility, whether that's a ship that has a medical bed or a hospital or a rest stop that has a clinic. And those medical beds will allow you to basically remove those injuries.

It's definitely going to be a harder challenge. It's going to be a harder experience. Obviously, we're still in an alpha state, so there's going to be scenarios where bugs happen and things are going to feel unfair, and I totally appreciate that. But these are two huge mechanics that were headline features way back when: physical inventory and Death of a Spaceman. These are delivering those experiences, and the next steps will be then the true realization of Death of a Spaceman and the true realization of the physical [inventory]. But the gameplay loops are what we're delivering, and that's why it's going to be a monumental change. But I mean, I look at it this way: if I played any survival game, or Rust or Ark or any game in general, and I put god mode on or I can just access everything, or I played Witcher 3 and I had an infinite inventory, those things, while they make things easier for me, really they take away from the enjoyment of progressing and getting access to all the equipment and that sense of achievement that you've done something. And it starts to alleviate that. If in Minecraft, let's just say Minecraft, if I don't lose any of my gear, then death doesn't become... you don't get those sweaty palms when a creeper pops out at you and you're playing hardcore. Or you don't want to lose your netherite gear going into lava. You're precious about these things that you've invested a significant amount of time into. So when you do lose them, it's frustrating, but it adds to the challenge.

So radar and scanning is... so we were the team that worked on the ship radar and scanning. So the ship radar and scanning, alongside the Vehicle Tech Team, who delivered that core system. Essentially we were the design arbiters around it. And if you notice, a lot of the things under the hood are what we changed. So how the signatures work in terms of you being able to hide in the shadow of larger signatures and so on and so forth. So FPS is the extension. And this is why we did it, because we didn't want to create two systems that people have to learn that are totally different. We wanted a seamless experience of you doing a ping or doing a scan, getting out of your cockpit, and you still have that information and you can then continue to use it. So FPS radar and scanning is the realization of that mechanic, that you can ping out, detect contacts. The biggest thing about FPS radar and scanning compared to the ships' version is that we still use EM and IR signatures, but it uses dB, so sound, instead of cross-section. So in space, they use cross-section for line of sight. On the FPS, it uses sound, so it has the three signatures. We also have, you can scan, so you can scan ships, you can scan people and find all their information, whether it's a bounty target and so on and so forth. We're developing and working with the UI Feature Team to create the actual radar. So essentially the mini map, we'll have them in. And the one thing I would say about FPS radar and scanning is that it's not intended to just be an I-win button wall hack where you just... So when you do a ping, all of your signatures are going to flare. And if somebody else gets pinged, they know that you've been pinged, and they know where you are. So you've got to use it in a kind of way of, okay, I'm going to use it here, but to give myself a quick overview of what's there, if I think it's harmful, and then I'm going to retreat. Or if I'm on my own and I know there's five guys in that room, maybe you don't want to do that. So it's going to be a risk-reward of whether you pull that trigger. I don't think people are just going to be going around pinging everywhere because of the nature. You're giving away your location as well as receiving theirs. So there's going to be some nuance with that, but that gives you the highlights, should we say.

Yes. So the biggest thing about EVA is that we're eventually going to be introducing EVA fuel to EVA, so that it has a compressed inert gas that you use to utilize your EVA. We're turning it into a decoupled mode. So essentially you use your jets to go in a single direction, and then you don't have to press the controls anymore and you'll continue going in that direction. Rather than right now, you're like a ship: you push forward and you keep pushing forward and moving, and then you release and you stop. So we're turning it into a decoupled mode. Alongside adding in the fuel mechanic, or the inert gas that allows you to do that, we're going to be introducing what we call zero-G push-pull. So you'll be able to attach onto things and basically pull yourself on the outside of an 890 Jump, or climb on things. And essentially, EVA T2, which introduces decoupled and the fuel, and zero-G push-pull, and then the tractor beam, those three mechanics will create the traversal mechanics to create EVA traversal puzzles and EVA traversal missions.

Oh, PIE is player interaction experience. So player interaction experience in a nutshell is going to be introducing all of the new HUD to the PU. So that introduces all of the new... we started with the widgets in the bottom left-hand corner, so your health and your limb health and so on and so forth. We're going to be introducing the blood drug level in healing, which is part of healing, which you'll hear more about in the future. We're going to be doing the rest of the map... sorry, not the map, the rest of the HUD. And that will include things like hints. Your personal inner thought will no longer be a list of text. It will be a wheel. You'll get some quality of life features around inventory so you can swap things. So I've got a gun in my hands, I go to equip the other gun; if I've got two weapons already on my back, I'll get a wheel that I can automatically swap. So essentially that epic, which is player interaction experience, which is split between T0, T1, and T2, includes all of these things. It also includes lockers, physical lockers, so you can store your outfits and save them out. So it's a big improvement to the interaction in the world, of how you interact with things and how you use the... not your inner thought... how you use the player interaction system in the game.