Star Citizen: Subscriber's Town Hall LIVE - Technical Content

Totally. Yep, done. Everybody's happy with the tools. They never need any more work. We never have to rework them. It's perfect on the first delivery. So next question.

Tools go through stages. You initially implement the tool and you do it in a way that it works. It can get the task done. Then once it's in there, you have to reevaluate a little bit and say, does this get the task done as quickly as we would like? Is the way that you interact with the tool as friendly as we'd like? Because usually when it first gets implemented, our tools are very complicated, which means using the tool is very complicated. And you want to simplify it as much as possible because that limits mistakes and also speeds up your workflow. So usually it goes through a couple passes. So I think probably the answer to that question is while they're implemented and somewhat working, they still need a lot of work. We use software that we're on version 11, 14, all these Adobe, Autodesk, all these programs are never quite finished, right? Because they could always be better.

And maybe, to use a term from Eric, to pontificate on the minutiae a little bit: there's a lot of, and I hate to overcomplicate this, but there's a lot of layers and a lot of tools that are involved. You can call a script that somebody writes for an artist within 3ds Max a tool. You can call the Sandbox Editor that we use a tool. You can call our copy build patcher setup a tool. So there's a lot of different layers of these tools. One of the things that we're working on even this month is structuring those tools teams a little more accurately to be fit for the purpose that we need them to be set up for. So a good example is we have a general tools team within the UK that's led by Martin Sr. And general tools are pretty much defined as anything that's outside of the editor. Then we have a Sandbox tools team that's led by Sascha Hoba in Frankfurt, and that's all the tools that happen within our editor interface. Like Planet Editor, like TrackView, like a lot of other things people have seen on various ATVs. Then we have another layer of this and that's the art and animation tools. So these are tools that we write on top of those DCC apps, so 3ds Max, Maya, MotionBuilder. And that's what a tech artist really usually spends a lot of his time on, is that sort of tool structure. What we're always trying to do is make an environment artist's workflow faster, better, things less prone to bugs, trying to automate it. Then the same thing goes for the animation tools. And so everyone's aware, we call them the technical animation team, but we've got a pretty big team, and that's led by Rob Howes out of Derby. So now I've just talked about three different studios completely, and you can imagine that there's a lot of communication back and forth. There's a lot of really early morning meetings to discuss this kind of stuff. So that gives you an idea of what that team looks like.

Now, where are we at in terms of tools? Just like you've seen with a lot of the gameplay systems, as that gameplay system comes online, you need to then either at the same time or shortly thereafter develop the tools related to said feature so you can implement and do the feature. So we put a huge onus and a big priority in the last year or two years, Forrest and I specifically focused on this, on the content creation tools that we had, because we knew when we were talking two years ago that the scale of this game is so immense that the amount of content we need to generate is to a degree that those tools need to be very powerful for the artist. Because again, we can't just do it in a standard AAA kind of setting where you make one character very specific. That is your hero character. Okay, cool. We're going to make 12 more of those and that's it. We're talking thousands of character assets already created, and a character asset is like a shirt or a pant or whatever. Then you've got the same complexity, if not more, on the environment side, then you've got more complexity within the ships. So we've got all those tools in shape, we've got our pipelines, we can do all this. Now, where's our bottlenecks? Where is all the time going? Because the only thing that a tech artist will think about after that pipeline works is how can I make that better? And every day, that's all we're thinking about: how can we make that better for the developers? How can we make that easier for the developers? But because we put such a huge focus on the content creation tools, I say this all the time, our ability to create content has far exceeded our ability to implement said content. And it's not a good thing necessarily, because what it can do is, okay, so we develop a lot of content, and again, the players aren't seeing a lot of the Squadron 42 kind of content yet, and that stuff has progressed very well. But because we've made so much stuff, it sits there unused for a month, two months, three months. And then what happens, and this is the really rough part, is a system will change under the hood. And it might change in a feature team in the UK, so I had no idea about it, Gaige had no idea about it, Forrest might not have known about it, and we're getting way better in terms of that communications structure, but what happens is, and I call it asset rot, basically a thing has sat there for so long that it starts to rot. Basically, there's bugs that get created after the fact, and that's just based on underlying changes. So the focus is moving towards: let's make sure that our tools for implementation and for all the designers match our rate and our ability to create this particular content.

