Let's talk about how your team and its work had previously straddled the line between Star Citizen and Squadron 42.

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.