Dennis Crow

So production is different on every project. And you'd expect that, because the original question is, what is production? And production is about getting something out. It's about making the product. So you can have artists and engineers and designers working together. And the artist's job is to make amazing art. The designer's job is to create really great experiences. And the programmer's job is to enable it technically to work. But the producer's job is to literally make a product. It's in the word, right? So since every game is different and every movie is different and, Dr. Dre is a producer, right? So basically they take the art and they take the hard work and the team on what they do and then make it into a product. So it is different everywhere. And it's certainly different here. And I think that's actually what I kind of love about it, because every producer can learn from everyone else. We deal with people, which are super interesting. We deal with complex projects that are never the same, which is interesting. So for me, the producer's job is to take the idea that we want to make and bring it through years of hard work from people and have something in the end that resembles what you intended to make at the beginning, or is even better. Find the fun, get it out. So yeah, producers' jobs are hard. It's whatever it takes. It's different on every project, but I wouldn't have it any other way. That's why we're here, because it's interesting.

We've done a couple of these, I think, over the years, and the answer hasn't changed in that it's a mix of project management and, like Dennis says, getting the product out and getting it done, or getting it to a place that's playable, or again, whatever entertainment you're creating. And then people management, right, working with people. It's the people that are making all these products. There's not a machine out there churning all this great creative content out. Not yet. It'll come, and I'm sure some people have figured it out with AI. Right now, it's still people making this, and it's people that make up Star Citizen, it's people that make up Cloud Imperium Games, and those people are what we like to work closely with and help them do the best thing they can possibly do in confines that are as successful as they can be.

Again, the producer does what you've got to do, right? And every project's different. So if you've got a project where you need to create a certain level, let's say that you wanted to create a level of a game, you need to have a lot of people do their work and then bring it together for a project. So you're starting with an idea or with a concept or something that people want, and you sit in a room, get up on the whiteboard, and "wouldn't it be cool if", and you've also been up on the board. And then there's a whole bunch of work that needs to get done to make that "wouldn't it be cool if" happen. You've got to have features written on that, right? So you've got to figure out, okay, wouldn't it be cool if this happened? What are all the features we need to drive that? Okay, so these features are going to have to be given to designers and programmers and artists and QA testers to be able to work together and get out, right? So that's one thing you've got to do, is shepherd it through that process while still keeping the soul and figuring out implementation as you go along. But you may also need to create cinematics or art or a character or a ship. And that's not really feature development. That's almost like an assembly line. That's almost like a group of people who know about an art pipeline and can manage that. So that takes a different skill to get through there, because you're talking to different people and dealing with different issues there. So then you also have this thing in a game, which makes it so much fun, which is you've got the technical side. Yeah, we're art. Yeah, we're design, but we're also technical. So we've also got to figure out technical solutions in terms of the code and the graphics and the performance and the optimizations, all of these things. And those are purely engineering challenges and tooling challenges. So a producer who just goes around and just checks off the list, maybe sometimes the list needs to be checked off, but in reality, they're taking that "wouldn't it be cool if", and then saying, okay, in order to make this happen, what do we need to get done? How do we coordinate all these people together? So at the end, when everyone's delivering it together, it has some resemblance to what that whiteboard said that many months ago. Some resemblance.

For me, I've always had a creative bone since I was a kid. And the story I always tell is, Eric the artist hasn't finished a product in 10, 15 years, but Eric the producer has gotten a lot more done. So for me, it's working around creative people coming up with interesting, exciting final products and helping shepherd them and work alongside them to get it out into people's hands in whatever fashion that is, whether it's books or websites or whatever. Whatever it is that's there to engage people and to potentially entertain them or educate them. So I think I originally got into it because it allowed me to work alongside people and also work in a creative environment that got something exciting out in the hands of people to also enjoy it. And in our case, give us feedback and work closely with us. But it's a cool way to work with creative people and help them understand what it would take to get something done, and kind of play both sides of it. You want your creative people to be very creative and shoot for the moon and blue sky and always go over the top, right? And then we can come and go, okay, well, this is what we could do. This is how we could do it. This is how we could get there. This is what the next steps would be. Maybe we tear it up. Maybe we get out the first version. Maybe we get out the final version. All kinds of fun ways to work with people that are creative. But it started for me being creative and understanding that process, no matter what it was, to then move into working alongside people.