What you're talking about here is a struggle that happens daily, not just for us. This is a standard game development thing.

Not even game development. I think this happens across anything that uses digital assets in some way. And it's this interdependency thing. The times that people get really angry is when they've made a super nice asset, like James Koo will finish off this gorgeous character and it'll sit there for about a month and then he'll come back to it, or what's worse is somebody else grabs it, puts it in game and says, oh, what is this? There's errors on it or whatever. Okay, I'm going to send this over to James, and then he gets some sort of email that says, oh, why is this? You said you were done with this thing. So it can create some friction. So we've really got to address that on a tools and developer workflow side. And this is a nonstop thing. We're never going to be done with the tools, and we have to be okay with that. But that also means that we have to very specifically prioritize certain things, and we prioritize it based on what the bottleneck is globally. So what is slowing this thing down? Is it slowed down at this step, at this step, at this step? Why do we have 30 assets sitting here and one asset sitting here? So I'm very much pontificating, but I do want to go a little bit further, because the tools thing is a real big focus for me personally right now, away from features, so much more on the tools. So we used to have a very solid mentality with what was CryEngine and is now Lumberyard, and Lumberyard has maintained this mentality of what you see is what you get. So a designer is working within a level. He does a thing. Sorry, I'm going to use your Red Bull cup for an example. So he places this cup on the table. Cool, great. Now he wants to actually test this and see how that actually worked out. Now, if he has to go through a whole bunch of, I've got to launch this app, I've got to set this CVar, I've got to do this thing, I've got to get 20 minutes through the level, and then I can see my cup placement, he is going to place it one time and never again. Even if it's not perfect, so it's like, actually, I wanted that cup on that paper. If I wanted to make that little move here and then go through 20 minutes, I'm just not going to do that. So what we're trying to improve is the what you see is what you get mentality. And sometimes that can be totally opposite of what would make sense for a system. So sometimes what makes sense for a system is that you're not updating everything in real time. You're going to bake it, basically. You're going to save it, you're going to export it, you're going to somehow lock it in. But the mentality of what you see is what you get is never be locked in, always be changeable. So there's a mentality that has to be addressed there. And I think with some tools that we've developed in the past, we have to not really rework the tool, but think of a different workflow for said tool. So a good example is Subsumption, and something we've been looking at is these GUIDs with object containers. And this is just a method of us identifying certain object containers, and then Subsumption uses a list of all of these things. The problem is, for a designer, if he makes a new object container, he can't manually go add this thing to the list, wait for a build to generate, and then see his new thing. That's the exact opposite of the what you see is what you get functionality. So that's a big drive on the tools front.

Well, originally, we spent some time getting some footage together for Chris. And by we, I mean QA was capturing, we had some developers in-house capturing. And then it came back, and then Chris asked me to take a pass at it, look at it, review it, and then revise it with some additional footage.

When you say capture footage, just so everybody knows, we're doing it the same way you guys do it. We load the game up, we open up OBS. When we record, we record using the same engine, the same game client our players are using.

