Eric Kieron Davis

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.

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.

With the distribution of our disciplines, there's a benefit to getting everybody in the same place, which is why I think that term summit became big for many, many years, depending on what it was they were trying to do or where the game was at or what the state was at. On the production side, or on the planning side, or the project leadership side, it was important for us to get in a room and just solve some problems as quickly as possible. And there's benefits to working remotely and there's benefits to working together. We had started doing these summits for production specifically last year, and so this was kind of our third one, or our next round of it, and it was a great time to evaluate last year: what we were successful at, what the team was really doing well, what the team needed more from, how we could support them better, how can we engage our community more, right? Just kind of, what is that next iteration to make this better? Not to change for change's sake, but with all the information we now have and the experience we now have in this environment, what's the next step and where do we want to take it. And so that was a big focus of the summit for sure. And then for me, Dennis had just joined the project six months ago, so getting them out in the rest of the studios and working alongside everybody, I think that was, for me, a small perk to doing it again. But the benefits are great to set the stage for the year or for the next six months, or just to go, okay, we all come together. We've solved these 10 problems. Okay, out there and now start making change.

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.

Well, the why is because we're working alongside the community. There's no question that the more we can get out, the more we can share, the more we can discuss and have feedback on, the more everybody can see kind of where we're going and how we're doing it, what we're getting done, because we're on this journey together for all intents and purposes. We are interwoven into one, so the more that we can work together, the better, right? So that was the intent, and the intent with the current roadmap is the same idea. The manual nature of it was definitely because of how we organized some of our schedules. It was still in JIRA and it was still in Microsoft Project, things we've talked about in previous production stuff, where we built that schedule, you got to see it. It was still happening in that vein. We just weren't capturing it in an automated way per se last year. So there was some manual nature to making sure we got the information from the right place to the next right place. And there were always intentions to do what we did this year. It's just we prioritize our overall developer work and our time. And so things shifted around, and so it stayed somewhat more manual than we probably all would have liked it to be. And then we shifted things around to be more burndown. As we got to 3.0, it made sense to talk even more granular about burndown and get that going. And Chris was really passionate, just like all of us: how do we keep sharing this, how do we keep this engagement, how do we make sure you know, here's where we're going, here's what we're trying to do, stay on this journey with us. And so that brought us, like all iterations, into this new roadmap that we have this year, working closely with Turbulent and our partners over there, really coming up with a solution that allowed for that immediate data, live data, right there, and has those checks and balances, and we can share that conversation. So yeah, it was just kind of the first pass of it. From my understanding, over three years here now, we hadn't, in my history, shared that level of detail. And Chris was really adamant about it, and we all got on the same page about it at the end of the year before and into the new year. And we really wanted to get that in front of everybody the best we could. Try to bring you along with our timelines and keep you up to date on things, and for good or for bad, keep our skeletons out there and keep showing you, this is what we're trying to do to make the best damn game we can.

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.

Yes. I mean, there's a lot of aspects to that, right? So the project leadership group for the Persistent Universe, as well as Chris, kind of go: with 3.0, we've laid so much awesome foundation for so many great things. And so now, what do we build on in that? And where are we at with each of those things, right? So if mining was in the R&D phase, but we've already figured out how to do it, now it's just about executing on it, great. Here's the tasks it'll take, now that we know more about it, and when we can get it done. Does that work for the project? Is that a good time to roll it out? So yeah, it's based on complexity. It's based on when that quarterly release lands, based on what we've established it would take to make it. Also based on what would be good coming in together. That's why you see some of those features planned to come in together. Object container streaming, as everyone knows, is a big feature that we're working on on the technical side, which will allow us to add more content and allow for better streaming in and out as you move through these large areas of assets. So yeah, there's a myriad of dependencies. It's not just a grab bag of like, I kind of want mining right around September, because that's when it gets colder out in certain areas of the world, and so I feel like I'd want to sit down and do a lot of mining. Does that feel good to you? Do you feel good with that, Crow? Yeah, let's do that. Maybe that's a factor, but that's a tiny factor. That's a real small one. But yeah, there's all sorts of aspects.