Personally, I got into games, obviously, I started my first job in games at 21. So basically, I think when I got in the industry, like a lot of people, we wanted to be the game designer, because that was like the sexy position. Everybody knows the game designers, right? Everybody knows Miyamoto, everybody knows Sid Meier. And we think, that's the job I want. The game designer is the best job. Then, actually working on some games, you realize that it's not actually how it works. The design is certainly a really critical part of it, but the game is figured out while it's being made. There's an expression that we're trying to find the fun, right? And that's something where you can have the best idea in the world. You can have something that just looks so cool on paper. And then really when you start building it and you start making it real, that's when you find the fun. And so for me, I love games and I wanted to make games. I felt that a producer got to be there throughout the entire process. The producer got to have the fun in the design process. The producer got to work out those technical challenges with the engineers. And the engineers sometimes surprise you and say, yeah, the thing you thought wasn't possible, well, it is possible. And now you need to change your design because it can get even better. Or an artist will just blow your mind on something. And what I like about it is, as a producer, we go where we're needed. We go wherever it's needed to make this game the best it can be. And then we get to stay with it even after it's released and get the feedback and say, okay, we put this thing out. We were really proud of it. Blood, sweat, and tears, all the cliches. But whenever it gets out in the community, you start seeing how people react to it. And then it kind of becomes the community's game, because shortly after, everybody on the stream right now knows that, generally speaking, the players know it better than the developers after about two weeks. So the producer, though, gets to stick with that and say, okay, we've gotten all this feedback. Let's pick some things that we can do that we can be successful at, because we can't pick everything and be successful. But the producer gets to be there the whole process. And it's fun to make the whole game, not just fun to make a game design document, in my view.

I think we should clarify, it's not a reorg or a restructure. Those generally have negative connotations, so I want to make sure that's clear. That's not at all what happened. It was more of a look at the strengths of what we've been doing for the last couple of years. As we scaled up in certain departments and as we brought in certain talent, it was now about going, what could we divide this into that makes sense to make this go to the next stage? And Crow could talk even more to this, Dennis Crowe. I tend to call him Crow. We have a couple of Dennises, so Crow. What needs to be based around the features to allow for faster iteration, and what needs to be based around pipelines? And I think Dennis can even speak more to that. But this was building on last year. We had already done some of this at the same time last year, of going, let's get people into strike teams or into goal teams. There's always various production-y words to use for this same idea. Get people together, let them work together, work quicker. And as the team has shifted and the responsibilities kind of ebb and flow as we bring in talent in certain areas or in certain teams, we have to constantly evaluate this stuff to make sure it works well. There's a human element that I was mentioning at the beginning of this: these are humans making this stuff. And the more we work together, the more we work alongside each other, the more we know each other's strengths and weaknesses. I've mentioned this multiple times when you're forming any kind of team, we're in this phase now, performing. We know what people can do. We don't question where that information should go or what part of the team should work on it. Now it's about doing it, getting it done, iterating quickly on it. We do it often, but I'm sure next year we'll go through that again based on what we learned this year. And as the product evolves, and as we get more out and we're working really closely with the community and they got more content with 3.0, it was a big one for us to go, look at all this content and how it all came together, what's the next step for us. A lot of the R&D we've been doing, which is really what a lot of that stuff is that people are playing, is R&D. If this was any other game, people wouldn't be playing that stuff. That would be just us going, oh cool, this looks really fun, okay, but don't tell anybody yet, but look how fun this is, okay, there's a lot of broken stuff. And so we get to R&D alongside the community. It's really unique. It's a live game, but we're learning alongside them, for sure.