In the past, the way the rendering worked a lot for the cutscenes, like in our original fundraiser trailer and then a lot of our commercials, so to speak, was we have a way to render out. We can set everything up in the editor, and then we run the game through the editor, which was the ultimate what you see is what you get from our engine. And then it would render that out into a video format, which would then upload to YouTube and then people would see. But we would do everything by hand. Let's say if I wanted to have a ship fly past, I would have to make a quick particle effect that I would attach to the thruster. And then in the software I'd have to say, okay, at this moment in time, I need to keyframe a boost to the thruster so it flares out, and everything was very manually done, like you were doing a movie type thing. And then our tools got more and more complex. Ships' landing gear started retracting automatically, and the tools started surpassing our cinematic methods, and it became very difficult to start doing these types of trailers and cutscenes. It really came down to, wait a minute, we were just showing off the art, but now we need to start showing off the gameplay mechanics along with the art. And so these cutscenes had evolved from just showing off art to showing off the game, right? Because everything's as important as the art. This was one of the first times that the goal was very clear: capture in the game. Chris was very clear, he wants in-game captures. So we started getting the footage back, and a lot of the footage was fairly rough right off the bat. And it was very clear, very early, why it was very rough, and that was because we have a very rudimentary tool, spectator cam, director cam, whatever you want to call it. So I was like, okay, well, let me give this thing a try. So I give it a try, I use it. Let's talk about the shortcuts of it. It's rough. I'm like, how do I move the camera? It's crazy. Hold F4, and then you literally have to put your elbow on a key to make sure you move it up and down, and then you need to put your thumb on the right joystick to rotate the camera. So I grew a third arm for a week and a half, and I randomly would have people come over and I'd say, I need you to hold this while I do this. And then some of the shots, I'm like, okay, well, I don't like the shot because it doesn't have camera movement, or I don't like the shot because it doesn't use any rule of thirds, or it doesn't do all these things, right? All with great potential, just not quite what Chris is used to on the cinematic front.

And all because it was very important for us to make the trailer in the game client, on the same game server as the player is playing, using the same tools the players have access to. Haskaha and Frostmaster and AlexS189 and all you guys out there, we wanted to do it the same way you guys were doing it.

So the trailer that you saw in 3.0 was the live product. A lot of people have asked, how did you get those frame rates? A lot of times I did log in when there weren't as many people on the server, right? Because they're making heavy server optimizations right now in regards to the fact that when you play and there's lots of people in the game, the server, the network code is doing lots of things and handling lots of things at once. And so they're making changes, saying, okay, if this character is on the planet, maybe don't update the skeleton, and stuff like that. So it's a very known thing right now, it's just part of game development and part of having an MMO that is now being targeted. However, there was the challenge of how am I going to get these frame rates? So I would log in at 2 o'clock in the morning and I would say, hey guys, who wants to play with me? And I would almost go undercover and I would record my experiences with players. And this is how I got them to play with me. I'd be like, hey, does anyone want to join me? And they'd be like, yeah, what ships do you have? I have all of them. Yeah, sure, all right.

He spawns a Bengal or whatever.

Yeah. And I would play with people, and also I'd get QA in-house to have Star Marine matches with me, and I essentially just learned the toolset, I did the best that I could, and I just played the game and I captured my experience playing the game. So now that we have the trailer, Chris is like, see, you can do this. And I'm like, well, you can, but I think I made it look a little easier than it really is, because it is difficult and it was a challenge, right? But part of my job is to just give him what he wants, get it approved and make it look easy doing it. So he was excited about it and said, I would like this to be revamped. I want this director's cam. I love the director's cam. We all know Chris has a background in film. He understands it, he loves it. And so we want to be able to bring this beautiful universe into cinematic mode, not just in Squadron 42 but also in the MMO PU, because who doesn't want to capture their experience? Because people are going to be making these types of movies. What is it called, when we were younger and we would make these things? Machinima. And that was fun back in the day, and people are probably still doing that, I'm just older now. But when I was a kid, I always loved doing that. And so I went back to my childhood and thought about what would be cool if I could do this with this. We decided we're going to make a tool. We decided we're going to take the current director's cam, spectator cam that everyone has access to currently, if you hold F4, rub your stomach and your head and push the keypad at the same time, freaking crazy, and then we're going to build upon it. And step one, I think, is to just capture something. So, okay, who's currently doing this now? Because I do believe that you don't just build a wheel from scratch. You have to look at what your competitors are doing, and then you have to see what they're doing well, what they're doing not so well, and then you basically evolve into a better, and it's not stealing, but you evolve and you always have to keep up with modern technology. That's just the way that it goes. You have to know what people around you are doing, because you have to make it that good and you have to make it even better. So I asked Sean and some people, specifically Sean, I said, hey, who else is doing this? Who's the best? And he goes, Mario Odyssey.

