TL;DRThe producer role varies by studio, but broadly it supports teams and leadership by managing schedules, scope and priorities, built around communication, planning and risk.
It depends on the studio, right? So game production is not the same across the industry. Every studio runs the production differently from another. But generally, baseline, it's about supporting the development effort at large, supporting teams, managing schedules, scope, timelines, priorities. It's a supportive role. We support teams and their endeavors and them hitting their goals. But we're also leading the charge. We're part of leadership and it's all about plotting the course for the next few months, years, whatever the project needs.
Yeah, and I'd kind of echo that and say when I think of just the basic building blocks of a producer role, I think of basically three pillars or columns. One is communication, the other is planning, and then risk. So production is basically managing communication, making sure that's flowing smoothly. Planning is all about schedules and making sure that we have them, first of all, but also that when things inevitably change, because that never happens in game development, that we update them accordingly and then communicate out those updates. And then the last pillar of risk is managing potential risks or impacts that might negatively have consequences on the schedule, essentially.
TL;DRCommunication management means planning how information flows between teams and departments at a project of this size, which artists and designers aren't trained in, while keeping meetings focused and concise.
Yeah, so I think for me, when you talk about communication management, it can vary from project to project. And that's kind of a disclaimer for this whole conversation, by the way, is that production can mean a lot of different things just depending on where you work. Titles can be different, producer versus project manager or development director or coordinator. There's lots of different words that people throw around for what we do. And every company seems to have a different expectation about what a producer does at their various job. So there's that disclaimer for everybody. But at least for us, when I think of communication management, especially for a project with scale, because this is very different for a small shop where everybody works in the same location or if everyone's remote. There's plenty of different platforms for communication through email and messaging platforms and all that kind of stuff. But for a project of our scale and the different departments that are involved, it helps to have a plan for how you communicate. It's not enough to just say, well, just hit me up whenever something's happening. I was literally having a conversation with QA earlier this week about how we communicate progress and status towards bugs and how production can help give QA the information they need. We have these various channels in our communication platform that we use to send messages, but how often are we sending those messages? Does it make more sense to consolidate all of the information you need into a single meeting or does it make more sense to send little tidbits of questions throughout the day, right? What makes most sense? And how do we keep that from ballooning to where it's just absolutely untenable? So organizing the flow of communication is an important part of a project our size and managing a project our size.
When you come into a business like this, you've got artists. They go to school and they train to be artists. You've got designers. They go and they train in game design. In all of these curriculums, and I've been to a few video game job fairs, there's not really a course in communication. The act of communicating is one of those things that is not generally taught. You're taught to be an artist, but you're not taught how to communicate that work effectively with other teams. And that's one of the big areas where producers come in. They form that membrane between all the different disciplines and make sure information is flowing from one to another as effectively as possible.
Yeah, absolutely. Communication consists of multiple factors that you have to account for. Communication is not something you can learn in a Udemy course. It's something you have to build a skill for and get better at over time. The greatest communicators are succinct, they're clear, they're concise. They get across what they want in the clearest way possible with the fewest words, right? Great orators are always the great communicators that we aspire to be. We want to explain something very complex without going into the nitty-gritty and get people on board. And in game production, communication is very similar. When we coordinate with multiple teams, for instance, to get a feature out the door, or multiple departments, we cannot sit in hour-long meetings and discuss all the kind of things that we'd like to talk about. It has to be specific to that meeting. We have to get to the bottom of what we're trying to achieve and get the job done.
TL;DRRisk management means spotting things like unexpected found work that could hurt the schedule, assessing and tracking mitigations, and sometimes simply accepting the risk, since mitigations often don't work.
Yeah, so risk management is a huge part of what we do. Part of making sure you're delivering things on time is making sure that you're trying to, as proactively as possible... The thing that you are looking out for are things that can negatively impact your schedule, right? And it's impossible to be able to 100% identify risk ahead of time, 100% of the time, but you try to identify things as they're happening. So as an example, if you have a gate review coming up for a particular feature or a ship or something like that, and something happens where some found work appears seemingly out of nowhere: hey, we didn't know that we needed to add this additional thing. That is a risk at that point. We don't quite know what this is yet, but it very well could have an impact on the milestone we're about to hit, the stage gate we're about to hit. So let's have a meeting about it. Let's talk about it and assess what is the scope of this thing that's come out of nowhere. Can we somehow make this work within our current schedule by bringing somebody else in to help out or reducing the scope somewhere else? This is risk mitigation, right? You're taking the problem, you're assessing a potential solution to mitigate that problem, and you're tracking that. You're saying, okay, I've got that documented. If this thing comes to pass, I know to execute in this way, and hopefully if you are able to mitigate the risk, you keep your schedule on track. Often the mitigation strategies don't work, or there's nothing you can do. There is a risk mitigation strategy called accept. Sometimes you have to just accept the risk, or it's a business decision. You know what? We're willing to accept that risk because of any number of different reasons, right?
TL;DRWhether to take a schedule risk is decided by production, team leads and a director weighing options, guided by a shared risk appetite that is typically higher for tentpole deliverables.
Usually when we identify potential risk for a deliverable, like a feature or something, I think we had a recent example that we've talked about, the ship trespass feature, for instance. So we had a full-blown schedule for the feature on a task level. We knew when it would be ready, but there was always this risk looming that there could be more edge cases that we have to address before we can release the feature in a good enough state, right? So that was one of those risks that we tried to mitigate but couldn't, and then we didn't feel comfortable with just releasing it anyway because these edge cases needed to be dealt with, and so we had to pull it out of that release. But in other instances, it's usually a discussion between production, the team leadership and a director like Todd. We will sit down, we'll go over the risk, and then we'll give him a few options and discuss it with him. And then if he's happy to go down the road of, okay, let's shoot for it, right? Let's put a few more people on it so we can get it out on time, then we'll do that. And if he would prefer we keep it, we make it good, we get it in a better state, then we'll do that instead. It's always a coordination effort between leads.
And to that I'd add, sort of how this process starts is you look at your release, just the release that you're planning for, and you try to identify what are our tentpole deliverables, right? What are the things that are really going to prop up this release and be the big selling points for this release, the things that are going to excite people, right? So you identify what those things are. And you then discuss what your level of risk appetite is. And basically risk appetite is what's our tolerance for risk with these specific features. And generally speaking, your tolerance for risk, basically allowing the potential to go down different paths that might impact a schedule negatively, your risk appetite might be higher for tentpole deliverables because that's going to be a make-or-break sort of feature. Whereas something that may not have as big of an impact, we don't mind delaying slightly to give it the time it needs. Or it could be even a bigger thing, but we're like, you know what, this needs a little bit more time in the oven, right? The risk appetite is low on this. So let's go ahead and do that. The trick with this is that everybody has to be in alignment. Everybody has to have the same risk appetite.
TL;DRThey agree that edge cases abound because the project is cutting-edge R&D, doing things not done before, so schedules built on past experience are always best-effort estimates.
It's not wrong. Actually, let's talk about that for a second. Game development, as everyone watching and here understands, is difficult, right? We're trying new things all the time, especially for a project like ours. It's always on the cutting edge. We're always trying new things and doing these in different ways. We're swinging for the fences on a lot of stuff. So some of the stuff just hasn't been done before, or we don't necessarily have a clear path ahead of us. So we start on a path. We generally have an idea of where we're going, a trajectory, right? And things happen along the way that we just didn't expect. And it's just because, you know what, we haven't done this before. We haven't tried it before. So let's see how this goes. As those things come in, yeah, you have to assess every single thing as it comes in.
You said a line here, I want to clarify it. You said because we haven't done this before. It's not like we haven't made games before. Everybody here has worked on another project, has shipped other games and whatnot. The weird reality, the thing that sometimes gets lost, is that if you're building something that's truly new, if you're building something that's truly different, you haven't done that before. So the way in which you tackle it will be different, ideally. The way in which you progress through it will be different. And the way in which you estimate and schedule it has got to be like, okay, your schedules have to be based on prior experience, and this is the way we made this thing, but we're not making that thing, we're actually making this thing, so we can extrapolate from this, but it's always a guesstimate. It's always your best effort using all the factors that you have.
That's a good way of putting it, because I don't want to shortchange our extremely talented and experienced developers. They know what they're doing, but often what we're doing is trailblazing, where we have these super talented and smart individuals for a reason. We want to try new things and we want to break the mold and we want to do a lot of stuff differently. Trying to, anyway.
TL;DRSupporting people means emotional intelligence and being there for developers dealing with stress, including offering a shoulder to cry on or vent, which Jake Ross says is what separates great producers from okay ones.
Yeah, well, I mean, you kind of joke about that. But when you talk about those three pillars, right, I'd also say that the foundation undergirding all of those three pillars is people. Part of what separates the okay producers from the great producers, I think, is that aspect. It's managing and being able to have the emotional intelligence to understand people. A lot of what we do is some of that. There is stress that is involved with game development. There's a lot of range of emotions. I have literally had a tissue box in my office because I would have a developer come and talk to me. He was struggling with various things, some work-related, some not. That was, I think, something that I was very happy to do: have somebody who needs a shoulder to cry on or needs to vent or something like that. As we go through the day-to-day life, we have to remember these are people that we're talking about here, and that is a motivation of mine and one of the reasons why I went into production, because I love working with people and talking with people and helping people to be their best self.
Well, here it's, again, every place is going to be different, but here it's sort of the same thing. We have assistant producer, which is a sort of entry-level role. We have an associate producer, and associate has two levels of one and two, and then we've got mid-level producer, just producer, one and two, senior producer, and then lead producer, and then you go up from there into production director and beyond. So that's kind of the general hierarchy within production. So it matches pretty well with what we have at the rest of the company and different departments as well.
TL;DRA lead producer manages and mentors producers, keeps a holistic handle on the schedule of everything in flight, and watches team performance, digging into root causes where velocity or execution falls short.
Yeah, so for me, it's a lot of, I mean, where do I start? I do a lot with people. I manage people. Philip and others are on my team, and it's a privilege to be able to help coach and guide and mentor wherever I can in that area. I consider myself sort of master of schedule. Whatever's going on, I try to make sure that I have a handle on where everything is in flight, whether it's in early stages or middle stages or later stages. We have a holistic picture of the entire development of Star Citizen. That's sometimes a challenge because there's a lot in flight at any given time. But I try to maintain a hold on that as best I can. I would say performance is something I kind of keep an eye on, in terms of how well we are performing as a team. If there's areas where we don't have the velocity we need or if we're not executing where we need, I'll kind of go into that and figure out root cause and try to figure out how you solve that problem.
TL;DRVelocity is the rate at which a team executes its goals, measured most easily on repeatable content work, and tracking it lets producers decide whether to cut scope, add people or fix problem areas.
Yeah, I mean, generally speaking, every team has a rate at which they work, right? And it's easier to measure for some teams than others. If you are a content-producing team and you're pumping out the same sort of asset over and over again, it's easy to kind of measure. You can measure how long it takes for one of those cups to go through the process, and you can kind of measure that velocity. And you can say if we want 10 props in this next upcoming patch, we only have enough resources to be able to achieve six of them. So if we want to increase the velocity, then we need to find ways to either reduce scope or add more people. And there's various levers you can pull to try to increase your velocity. That's really what it is: trying to measure how quickly we are able to execute on our goals. And the reason you do that is so that you can dive into areas where you feel like the velocity isn't quite what you want it to be, and you can help solve those problems.
I'd say an R&D-heavy team. Any of our core tech teams or gameplay feature teams, it can be difficult sometimes to get a handle on that because the work items, if you want to call it that, the cups that they're putting through the pipe, are not cups. They're foundational technological marvels that people are building. And so it's hard to measure and quantify and compare apples to apples in that way. So what you can look at is sort of individual developer velocity. So you can look at it down to the developer level, like how's this person doing versus that person? And it's a way to help alleviate blockers and help somebody to improve in their craft.
TL;DRIt can get that granular, but on this project it doesn't; they trust developers and only look at what a team achieves over a period like a few months, not individual check-ins or tasks.
Yeah, we don't want to watch over people constantly, right? We trust our developers. I mean, they're professionals. All we care about is that how long they think it takes is what they feel comfortable with. They don't give us estimates to make us comfortable. All we care about is when we can ship something to the players. And what we look at holistically is how much a team can achieve within, let's say, three months. And if that is half a feature, then it might take six months to deliver a full feature. So we try to give the developers the space that they need to figure out all of these difficult problems, and not look over individual check-ins or measure how many tasks per week they've closed off. That's not what we do.
TL;DRProducers question optimistic estimates and scope, since people are bad at estimating, and add buffer for unknowns, meetings, time off and bug-fixing so schedules are not maxed out.
I'm actually quite passionate about this, because I review all the game design documents that the lead designer puts in front of me. Like if they say this is the amount of work, I'll try and question that, right? Because they may feel very optimistic that we can achieve something with X amount of weeks or months available to us. But I, as a producer, have the responsibility to push back on that and look into those numbers and look into that scope that they're trying to achieve and ask difficult questions like, are you actually able to do this on your own? There's so many things you have to keep in mind, right? Some of our leads have more than just development work that they have to do. They have their own people, they have a lot of meetings to attend, right? Everyone, I think, that I've met in this company is very optimistic about what they can achieve, because it's an exciting project. But humans are incredibly bad at estimating. I think there's entire papers written on it, right? So what we do as producers is question and push back, and wherever we feel like we're not really 100% confident, we can build in buffer, right? Extra time in the development of a feature schedule so that we can account for unknown unknowns. There's always something that goes wrong. There's a tool that's breaking, or there's some priority that has to be addressed immediately, right? So that is something that we have to deal with. It's a very big company with so many developers, with so many people checking in. You've talked about game dev before. It's difficult to get it in a stable enough state very quickly, and so sometimes we just have to make a push, and that can affect a feature's development time, right? So we as producers try to always push back, ask questions, try to understand what's the reality of a feature's development timeline, and then build in that extra safety net of buffer.
Yeah, and then I'd say that you can't always look at just an estimate on its own, right? Sometimes a developer will say this will take me three weeks to do. Okay, cool. You're not working 100%, eight hours a day, whatever it is, for that amount of time. There's meetings that crop up. People get sick or they take time off. You can't just look at an estimate somebody gives and say, okay, cool, I'm just going to take that and plop it into my schedule, and that's that. We do track and ask teams to account for time for unknowns, which is the things you don't know that you don't know, because it always happens. Things come up that we just could not foresee. And so we don't max out our team schedules. If they give us an estimate of three weeks, we might actually put it in the schedule for something like four, four and a half weeks, because we know that there are real things that crop up. Bugs will come in that need fixing. So there's an element of that as well, of trying to keep in mind the whole context of things, whereas the developer's scope of what they know about is the stuff they've been asked to do. Producers have to be mindful of everything that's going on in the project, so that we can be like, well, I know that there is a release happening around that time and that likely we will have to monitor the bugs that are coming in. This team is often supporting the releases and fixing bugs. So I'm going to take your three-week estimate and I'm going to add a little bit of time there, because I know that you will likely have to get pulled off and reprioritized to help support the release or something like that.
TL;DRProducers trust developers' estimates rather than dissecting them, but add context and buffer where they know of conflicts, and the process is collaborative between developer, producer and lead.
Ultimately, it comes down to trusting what the developers are giving us, but then always having a backup plan, right? I don't want to question every estimate that I get from a developer, because they know best. As a producer, my role is to get the information that I can gather and add some extra caveats to it, and as my risk mitigation process, for instance, add buffer. So there's been times where I've asked, are you sure this is just going to take one day? Because you have a meeting all week, or like the entire afternoon, so it's more like half a day that you actually have time for this. Like, yeah, okay, let's make it two, right? But I don't try to criticize or try and dissect what they're thinking this would take.
So you're talking about trusting the devs, and I just know from experience, you absolutely have to. But there has to be another layer of, I'm going to check over here, and we're going to check over here, because they're always very focused on their work.
I think it's just asking the right questions, right? It's a collaborative process. Game development is a collaborative process. Schedules are no different. You have to have the developer's input, absolutely, because they have to be the ones to tell you how long the thing is going to take. But then you also have to have the producer's context, and you have to have the lead who probably has more years of experience and can say, well, you didn't think about this. Oh, yeah, I didn't think about that, right? It's a collaborative process.
TL;DRYes, they hold regular internal venting meetings and playtests and track player feedback, which matches internal views, but fixes are often complicated and come down to how teams split time between features, bugs, quality of life and tech debt.
Yeah, we actually have a weekly, bi-weekly meeting that is just venting, right? It pretty much is that. It's not supposed to be just a place to vent. It's a place where you can share your frustrations, and we play the game every week. We have playtests internally that every team does. And after it, it's like, okay, there's a lot that we need to fix here. It's an opportunity for us to get a reality check, and we try to play as much on live as well. I try to do it all the time, to get the pulse on the current situation in the game, and then have that feed into the decision-making process that we do with directors and leads, right? Everyone is acutely aware of the issues that players have right now. We share those frustrations 100%. I'm seeing the posts, I'm seeing videos of people talking about what they like and don't like, and it matches almost 99% with what I'm hearing internally in meetings with regular developers. So I feel like we are very aware, but there's a challenge in just addressing what is currently the biggest problem at face value. It's often a little bit more complicated than it appears to be, especially when it's deep-rooted in some of our tech stack. It just requires a bit more brain power than just one developer going off and doing a bunch of bug fixes.
We do have a process for tracking all the player feedback, essentially. And so we do have an acute awareness, as Philip said, of what the issues are. It always just comes down to priorities, right? And I mentioned earlier how we have an expectation during our planning that we allot time for unknown unknowns. We also have an expectation that teams account for time to address what we call quality of life issues and bug fixing. And so along with the feature development commitments we would need to develop a specific feature, we ask teams to account for unknown unknowns. We ask teams to account for tech debt. We ask teams to account for quality of life and bug fixing. And so it's just a matter of what percentage of the team's time is spent on each of those allocations. And often new feature development dominates the team's schedule, but there are times where we pull those levers around and we say, okay, we're going to need to spend more time on quality of life this quarter, or more time on bug fixing, or more time on tech debt. But that's just the challenge of having both a live product and an alpha development game at the same time. So these are always just different levers that we have to pull.
TL;DRThey ask this constantly and decide case by case, sometimes pulling a feature and sometimes releasing an imperfect one for feedback, with producers communicating the impact of business leaders' competing priorities.
That is always the question. I feel like we ask ourselves that question internally every single week. That's the constant challenge. Folks expect a patch, and then folks expect a certain threshold of content to be in that patch. None of that determines how fast a project gets developed, how fast a feature gets successfully built, how fast bugs are found and destroyed and whatnot. And that's what we talked about earlier. Sometimes when it's a thing that's egregious and we can do it, like ship trespass, we pull it out. And sometimes you go forward, and it's like, we think this is in a place where it can still generate good feedback. We think it's in a place where it can still be useful for testing, where it can still be useful for analytics and stuff. So even though it's not perfect, we still put it out there, because it serves a purpose to our game development to get it out there and to get it in the hands of players. And I hear this conversation constantly, there's always this back and forth between whether that should be pulled, or whether that should go in with just a little more pillowing around to make it safer. It's the forever challenge, right?
We've done something similar for 3.19 when we introduced the ability for tractor beams to remove and reattach items. We knew that there would be issues with some of the ships because they're not up to gold standard yet. But we accepted that as a risk, because we felt the feature was in a good enough state that it would add so much more value to the current game. We now have the ability, when you go out for a salvage contract, to find loot and strip the ships of their components and make some cash on the side, right? Or re-equip missiles for some of your vehicles. There was value in just pushing forward and not scaling back and not saying, okay, let's get all these ships sorted out and hold the feature from getting released. We felt like it was the right call at that time.
It's that same debate. It's the debate that's going on in Twitch chat right now. It's whether a thing should go out, whether a thing should be held back. Oh, that's too many things being held back, now the patch has to be delayed so we get more stuff in. But if you delay the patch too much, I thought we were going to pull things out so we didn't have to delay the patch. It's just this constant, never-ending shifting of levers.
Part of that too, going back to what a producer's role is in all this: every single one of those things, putting out new features, addressing stability and performance issues, bug fixing and releasing patches, the events we do every year, preparing for CitizenCon, these are all goals that are set by our business leaders. They set the goals. This is what we want to do. What they don't know is, if they come in and say, hey, this is a new initiative we want to do for this next release, how does that impact everything else we were already planning on doing, right? So as a producer, a new request comes down. How does that impact the current state of things? And something that I feel like we've improved at over the years, but still could very much improve on, just full disclosure here, is better communicating impacts: this new thing came in, here's what that impact might be. We want this new feature. Okay, well, do you realize by requesting that new feature, it means this team's allocation towards quality of life and bug fixing actually shrinks? Was that something that we were aware of? And often that's not the case. So we have to be better at communicating that as well. And I would say over the years, we've improved at that leaps and bounds from where we were four, five, six years ago, right? But we can always do better at that. So I'd say that is something we're constantly assessing: of all these things we're trying to juggle, which thing is the most important at any given time? Because that does change quarter to quarter. And essentially, what would we lose by focusing on this versus that, and that sort of analysis and what I call scenario building: if we do this, then that means this; if we do that, that means that. That's the communication management aspect of this, right, where you come in and here's the impact, do you want to go left, do you want to go right, and then hopefully we can help our business leaders make a more intelligent decision that way.
TL;DRJake Ross says a big win is seeing a process change pay off, such as a new stage-gate progress measure that caught schedule slips earlier, and seeing incremental yearly improvement is why he has stayed.
I mean, earlier this week we were actually talking about some of this, because part of what production does too is identify areas of improvement. Okay, this is how the current process is going. Is it working or is it not? If it's working, how can we make it better? If it's not working, let's throw it out and do something new, right? These are the sorts of questions that we ask ourselves. When you introduce something new, a new process, often it takes a quarter or two before you really start to see the effects or fruits of that process change. But to me, a big win on the production side, and the reason I bring it up is because it's fresh, because we were talking about this this week, is when you see the benefits of that process taking effect. You brought up the example of ship trespass earlier. You can correct me if you think I'm wrong here, but the reason why I think we were able to make that call to say, hey, this isn't quite ready, let's push it out, is because we introduced a new process towards the start of the year, at the end of Q1, where we were measuring progress at the various stage gates in a different way. And so we were able to catch changes to schedule earlier on in the process for some of these features, which then allowed us to make calls about whether this is going to be ready in time or not. Sometimes things catch us by surprise, and that's never a good feeling, and as producers it drives us crazy. When things come out of left field and you just weren't prepared for it, nobody told you, they didn't communicate to you, they didn't use your excellent communication management plan that you set up. These are the things that drive us crazy. So we try to set up processes in such a way where we aren't surprised. We mitigate and alleviate the surprises as they come up. And so I think we rolled out a process change towards the beginning of the year that has started to pay dividends. And it wasn't a big thing. It wasn't a gargantuan, massive, huge thing. But it showed that, oh, we actually made something better. We made an incremental change that made the process better. And over the course of almost 10 years now, just to get personal for a second, it's the reason why I've stuck around as long as I have. One of the reasons is because incrementally each year I see the improvements. I see us getting better at this, and there's a lot that's wrapped up into that statement, but at least internally it feels like we ratchet up year after year in terms of how we run things and how we do things internally.
TL;DRPhilip Becerra recalls, at a different company, finding the Steam go-live date unset 30 minutes before launch, while Jake Ross recalls late nights and broken air conditioning before the first Arena Commander release.
It was not at CIG. It was a different company. I think it was probably 30 minutes before live, and we would release our game on Steam, right? So on the Steam backend, there's this little thing that you have to put in if you want something to be able to be purchased on the actual store. That's the go-live date that you have to set. And 30 minutes before the go-live date, we realized that nobody had actually set anything in that field. So panic sets in. And fortunately, I was working with a company that had good relationships with Valve. And so we kind of picked up the red phone and said, Gabe, make this go live, please, effectively. But in those 30 minutes, I've never been this stressed out. This was a crazy moment. And I'm happy that five minutes before live, it was actually live.
I mean, I was thinking about this. It's funny, some of what I would call horror stories in the moment, I now kind of weirdly look back on fondly. I don't know what that says about me, but I remember the early days here, trying to get that first publish of Arena Commander out the door.
Yeah, so the days leading up to that were intense. I'm just going to say it for what it is: late nights, people sleeping under their desks and stuff like that. But what was great about the whole thing was that at that time, the Austin studio's air conditioning would go out for no reason. So it was really, really nice to be up super late at the studio with no air conditioning in hot Austin summers. Or I guess at that time it was in spring. But it was things like that that I look back on and go, man, that was trying. Let's just put it that way. But I look back now and I kind of laugh about it, because it's like this camaraderie building that also happens. Some of those people are still here, I still work with them, and I built relationships with them, and you build those friendships that last a lifetime through trials like that.
There's a lot that a producer does. I think it'd be easier to list off things that a producer doesn't do. But one thing that we don't do is development, right? We don't actually make things, but we are cheerleaders for everybody who does. We create and maintain the schedules and sync with the teams on a daily basis and make sure that they don't have any things blocking them or anything that may put their work at risk. And then if they do have things that are blocking them, we will be the ones to communicate with the various people around the studios to help ease that burden and remove that obstacle.
For those who may remember, at last year's CitizenCon, we did a big old presentation and showed off the new hair shader and the hair tech. The tech is all there. It's basically just content at this point. Right now, the character team is focused on applying that shader to all the Squadron 42 characters and prioritizing those. And then after they're finished up with that, the sky is the limit as far as how many different types of hair and beard, new hair and beard assets, we can implement. So Gareth and Dan and myself are just waiting, itching to create our true selves in the 'verse. And we just can't right now. It's just so sad. But it's getting there. It's coming.
TL;DR3.7.1 is on the PTU, at least one more point patch is wanted this quarter, and there is a push for quality-of-life fixes in 3.8, though it's unclear how many will fit.
Yeah, so 3.7.1 is up on the PTU now. When we went live with 3.7.0, there were some bugs that we definitely wanted fixed, but we wanted to go ahead and get 3.7 out the door. So we're working towards those things, and we're trying to get that live. And then, looking ahead to the rest of this quarter, I think we definitely want to do at least one more point patch. And then we obviously have 3.8 at the end of the year. And you're right, there is an absolute push right now to get more focus on quality of life fixes. Things like making quantum travel work properly. Sometimes there's lots of bugs there that are causing issues that have knock-on effects to interdiction as well. Interdiction, I know, has been a frustration, and so making that a more enjoyable experience. There's issues with the ship HUD and being able to actually understand what's actually happening in the ship, and so we want to look at that. Improvements to flight and FPS AI, making sure that the load and save feature is working well and you actually have new areas that you can log out and log back in and you'll spawn in at those areas instead of just Port Olisar. Then a myriad of other issues, things like ships not dropping cargo when they're destroyed and police turning up at the right time, and security and stuff like that. There's plenty of things on the list that we were looking at that we definitely want to push for in 3.8. We'll see if we can get them all, because we're still trying to figure out how we can still deliver some content in 3.8 while at the same time balancing the quality of it.