When? It's the production part of me, that's why you have to ask the 'when' question, right? I can't go without a 'when.' Okay, the 300i rework. That is a great question. It is, I believe, the last of our original five pledge ships. And from what I understand, it's one of the most owned ships?

Yeah. On the recent accounting that I had to do for Ship Shape, it was number five in total ownership amongst all ships.

Wow, so there's a few people interested in what's going on with the 300i. Fair enough. All right, so the 300i, I'm going to have so much information for you. It is definitely on our radar. It's definitely one that we want to rework. It is on the agenda to work on, as you'd expect. I can't give you more information on what the date is. I know you're asking for it. We're looking at 2018. We're looking at what the long term is for a lot of the ships. Being one of the last ships to be reworked, we're definitely super interested in getting that done and out from under us and getting it into everybody's hands, so we can keep moving on to the new ships and the fun ones that are coming up. So I can't give you more than that, but it's definitely on our radar. And I think you're doing Ship Shape now, right, Jared? So is it going to be on Ship Shape in the future?

We do have a new Ship Shape segment every month on Around the Verse going forward.

Well, I think that might be a place that gets updated. More information to come for sure. But being an original and being a rework, the guys get really excited. We're doing the Mustang rework and it's looking really good, and just seeing that ship in the studio gets us really jazzed. So the 300i, it's coming up.

That's a good question and it's up to design to answer and I've not seen anything written in stone for it. At the moment, no they don't share any clothing. The aliens don't share anything with humans the real big problem with that is one of scale a good example is the Vanduul who are about 8 feet tall, and he wouldn't want to share with a human anyways, but if he would the stuff wouldn't fit and wouldn't look right.

We don't want to do any of the hand wavey it just magically fits on the dude and all of a sudden you have human sized Vanduul armor it's not really going to be like that. Now whether or not aliens sell human clothing in their shops, I think that'll completely depend on the economy. If they have a lot of humans there they are going to want to sell human things in that shop. Right now we don't necessarily have a shop run by aliens so I can't really tell you if they'll sell human clothes but they could.

and repurposing, look at the Scythe and the Glaive, we got access to alien technology and repurposed it for human use.

Right but it was very specifically authored.

you got it, so it's not out of the region for possibilities but also going into character customization and how these guys have done such a great job setting up our tech and our characters it doesn't hand wavey magically work like that, in reality how would I make this work on this character and it's the same sort of process here.

It's a really good question and I'm glad you ask because we don't communicate this necessarily as well as we could sometimes. Players have had some form of item 2.0 for a very long time. It's items that have been componentized vs entities that have a whole set of properties on them. So Item 2.0 is really is the componentization of functionality per item. Maybe that isn't a perfect way to frame it in one sentence but what it does is takes all the properties and generalizes them as much as possible so we can apply gameplay components onto them or any item regardless of its entity type.

What we are doing is taking the Lumberyard engine from being a purely entity driven engine to being a componentized system, meaning you can share components between different items or entities so you don't have to write bespoke code for every single entity.

An animated object within Lumberyard was an entity and that had a certain set of properties so of the big ones being a model, animations and some physics. All of these were written in terms of the item entity so instead to componentize that and move that entity from an item 1.0 to an item 2.0 you would have to decouple all of those properties from the entity itself. So you turn it into an item first of all but it cannot do anything by itself, we call it a game object, it's just a concept of a container waiting for components.

The first component I add is the geometry component, something which can be shared across pretty much any item. Then you might have an animation component which would be added to the same item and at this point we almost have the same entity in a componentized way. We have to write all those components up, so the conversion is a slow one as we have to slowly removing all the bespoke entities from Lumberyard and turning them into a componentized system.

Which allows for some really exciting gameplay implications because once you have things in this way there are more interesting things you can do with them. Which is a large part of the gameplay aspect of what we are making is, utilizing that level of granularity which is really cool.