And I've been playing a lot of Mario Odyssey with my kids, and on my own at 3 a.m., getting the power moons. But on that point, the barrier to entry for Mario Odyssey, there's no barrier there to snapshot mode. And that's a nice tool. It's a player-facing tool, and that's what Forrest is looking at here. And it was funny to use that as a reference, especially sending it to Chris, where I never expected in my life to be sending Chris Roberts a screenshot of Mario with snapshot mode on and there he is with Cappy just hanging out in Cappy Land.

How did that go over? You sent Chris Roberts a screenshot of Super Mario?

You know what? He was like, no, that looks awesome, that's exactly what I want. So that's where we have to go, as well as NVIDIA Ansel was the other side of this. And the whole goal of this player-facing tool is to remove that barrier to entry and give them the same power that Ansel or a Mario snapshot mode, or even in Zelda you've got a bit of a picture mode, give you. Making it as accessible as those are, I think, is a very worthy endeavor.

Yeah. And that one, of course, the expectations of the customizer right out of the gate are pretty direct. And if you look again, to go to Forrest's point, looking at what everybody else is doing is a really important part of this. You look at games like Black Desert Online, or you look at games like Destiny, and everybody approaches them a little bit differently. And as we want to do this, very much out of the gate, we just want some form of customization. Just select a head, select some hair, select some eyes, and set the colors.

For the first part.

For the first part, then call that a day. But even at that, let's say, limited customization experience, you can still make mistakes on the way there. And some mistakes would be an interface that isn't as intuitive as you would like, even for that kind of thing, as well as making sure that whatever system is developed is a totally scalable thing. And as I talked about a little bit before, because of all the different studios and different levels of communication from various teams, it can happen that a thing will be developed and it's not exactly what Chris was expecting or Todd was expecting or I was expecting. So basically it's gone to a full feature team now, which is a cross-discipline team of programmers and UI engineers and artists and everybody all together working on that. So they're progressing pretty nicely on it. But what's interesting is Gaige had already done the entirety of the asset setup months ago. I had done a show a little while ago, we do a lot of shows, and we had talked about that coming out very soon, and it was definitely a goal for 3.0, but it wasn't where we wanted it. And not, again, because the actual assets and things weren't ready. It was more the interface just wasn't where we're demanding the interface has to be for doing that. But yeah, Gaige, back in, I think it was October or November, really went through them all.

Actually, it's interesting about the customizer too, because we've always had our own version within the office called the Loadout Editor. But it's just not something that you'd want to give to people, because it's not a very friendly interface at all. So the hardest part was making it a nice interface for the user while also accommodating scalability for the massive amount of assets that we have. Because we have it on our end, but it's very difficult, and we build onto it constantly. So just dishing that out wouldn't be great early on. Like I said, didn't want to rush it. But an interesting part about that is it comes in a few stages. We always have our first step of character artists. They make everything on their end in models. Then we have our implementation phase, which we've been doing in the back end for a long time now. And then there's the UI phase.

UI is always there at the end.

Yeah, and it's one of those things, because it's the visual element, it's something that is very picked on. So it goes through a lot of stages.

It just won't be sculpting, that's the thing. It won't have the DNA.

We're talking about the first version.