Just to echo that, I would agree. I think one of the things that we would probably want to say, though, is it's not necessarily a production change. It's a development change, really. And again, it was not necessarily a reorg. What it is, is understanding where we're at in development and fitting how we work to the work we need to do. So it's not about, we have these ideas of how we want to make our game. It's, here's right now where the game is at. This is what's working really well. This is all the research that we did and the experimentation that we did and all the things that we have made and shipped. We've learned a lot. The project's in a different stage. And so when the project's in a different stage, you should say, okay, are there things that we can do now that more match what we're ready to do? We know how to make a ship. We know how to make these characters. We know how to make cinematics. We know how to make these features. So now that we know that, we don't have to be in the experimental phase that was required. To make something new, there's no roadmap. There's no manual for how to make this game, right? So we had to figure that out. We had to research that, come up with all these ideas, try out things. Try things, and then you get a result, and that's not what you expected. So try something else, okay, that's a little bit closer. So now that we've tried a bunch of things and we kind of know what works and what doesn't, and now we have a base of knowledge and we have a great tool set, we have a great engine and all these types of things, the project's just in a different phase where it's, okay, now we know the features we need, so we need to reorganize how we develop. We need to have people work more closely together. On this half of the room, you guys can huddle up and go do features. Let's organize into some groups so you guys can kind of work together and just go hit these features up. The guys over here, you guys need to be producing a ton of exceptional quality content. And you need to be doing it in a very streamlined way where everybody knows what's going on. Everybody can see what's going on. And then the guys over here: we know what features we want. We know what content we want. We have a tremendous amount of it already made. So now what we need to do is evolve our tools to support all that. So you couldn't have done all this in those three groups, in terms of what each person needs to do, until you had done the research. Because if you just come up with that piece of paper and you say, we're going to execute this piece of paper, so let's just all go do it, well, now we're following a plan. And the idea of Star Citizen or any great game is not how closely can you follow the plan. The plan is the start. It's about making a good game and learning and adapting as you go. This is an adaptation as we go.

Every time I mention the name, they send me a check. So keep doing that. That's why I came here. No, it's good. But basically, here's what it's all about. Again, it's about matching what we need to do with how we're going to do it. You use a hammer on a nail, right? So we have these features that we want to build. So whether it's the character customizer, or whether it's the service beacon, the distress signaling, or whether it's improvements we want to make to the PMA, or any number of features, and people know them, we put them live. Those features, we generally know what they are, but we don't know if that's a month of work and then it'll be fun, or if it's six weeks of work and then it'll be fun, or seven weeks. It's really hard to schedule fun. So what we say is, let's get a group of people together who know it. Let's give them two weeks to go run off and do stuff and try it out. And then at the end of two weeks, they have to show us what they've done. Chris is in the room. We have these great meetings where every Scrum team meets with him and talks about their feature and shows it, and all the directors are there. So basically, we can't schedule when it's going to be fun, but we know the more cracks we get at it, the closer we'll get, and it'll become fun over time. And then any team can only ever really get two weeks. If someone doesn't have the greatest idea, not all of our ideas are great. They're trying something and they get a result and it's not exactly what fits with the game, whatever. They tried something, and that's good, and they're pushing. Then we can bring them back every two weeks. So really, for feature development, we don't know exactly how to make it. So that's what Scrum's about. It's getting a small group of people together, a couple programmers, a designer, a dedicated tester, an artist, if they need an audio guy, bringing them in, letting them go for two weeks, operate maybe a little bit like a startup. So maybe like old days LA, right? Make a whole bunch of old days LA, little tiny teams. And let them go for a couple weeks, bring them together. When we began this, we didn't know if character customizer was going to take three sprints. And again, sprints are two weeks each. So we didn't know if it was going to be six weeks or if it was going to be eight weeks. What we did know is if we gave them a quarter to do it in, and this comes back to our quarterly schedules, that we would be better each iteration on it. By the end of that, we would have something that we would feel pretty good about. And so in terms of matching the development that makes sense for our features, it makes a ton of sense. We get things out to the community. So that seemed to fit this stage of the project. It also seemed to fit the culture of this company, which I'm learning about and I love. It's a band of pirates and it's fantastic. But the other thing is, and I'm going to throw out a number here, this number's not exactly correct: if we've got to make 200 characters, and let's say we're halfway done with them, but we've got to make a huge amount of characters, well, we wouldn't ask them to work in two-week increments. It could be really hard to write up a narrative bio of a character, figure out the gameplay design of it, and then get a concept, and then model it, and then rig it, and then set it up, and then go get the animation done, then go get the AI done, then go implement it in game. You can't do that in two weeks. There's no way you could fit that. So it's not about, oh, Scrum is great, it's a buzzy word, let's use it for them too. No, they actually all know what they need to do. What they need is the time and context. So what they need to do is say, we're going to be working on these characters in priority order. And we're all going to work on them. And we're all going to be the same team. We're all going to be thinking about the same list of characters that we need to put out this year. And we're all going to basically work more together. We're going to work on unified priorities. I always make fun of it, it's almost like a Chipotle burrito line, where people go step by step through it. But what's great about that is it's super clear what goes on. And also, you get your burrito faster than if you had to wait for someone to take your order. That kind of style fits that kind of work. And then when you go to your departments who are making tech, that's a different style of work. So what we've done this year is said, just like those Scrum teams, the more cracks we have at it, the more iterations that we have, the better we'll be. It's like anything else. The more times you practice something, the better you'll be at it. So last year, we had a lot of stuff we were researching, a lot of things we were trying, a lot of things that we wanted to do. And so we said, okay, here's a big group of work we want to get done. And we went through and we got that work done, and we got a result out of it, which was a whole lot of really great features, but it was really hard to estimate. And it ended up, we got the work done, but since you can't schedule fun, basically we came in at the end of last year. This year, we said it would be more effective because we'd get more iterations in. Imagine if we had four releases in the same time period as one. Now, all of a sudden, we're doing four experiments instead of one, or four practices instead of one. And we time box it instead. And we say, whatever we can get done in this time period, we're going to send out. And then we're going to do it again. And then we'll send it out. And perhaps the first one or the second one, we're going to learn things. We're maybe not going to get everything done that we thought we would. We'll get more done in some areas and less in others. But we'll learn each time. The community will learn, and you guys out there will learn it also: what does it mean to basically say, oh, we're going to have these regular releases coming out, and some things won't be done. Some things will be farther than we ever thought they could be, because we'll have learned. But really what it is, is we know the more cracks we have at it, the more times we can send things out, the better. And so in order to enable that, in order to be able to release things four times a year, we had to really say, okay, we've got to shrink everything that we did, from "I have an idea on the whiteboard" to "it's in the game and working". We had to shrink that down basically from a whole year into a quarter. And in order to do that, we had to break the features up smaller. In order to do that, we have to find ways to work better together, which goes back to the new tooling and kind of the Scrum and Agile, and these are some of the things we can get into for sure. Basically, everything that we're doing is to make the game better. The more cracks we have at it, the more iterations, that'll make the game better. We'll find the fun sooner. And in order to make these quarterly releases worthwhile, we need to make sure that they're an asset to the team and the team's working in a great way. But it's going to be really interesting. I'm excited that we'll be releasing on time, which is a really great thing. And we're going to learn a lot, and I'm curious to see what people think about it. But I think overall it would be a positive.