It also just makes things easier to make, by far. The geometry component was the most obvious one right out of the gate, so that was the first one we wrote. Now we can assign geometry to any item through this one component, this one block of code that applies to everything. Rather than whole separate entities dealing with their things independently and if we change something we have to change it across 100,000 different entities, which creates too much work.

So one of the other things on top of this is the performance it brings us and the ability to optimize. When you have so many entities with so many different properties you have a hard job doing large scheduling updates. What we can do with these components is make an entity scheduler and make it update the component so many times per frame or if an item has a geometry component that's over 10 feet away say don't updated that one. It is these kind of optimizations we can make in a component based system that is the whole reasoning behind doing it.

The way i have to explain it is that there isn't a separate flight model. It is completely seamless, at some point when you get into the atmosphere you are at 0.001% of hitting the atmosphere. The first reason of why we don't have a whole new flight model is when do you make that switch? It would feel like something is happening and that's not something we want. What we want to do is make our flight model which is made to fly ships around which aren't aerodynamic is still what is being used in atmosphere just the variables applying things to the ship have changed and pretty dramatically.

Those two things you've mentioned wind and air density are the more important things and everything that would affects those two really are the things that would do anything. Drag is affected by air density, the amount of wind from weather from all different places. What's going to happen when the ship hits the atmosphere they thrusters are going to keep the flight model the same except the external forces are still acting on it like drag and lift are now a lot more obvious but the model itself hasn't changed. We have actually have a guy with a Phd.

A very smart guy

we stare at his screen of formulas and bar charts. He [John Pritchett] is our flight programmer and he's been on the project from the start.

The complicated maths behind the newtonian physics and that model. That brings back to the simulation as much as we possibly can. What would actually happen if you take this ship into atmosphere.

So to answer more clearly, the shape of the ship will absolutely effect how it handles in atmosphere, but it's not due to a different flight model. More because those external variables are different, less drag because it's more aerodynamic, more lift because it has wings and more like that.

We constantly clash in terms of its a game thing that happens in game development of what happens in reality and what's just a game part of it. John hates the hand wavey game stuff. He's like "Noooo that's not how it would work" the the G-Force conversations are just none stop. There's a way we do it in games that is fun and feel s cool and then there is the reality of what it would do to you. You definitely have to come to a balance but it is nice to have the accuracy of someone that understands it in the real world.

It is nice to see that level of passion in each person's individual aspect of what is Star Citizen. Everybody you interact with in their field or thing that is exactly how the conversations go. The passion is deep and rich and it is a discussion you have to have and then ultimately we get to what you get to play but it is across the board with everyone.

So the cool thing is being a global company, we can't just say what LA is working because we are acting as one as best we possibly can with the time zones given to us and in LA currently have 5 that we're working on at different capacities. 2 of which we've talked about recently, but the other ones are ones we're either working on with our partners in UK on or are different forms of production or pre-production.

Ships are one of our biggest thing to working on so we're always having them flown in and out. We have what I call a subsect of our tech design team here and our ship team comparatively to our partners in the other region. So yeah touch quite a few in different capacities and they kind of flow in and out and it's the most exciting about being such a large, free flowing community of people making this game and product.

Just building a mesh that can actually go in the game. Because the high polys can be several million, tens of millions of polys, and that can never go in.

So essentially you freeze your mesh. You have your high poly, then you decimate it and then bring it into your retopology tool and then start tracing over it with polys and try to recreate the same exact shape with the least amount of polys as possible, yet enough for animation to still be able to move it around. And like Corey mentions in the video, about having to keep the silhouette and making sure that no matter what angle you look at that thing in a 3D space, it will always create the exact same silhouette. That way the character doesn't get lost in the translation between the high and the low.

I would have assumed you guys would have said the high poly phase because you get to make such detail. It seems like you're attracted to the challenge of going, all right, we got this really pretty thing that looks awesome, a lot of polys, will never work in-game, but now we get to put it in-game.

Yeah, there's two aspects. There's the making it as good as you want it to be, and then there's the ability to get it in the game to mimic how great your original source looked.