Yes. I've talked about it before, but there's complexities because of the rig logic and because of things like we want to drive the face with Faceware, we'd like animation shared. And then even further, we want to be able to update the runtime rig code implementation, DNA as it's called, at runtime and be able to save this for your given character. So there's a lot of reasons why it's not just as simple as putting a couple blend shapes in and going between them. Because we could absolutely do this, but it's actually not going to get us to where we want to go with this system. So you're going to have head selection, you're going to have hair selection, and you're going to have eye selection, and colors between the hair and eyes. And I mean, we're even beating to death some things like, okay, the workflow right now is that we're going to have to have images for each of the hair, but is that really the scalable way to go? Shouldn't we do a render-to-texture sort of thing of the hair asset? And then, oh wait, hair assets don't render super well in a render-to-texture kind of setting, so how do we set that up? There's minutiae in here that has to be addressed. So that's why it's getting addressed on the feature team. But again, to go to Gaige, he's already set up all these assets like this, because we had to support this for Squadron 42. We had to support this for the PU and for all the designers, because we've got that design-facing tool, a Loadout Editor, because that's how they make all the NPCs.

Yeah, so technically we've had customization for at least two years now, just in different phases. What's cool about the phases too is, with our back-end setup and our internal Loadout Editor, we have all these dynamic tag setups so that when you switch a head, it'll switch the body color and it'll find all the appropriate items to fit this character. That's why we can have all these modular setups, as they all dynamically switch to each other and piece it together based on how we set it up internally.

Right. One of the interesting challenges, even for Squadron, and we can talk about how we solved it for the PU as well: in Squadron, for example, all the heads, they've got different size necks. And I think in an ATV we're going to talk about how we actually scaled that to Gaka. He's one of the cool characters within Squadron 42.

Like six feet tall or something?

Yeah, six-six or something like this, really big. Where we were going with that was the necks were actually different sizes between the heads. And this totally makes sense, right? Because a human is just different proportions. But the problem is when you have a modular system and a shirt, the shirt doesn't just stretch. It just doesn't move for it. And then you can't use the same shirt across a bunch of different guys. So that's why we came up with this tag system, so that the tier one and tier zero, really high-end actors, get custom clothes that fit them specifically. And this is going to be the case for... actually, I'm not even sure we've talked about this character, so I probably shouldn't. It's a very specific character. Nope, I can't. Won't do it. But whoever they are, they're custom. But how we solved this in the PU was actually we unified the neck shapes right down. There was a range of verts that we actually unified.

It was a longstanding discussion too. It was a big decision to start unifying things, because you start to lose some character when you unify or standardize anything. That's the trouble we've had with clothing too. You can't standardize so much that everything looks the same. So of course, did we want to standardize skulls and head shapes and necks, and how similar would everyone start to look after that?

We wanted to put the ears in the same position. There's so much detail.

So they started testing them. Vineet in the UK did some tests to figure out how far we can blend before we start to lose the character of this person. And then once we finally decided, we made that the new standard, and then all clothing up to that point on the neck would then fit the same size, and then they can do whatever they want up here.

I mean, we literally would just walk behind his desk and Gaige would be like, does this look weird? And if it jumped at you, like, this is now a different character, then we've gone too far, right? Because you've got to shape the skull, because you've got a hat you've got to put on, and some people just have giant heads.

You don't think about it, but if a hat is stretched to fit people's heads, you can't just shove the same thing on there. It doesn't work.

And to talk a tiny bit more about it, there's a lot of logic in each of these items, like he said. The head carries logic with it, because there's components on that gameplay entity class of that given head that trigger a bunch of other things on the body. So that's where the complexity comes in. And again, sometimes I get jealous of other games, because it's a difficult thing to have a system that does everything. You usually can make a system and make some concessions based on your gameplay design. If you're making an MMO, you're going to make different concessions than if you're making a single-player scripted experience. So now you see my problem. Because we need a system that, one, has to coexist, so they coexist together, and two, has to do everything.