And to be clear, last year all the stuff we were sharing was really what was going on as well. We weren't like, well, let's just say this. It was like, here's what we're planning, here's what the team's trying to achieve. So last year was the same thing, but go ahead.

It's funny that we talked about the production summit before. That's where we built it. Obviously we talked to Chris and Erin, talked to a whole bunch of, everybody. Carl, Sandi, everybody. And we said, we want to put this out there. We want to figure out a way to do it. How do we make that happen? And it was funny, because it's a hard thing, because actually I've never seen a AAA, or quadruple-A almost, game do anything like that. And then we put it out, and a couple other games have followed, but theirs isn't live. What I can tell you is, when we were in the production summit in Wilmslow in the UK, we kind of were forced into having live data, because there was no other way to make that. We couldn't have done that other than saying, okay, we have to put a live schedule out. And so what we did is say, okay, what are all the features in development? And let's get them up on screen and put them into columns. And like, wow, okay, is that possible? It might be possible. And then, this is exactly it, we went feature by feature and said, okay, how many tasks are here? What does it look like? Okay, if those guys didn't work on anything else, they could get that done. If they were never blocked, they could get that done. And then we went to the next one. Okay, well, these guys had to work on that, and if they were never blocked, they could get that done. And we went piece by piece. And in some areas, we were probably pretty aggressive in what we could get done. In other areas, I'd say we were pretty conservative. We said, we want time to polish. We want time to make it right. There are things on there that definitely are really exciting. I'm not going to say they're stretch goals; I think we will hit them, or they wouldn't be on there. But essentially, the only way to make that was to say, okay, what's in progress now? What are things that we know need to come next? What are things that are dependent upon each other? And let's get it up on screen. Let's see how many tasks and stuff are remaining. Then let's call people in and say, hey, is this everything? And then, no, we added more things to it. And very quickly over that week, it only took about three or four days to build. Obviously Turbulent was great. But to actually build that into our project management to actually power that, three or four days we had it. And then we were like, can we really get this done? But looking at it, if that group of people could focus on that goal, yeah, they could do it. But it would require production making sure they could stay focused. It would require us to make sure that they didn't get blocked, that they had regular reviews from all the art directors, tech directors, Chris. But if they got all that support, they could get it done. But then it was on us to make sure that they could get that support. And that was what we needed to do at that stage of the project. And that's why we had to get into Scrums. So we had a problem and the tool fit the problem. So really it was built over three or four days. We kind of update it. We have this little checklist that goes around. We update it on Wednesdays and Thursdays, and one went live about an hour ago. And it is absolutely accurate. You guys know Jira, the Jira API. We're pulling the Jira API into a website. That's what's going on. And that little picture that you see on the website, if anyone here uses Jira in their job, that's actually an attachment on the Jira issue. It's how it works. And Benoit at Turbulent has been fantastic.

And I think to further clarify, the schedule wasn't made in three days. Like, when we started this, we didn't know what we were doing, and then three days later, we made it. This was just allowing the live data. We had the connection points that had to be created with Turbulent; they spent a lot of time on their end making sure the platforms interact with each other, and like you said, pulling from custom APIs. And then we really just added a custom field, a public field in JIRA, and there's all kinds of really cool customization that we put in place so that it would know what to pull and what not to pull. And like we communicate in the caveats, we intentionally don't have certain things on there based on where they are in production. So there's other things than just that stuff on there. But it was a good exercise to take exactly what we built on last year and take our data that we already are managing and pour it in here, and now we've got these great one-to-one connection points that we can, again, interact with. It's also been really healthy to interact in a very open way with the community on, like, that's 3.2. That's definitely still on track for 3.2. I would say this internally, but I'm on camera telling you that because we still feel confident about it, right? And it allows for a nice dialogue that I know I appreciate, especially with the most recent studio update we did. In the past, it would be like, that character update's coming. The next one, I know it is. We've talked about it. It's internal. But now I can say, that roadmap you're looking at, that's still the aim. And you'll see if it shifts up or shifts down based on whatever comes up.

And also, I think people will get this, because we've all worked on projects. We all went to college where it's like, you work on your term paper, but you don't really work on it until the last week. Like, oh, I'm working on it, I'm researching, I'm doing web surfing, whatever. But you really work on it that last week. And you really get that focus, in that zone, right? When you've got to perform, you perform. So to a degree, it's always easier to be like, well, maybe we can get it out by the end of the month, right? But I don't want that pressure, so we'll just push it off a little bit more, push it off a little bit more. So what this is doing, because we can reduce scope to get it out, I mean, that's the number one, we're time boxing it. But in a way, it's kind of like a forcing function. Not keeps us honest, but keeps us where it's like, we know we have to get this out in some form. Now, we don't have to get every bell and whistle onto here, but we've got to get something out that is real, that solves a problem, that is actually a fun experience, and then we can build on it. But to a degree, by kind of putting that stake in the ground and making it public, I think it clarifies for us, because it's out there. We're working hard on it. We're going to get it out there. And it kind of takes the decision away from us of like, well, what are we going to do? It's like, well, we're going to stick to what we said we were going to do. We're going to keep the team focused. We're not going to try to pull them off something. So I actually think the public roadmap helps us internally as well.

That's interesting. So I think there's a lot of science behind people. And I think there's a lot of really great readings out there about how we function as humans. Some are classical common wisdom. Some are new-agey, trendy, software-devy types of things. But there's an interesting dynamic that occurs, not just in people's brains, but also in the impact of that conversation, when people stay standing up. If you stand up versus sitting down, you tend to do things quicker, your legs start getting tired, your brain functions a little bit differently, and it also reflects the intention of what that is supposed to be. So if I stand up and I say it's a 15-minute stand-up, it's a pretty common thing to do at the beginning of the day, beginning of the week, beginning of the project, beginning of the feature, whatever it is, because we are getting in a room, we are all going over either what our blockers are, what's coming up next, what we're working on, to get in and get out. Right? Because people complain about meetings. Oh, I got meetings. When you sit down and you have your coffee and then you relax, it's still all work-related, but it depends on the goal of the meeting, right? There's even science behind taking someone out of their natural environment, which is maybe the same meeting room we meet in every single Monday for the last three years, and going, we're going to go outside and do it now, right? It sounds super new-agey and kind of like some of these new software companies, but it's the same thing, right? The reason you have work lunches, right? It's the same thing. Your brain goes through a change. There's all kinds of unique things and fun things that happen to the human existence when you do these things. And back to being able to work with people, it's fun to help engage different parts of their brain and engage different parts of the team to do things in a potentially different, unique way.