I see a lot of questions coming in about recent comments as far as the insurance system, and pirated ships and spawning and whatnot. This is a good time to say that we're going to have more information on that on Friday's Reverse the Verse, so you're going to want to tune into that. We have Todd Papy and Brian Chambers, who are our guests on Reverse the Verse Friday, and we're going to talk all about our future plans for piracy and stuff like that. But I can tell you now that the comments that you saw on Spectrum are very much speaking in the same regard. Will Maiden was speaking about current implementations of insurance and how stolen ships work in 3.0, in 3.1, in 3.2, but not the long-term design of the system. There have not been any changes to the long-term design that we're aware of at this point, and we will ask Todd Papy to clarify that on Friday. That whole thing with the piracy and the insurance, he's talking about how it is in 3.0 and 3.1. And it's a follow-up to the conversation we had on another Subscriber's Town Hall back in November, where we perhaps made it a little more clear then that we were talking about 3.0, 3.1, 3.2 and not the long-term design.

It's currently on hold while those people have been moved over to do other work. So I don't know that we actually have an answer for that at the moment.

No, we haven't come up with a solution yet. But it's not because there isn't one. It's because we're not working on it. That's kind of it. And a lot of this is sitting in Frankfurt on the physics engineers for the physics system itself, because there's a couple different issues with the whole thing. But one of them is, yes, animated physics, the thing needs to change. And again, this goes into those what you see is what you get kind of functionality stuff. The system that we currently use, which is being re-engineered anyways, is a pretty static system. So you make it, that's it, that's what the physical grid is, and it ain't changing. Regardless of how that ship breaks up or whatever, we can turn it on and off, but we can't move it around. It's kind of a fundamental thing within the engine and within Lumberyard that there's a concept of areas versus entities, and an area is not an entity, and thus you can't do the same stuff with an area volume that you could do with an entity, just from the code side. Everybody knows that. Physics grid is one example of an area; another example would be a vis area, these things that we battle with, vis areas and portals. So this is what calls out certain regions or areas. And the difficulty that comes sometimes with those is, yeah, those don't animate either. So anytime we want to really change that ship around, even in destruction, it absolutely comes up. And then some other problems with the Hull C: I think somebody had done just a quick setup with, it was like 50 Hornets or something attached to it. And I don't think this is what you're going to be able to do by any stretch. But just to give you an idea of the performance implications that that brings, the fact that a ship can be strapped with that much stuff is a performance concern on the GPU, not so much on the CPU, but GPU, and that's where we get worried about it. So there'll be some things we need to solve there, but none of them are insurmountable, as nothing is. It's just a matter of time and money.

I sort of talked about it a little bit with the tool structures and the mentality of moving around backlogs. If you really want to get into the details of it, right now, I was joking with Forrest about it, but I'm spending a lot of my time in Outlook at this exact moment, which is obviously not where I want to be, but where it needs to be. Communication. I can't complain about that at all. But I, of course, miss having the editor open and actually solving some problems directly. But you've got to have a bit of this production work to get everything going. So, yeah, just working with the various tools teams on getting them prioritized for the year and making sure that we're supporting all those feature teams.

What are you working on, Gaige?

On my end, really just tools development for the character side in Maya. This is a lot of working with Red9 and the UK team, Rob Howes over in the UK, communicating with them. We're building tools here that will then sync their tools, implement their health tests, and this will just help streamline our whole character process. So we can distribute these to the character team themselves. They can create their models and everything, run health tests, make sure it's all good to go. It'll automatically hand off to us, and we can run our pipe very smoothly once this is finished, and then into implementation. And hopefully, like we said before, implementation can be the hardest part, smoothing out this whole process and just delivering it in one go.