But I think also, I made this joke in the ATV that went out yesterday, but nomenclature is so insanely important, right? If you talk to some processes and practices out there that people have been doing for hundreds of years, or they've been building houses or rocket engines or whatever the case may be, once you've established a pipeline and nomenclature and then you all are speaking that same language, there's no questions in it anymore. So when I say the word stand-up right now, everybody watching, I think we know what that means. If I say, hey, everybody on the team, it's time to stand up, sometimes people literally stand up from their desk and they do their round robin and they sit back down. But it's the same thing with our vehicle pipeline. It's called ships. It's the ship pipeline because we were making ships right back in Arena Commander. That was the goal. And so now we have ground vehicles. Should we change that nomenclature? Or when I say flight prep, everyone knows what I mean. And now, especially with Ship Shape, you're training everyone out there in the world to know what that means. And I wanted to go more into that on the studio update, but I'm like, all right, you don't want to hear me talk about nomenclature on this thing. Just show stuff. But the nomenclature of flight prep, once it was established years ago, everyone that comes in as a new employee, they get taught this way, they get to say this thing. When I say it in an email, hey, that ship's in flight prep, there are no questions. If I say it's kind of towards the end, what does that mean? Does that mean it has UVs? Does it mean the damage setup? Does it mean VFX is in? Does it mean sound's done? When does that happen? The reason you see these beautiful pipelines being created and then iterated and changed is, once we all are looking at the same map, or we're going the same way, we take so many questions out. Once I know what my job is, I know what part of the pipeline is important to me, I know when it happens, I know where it's going to come. It's the Chipotle question. But how we still allow for creativity and for improvements, that's the challenge. I don't know how I got on the stand-up question, but nomenclature is so incredibly important, when you say that word and you start saying it over and over again, that people are like, oh, I get it. I don't have to ask what that means. When Jared says, hey, we're going to do Reverse the Verse, can you be on it? There's a general sense of what the show is now. People know what to expect from it. Over the years of Reverse the Verse, what is that intention, even though it's shifted? It's the same idea.

At a basic level, nobody likes status meetings, right? Status meetings are really bad. Nobody's like, oh, I go to work, I love how many meetings we have. Generally, that's not the thing. We're comfortable here, right? The three of us sitting down here at the table, we're sitting down, we're comfortable, right? So we can park here, we can camp here, we can just hang out here. Well, if people don't like meetings, then if you don't sit down, it goes back to, it's not comfortable. So go there, have just the part of the meeting you need, which is what Eric had said, which is: I'm working on this UI bit. I need a programmer to hook this up, and that's blocking me. But after that, I'll be ready to go on my next task. Why do I need to sit down and then look at a PowerPoint up on the screen? This is what I'm working on, and I'm not blocked. This is what I'm working on, and I am blocked. And then let me get back to developing the game.

That's an interesting question. I'm pretty sure you can click that little caveats button and get that answer. But you want us to say it? We could say it too. I think, like I mentioned before, the goal with the roadmap is to show as much of it as we possibly can that makes sense for what we're trying to release for each upcoming release. No, it does not show everything, as we explained in the caveats. And like I said, I think even in the ATV and then just a moment ago, it depends on where the features are at. It depends on where the asset's at. It depends on how much R&D is left. The tough thing, and anyone that's worked on a creative project where there is prototyping or R&D necessary knows this, whether it's a game, or whether you're prototyping a new way to do something online, or you're prototyping a new way to tell a story, it doesn't matter. There's so many unknowns that, other than saying, can we do it in six weeks, there's no other more management or production you can do on it, because you don't know. You don't know what you don't know. But the moment you know, that's when we can really, right? Like once we've discovered the pipeline for ships, we can keep going back to that. Even though we've tweaked things over the years, we know what that is. We know when we bring a new ship artist in what they're going to do. There's so few unknowns. So no, it doesn't have everything. It has a good chunk of stuff, but it intentionally doesn't have everything.

That we feel confident that we can include in these releases.

I think that's the big key. It's the stuff that we feel confident we can get out, and there are definitely things on there that are ambitious beyond what most other people would be comfortable sending out. That's why some of the other ones that came out weren't necessarily that way. But you can also think of, imagine that there's a feature that we weren't as confident with, but really could be cool if it would work. It's almost like a very R&D project where it's like, it's a 1 out of 10 chance this is going to work. But if it does, oh my god, it's great. But that kind of project, if you analyze it too much and you try to break it all down, it can kind of die. Sometimes ideas are fragile. So I think the roadmap is a really great suite of features that we feel pretty confident we can get out. I'd say very confident we can get out. There's definitely stretch stuff on there. There's definitely ambitious stuff. But you wouldn't want every brand new idea to be subject to that level of scrutiny, because it wouldn't be best for the game in the long term.

So here's just the way that it's structured. I'll explain these terms a little bit, but I don't want to get too far in the weeds. I'll use a little bit of jargon here, but not too much. But anybody who's worked in Scrum will get this right away. So if you see something on there, like the service beacon, right? That's what's known as an epic, which essentially is a group of features, or a group of user stories, a group of things that come together as a nice feature that can come out together and be something that's well-rounded. So whenever you take a look at that and you see one of the cards there, or you see one of the features with that number on it, you're actually looking at an epic. So within that, we've got that number where it says a certain number of tasks completed. So we use tasks because it's something everybody knows. If we were to put on there nine out of 12 user stories completed, it'd be like, well, what's a user story? And then we have to get into a whole conversation about why we use user stories for features where we might not use them for something else. But essentially, everyone gets a task. It's something you've got to do. Basically, if you see that number, 38 out of 57 things done, that's also not going to be all the polishing and necessarily all the things that will come up, and bug fixing, because we can't always predict the future. But we do know on something that we've got a lot of work to do, and we just kind of bundle them under tasks. But those are epics, and there's user stories under there, and there's tasks under there. So that's exactly what's driving it. But that's kind of why it's left a little bit vague. Some people would get it if we put user stories, but it might be a little hard to explain to everybody.

I think on the Reclaimer specifically, again, not going into the weeds, but there's some animation stuff left and there's a couple more pieces left. It's a pretty big ship with a lot of moving parts. So that, besides going into the polish phase that we'll be getting to shortly.

And this, I think, is actually something really simple that a lot of people kind of overlook, but there's some real power in it. So a user story is kind of a building block of Scrum. Everybody knows these things. Essentially, it's a way of describing what you want to do. So an example of this would be, for the character customizer: as a user, I want a character customizer so I can customize my character in the Persistent Universe. That would be a big user story. And basically what that means is, as a user, so as a player, I'm speaking as a player, I want this feature so I get this benefit. Versus saying "character customizer" and having it as a task. Now, a character customizer task makes a lot of sense to people who are on the design side, but it doesn't necessarily make sense to everyone who has to touch it. It kind of goes back to part of why we love production, because we get to interface with so many people. So if we have a user story, "as a user, I want a character customizer so I can customize my character", it seems like you're overstating things, like, why are you doing that? But imagine this. As we start working on that user story, we start breaking it down into smaller stories. So imagine if you said, "as a Star Marine player, I want my character customizer in Star Marine so it matches my PU character." That makes a whole lot of sense, right? But if we were going to write that as a task, it would be like "transfer PU character customizer to Star Marine", right? That could be how the task was written. That doesn't tell you the intent or what the player wants to get out of it in the end. And when we come into the office and we're doing all this work, it's not just to get tasks done. Nobody on the stream, nobody playing the game says, oh yeah, they're working on even more tasks than last month. No, it's about the objectives we can deliver. So by writing a user story, you make sure that everyone working on it sees what the objective is, and we're all working towards that goal. We're doing that whole user story about Star Marine so that people's PU character matches their Star Marine character. So whenever it's in QA or it's in art or in any of the disciplines that it's in, we all know the goal, and we're working towards the same goal. So that's why you would write a user story. You also write it to annoy Chris, because he doesn't always love them as much, but he's coming around, I feel.

And just to confirm, folks, he was using the character customizer in Star Marine as an example. This is not him sitting here confirming that we're bringing that to Star Marine.

Not confirmed. I'm using that as an example.