It's coming along. It's coming along good. Next question. I know, I'm always trying to shut it down. I shut it down, and then I make it take 20 minutes. So, yeah, Faceware, we took it super far. Was it Gamescom we first showed it, I think? Then we had a setup at CitizenCon showing it running in real time. There's some performance stuff that we want to address, and especially in the state that we are right now, I don't think anybody would accept me dropping Faceware as a feature to sap any performance right now. I assume most of the players would not want us to drop that in if it had any adverse effect on the performance, so we're trying to completely address that out of the gate. And just so everyone's aware, there wasn't a massive team working on the Faceware implementation. It was really down to just two or three people. And it's Graham Philipson over in the UK, as well as some of our QA staff and a bit of design. So we've got the feature online. It's in the game. It's not in the PU as it ships. It's all shut down and turned off, but we're ready to go. There's a couple of things left. A good front end for the players, basically, because we have a lot of tools that are just sitting there in console variables with different tweaks and these kinds of things. So with the new mentality of our team structures internally and these cross-discipline teams, FOIP as a feature will go to one of these cross-discipline teams. Now, most of the heavy lifting, I would say, is done. So the only things that they really have to do is to wrap an interface around it. So whether that's a Spectrum overlay or whether that's an options menu within there so that you can tune different things. I really wanted to put it in the character creator, because I think that that'll be a really exciting thing, to be able to drive your character as you sculpt and customize. But I don't think the versions are going to line up in terms of when that one comes out. So they'll have to get an interface on it, a bunch of different options. Design will need to take a look at it just to see, again, how does this interface with, I forget what we're calling it, but when we do a video comm to a player, when you call each other, how that whole party structure works out. So it as a feature is ready, but like we said, it's kind of suffering in the same way of asset rot, where it's not rotting as a feature necessarily, but it's not gotten much further progress in terms of its implementation. But the feature itself is still getting work, Graham is still making changes to the way that it actually works. But yeah, it should be coming along shortly. And I'm not even sure if it's on the roadmap, but it will appear.

Once that team is 100%. Yeah, it's not currently on the roadmap right now because, like I said, a lot of the folks that are necessary to implement it into the game have other tasks ahead of it. So at this point, we can't accurately predict what quarter it would be. So we're holding off on that, just like the Hull C. People knew that we were working on the Hull C. We've been showing the Hull C in ATV for a while, but it wasn't on the roadmap. And it's because it's got a pin in it right now. It's like, we've got it to this point, now we have an implementation issue that we need to work with. We can use those guys on other things that are more valuable to the Persistent Universe right now. Because honestly, if we could put the Hull C in the Persistent Universe in 3.1, what would it really do at this point? You still need to be able to offload and load up cargo to it. The other game systems that are necessary for it to really function in the PU still haven't come online yet. So it's one of those things you can stick a pin in and put people on more pressing things. And that's what the implementation on the Faceware is. You need those guys to do that, but there are other things right now.

And I would argue that in the past, we've driven out features in that way where it really wasn't as ready as I would consider. And yes, we're an alpha, totally understood. And I know the community defends us all the time: it's an alpha, it's an alpha, it's an alpha. But we're not, I guess, judged as an alpha. We're judged as a live, released, fully commercial product. So with that mentality in mind, we got a little more careful of how we release these features. So it's cool that we get the features out to you guys. I've talked about this before, the layer between the developer and the community is so thin at CIG, it is so close, that you could work on something a week away from a player actually experiencing it, and that's scary. For a developer, that's super scary, because usually we're offline for years at a time, working with our own feature, using it, doing things with it, finding issues with it. And then when it goes out, you're pretty sure that things are going to be okay. But again, our layer is just so thin here. Our layer is about 24 hours.

It can be.

It can be. I've done a thing, and then 24 hours later, it's absolutely in your hands. It happened recently, actually. A couple items we were working on, and I was like, okay, tomorrow this is in. And actually, I had seen something online, so I'll address it anyways a little bit, because the monocle showed up in the patch notes. And now, is that the biggest feature? Hell no. Is it super important? Not incredibly. But we had worked on this thing six months ago, and it hadn't yet gotten its way in, because we knew for sure the concierge were going to have this. So we saw that rolling out and we're like, what happened here? It just hadn't gotten all the way through the implementation portion. So it was like a 10-minute job, really. A couple clicks and there it is, it's ready to go. So we made sure that that got in. Now, I fully did not expect to see that in the patch notes, that it was just added, but that's how those things happen. But there's the monocle.

Well, the monocle, it's not in 3.0. 3.0.1 is what we're shooting for right now.