10 for the Producers

Transcript by StormyWinters, Erris, Dolvak, and Myself

DV – Hey everyone, welcome to another episode of 10 for the Producers. I’m Darian Vorlick, production coordinator on the Arena Commander Design and Engineering team, and with us we have…

LO – I am Lisa Ohanian, and I am a production coordinator on the Ship team.

DV – So first off we wanted to thank all the subscribers for making this content possible. Without you guys we wouldn’t be able to deliver this kind of exciting and interesting content for you all. So, lets get started with some questions.

(0:42) MF140884 asks:

Nowadays it’s seems to be a common thing in gaming industry to set a release date for a game and than either release a half finished product or postpone the release date over and over again. What are you going to do to prevent anything similar and what can be the reason for that phenomenon.

LO – So the answer to the first part of that question, what are we doing to prevent this, everything that we can. The reason you’ll see this sometimes is because you’ll see games, usually ones with bigger publishers, that have committed to retail stores, committed to marketing dates, a year, a year and a half in advance, that means those games have to come out those days, no matter how much polish they get, or maybe don’t get to do. You’ll often see those games release patches or something later on to help bring things up to where they were aiming to be. On the flip side, you’ll see people push their dates back when they can, because they’re seeing the trajectory, and the features they might have added or things that didn’t turn out the way they might have wanted, and in order to keep quality high you have to push things back a little bit, or else you’re one of those half-finished products that you guys are asking us questions about.

So it’s always kind of a give and take.

DV – On top of that, if anybody’s ever preordered a game before, you’ll see, lets say Amazon, you’ll see a release date a year ahead of time, before any kind of release date is actually published, and a lot of times those dates are actually set by the retailer in anticipation of what the game’s release date is going to be. Now, interesting about what we do at Cloud Imperium, because we don’t have a parent company, we’re not beholden to marketing deadlines or publishing deadlines. We pretty much set those internally. And those dates are set collectively by the entire company, whether it’s Chris Roberts or the Marketing team, the Development team, the Production team, we all kind of have a say on when those dates are.

So, with the case for Gamescom, it was very obvious that our deadline was Gamescom. We had to have that finished for Gamescom, because we couldn’t push Gamescom back, so you’ll see a lot of scrambling to get that done. So it depends on what the deadline is, what is it for, and how badly do we need to meet it. If it’s a deadline that can be moved and we feel that the quality is going to suffer if we release it right now, then clearly it’s better to push that deadline back and make sure we reach those quality benchmarks.

LO – A lot of games will also have sort of an internal range, and they have the luxury of not mentioning their game or announcing it until they’ve decided, okay, yeah, we can definitely make this date, which is something we don’t really have the luxury of, since we started engaging our backers so early.

DV – Yeah, our game is very transparent.

LO – It’s good but it’s also challenging.

DV – You can see every little thing that we…

LO – Every second.

DV – So, lets go on to the second one.

LO – I liked this question a lot.

(3:44) Archilele asks:

How many individuals typically touch a ship in some way before it is shipped?

DV – That’s all you.

LO – So, I actually thought this is a really good question, and I kind of took a few seconds to work backwards and see what I could come up with, because even I didn’t know. For even a smaller ship, actually for a smaller ship, I think it would be a minimum of probably 30-40 people. And this counts everyone who is in the initial design meetings, the initial art review meetings, any concept artists, this includes the person doing the modeling and the lead who’s going to be guiding them through the modeling, even if they’re not doing the modeling themselves. So everyone who is going to be touching a ship or giving guidance directly on a ship, a smaller one, assuming you can keep the count down in most of the areas, like, minimum of 30 and 40, and that’s before QA and that’s before bugs. Usually when that comes along those numbers go up a lot, because you have a ton of people touching the ship to make sure everything is the way we need it to be. When bugs come in you don’t always get the original artist or designer or programmer who worked on it, sometimes you get who is available and knows how to fix that kind of bug, so it can really balloon up at that stage.

But if we’re just talking about the development stage, very first draft before it goes to QA, the pre-production, the production, about 30 to 40 people for a smaller ship.

That doesn’t include marketing or any of that. That’s just development.

DV – After that, it goes through a lot of hands such as marketing, making sure that our marketing plans are correct, making sure we have the pricing structure in place, making sure that once it’s post production, that QA can actually test it, and… I haven’t thought of that. Even if the original artist isn’t available, whoever’s available to fix things, fix the bugs,

LO – That guy can fix textures, so lets give it to him.

DV – So lots of it’ll go from Daniel Kamentsky who’s one of our artists, may end up doing…

LO – Some touch-ups on ships that Gage made, he hasn’t seen the ship before but he knows how to fix that problem.

DV – As long as they have the skills to do it.

LO – Next question.

DV – Ooh, I like this one.

(6:00) Gravy asks:

Any tips for setting realistic time frames, especially when dealing with something the team hasn’t done before (sounds like a lot of the netcode work and server tech is pretty uncharted waters)? Would you consider it better to work in a certain amount of flexible time to the initial schedule for when things (seemingly inevitably) run over, or is it more like a plan runs off track and you start fresh from where you are now?

DV – This is pure production work right here. Our job is to create those calendars. One of the things Lisa has is a calendar of all ship development, and the interesting thing about production, is the moment you make a calendar, it’s immediately out of date. Because things, reality happens. Things change. People’s schedules change. Resources become available or don’t.

LO – It’s more of a living document. You change it and you update it every day. There are definitely periods, especially early on, we give a little more flex time. And then as we flesh things out, we can predict a little bit better, usually, against other ships we’ve done. I’ve definitely seen situations where we have ship concepts coming down the line, and we know that some of them are going to have some new unique functionality, we’re going to have to flesh out the gameplay that comes along with that, and we’ll talk to marketing about this and we’ll say hey look, we can’t predict this ship for this time, but probably around this period. And they’ll say okay, well, let’s see how that progresses. And then as things flesh out, we’ll decide which ship to plug into that date depending on how it goes.

Luckily we have a good marketing team who’s willing to be reactive. When some ships come in early or, more often, a little bit late…

DV – On top of that, a lot of the tech is very similarly related. For example, we’ll use one of our animators, Mark McCall. If he has to animate a gun shooting, and the new ship that we’re working on has a very similar gun, if historically it’s taken him 3 days to animate it, then we know roughly that it’s going to take three days to animate this other weapon. So, at least we have a ball-park estimate of what time frame it’s going to take.

Now, if it’s something that’s completely new and unprecedented, let’s say we need to create some kind of instant repair beam or something, that’s not an actual feature I’m just hypothetically throwing it out there…

LO – Yeah I was thinking that someone’s like, ‘What is that?’

DV – If it’s something we’ve never done before, what we do as the producers, we ask those developers ‘How long do you think it’d take to make this?’ and we get their feedback. If we went to a designer they might say, ‘Okay, it might take me a day to come up with a concept, another day to write the full design brief on it, and then maybe art may take two days,’ so we kind of get their buy-in on how long it’ll take, and we just update our schedule as we hit those dates.

LO – And we always try to ask them even if we do think there’s something similar that we can compare to, because our job isn’t to create any of this, it’s to facilitate everything. And you never know when we’re going to say hey, this weapon’s a lot like this one, so it’ll probably take three days right, and Mark’s like, hold on, no, you didn’t account for the fact that we haven’t done this yet, or it’s on this kind of ship which is totally different, so we always, every single thing we have to check and check in again.

DV – Another interesting point is that, as we go through more and more ships, we learn the processes as we go. So, one process, if we see that historically it has taken three days to do a certain type of feature, we’re going to become more and more efficient as we go through, so what might have taken three days historically, we may have it down so pat that it only may take a day and a half to two days. So, it’s one of the other advantages of having producers on hand, and also keeping these schedules up to date. We see the trend of how long it’s taken before versus how long it’s taking now, we can see where those increases are, where we need to give more time versus less time.

LO – And that’s, we’re seeing that on the component pipeline right now, which brings me really conveniently into our next question. Logical Chimp.

DV – Are chimps logical?

LO – This one is.

(10:05) LogicalChimp asks:

Last year there was a lot of talk about the ‘Component Pipeline’,and how it was expected to ‘start pumping’ in the new year. Since then, all has gone quiet on this front. As such, can you give us an update on the component pipeline, and when we can start seeing something other than weapons and shields in the store?

LO – So, I can’t tell you when you’ll see stuff in the store because that’s marketing, that’s Ben’s realm. But we actually have been making a lot of progress on components lately. If you saw ShipShape a few weeks ago, we had Elwin on and he talked about plans for components and he has been working on that nonstop ever since. We have our pipeline fleshed out in excruciating detail for art and design which is fantastic. I took a break from working on our til the end of the year components schedule to come down here and do this. We’ve been having a lot of meetings about it. We have at least a first pass concept of every component type in at least one size, so we have an idea of what the norms are going to be and the visual cues, because obviously the smallest and largest size shield generator are going to look very different. But we’re hoping to have visual cues in there so you can look at either one and say, ‘Oh, that’s a shield generator’, right away. So we have the basic concept art fleshed out to give those cues and we have Gage working on a lot of the whiteboxes right now and Elwin supporting him.

LO – He’s fantastic. He’s starting the design on a bunch of that stuff too and again, like we were talking about before, he was saying, ‘For the first one give me X amount of days and the next one give me just half that’ because we know after that’s all been fleshed out it’ll be a little bit easier to predict from that point on. So, I know we’ve been kinda quiet but we are making progress, it’s just not as shiny to talk about as ships all the time.

DV – Like Lisa said, it’s being worked on, we haven’t forgotten about it.

LO – No, not at all. It’s like my day to day.

(12:09) Mookie asks:

It’s great that new releases of AC are always fixing bugs and introducing new stuff, but my question is when are we going to start seeing some of the stuff still broken from way back fixed? Examples would be collision issues with ships or items in our hangars, the greycat not moving in the Aeroview hangar, Wingman’s voice over is gone. I realize these are not game stopping or uber important compared to new supercool features, but I would think that existing problems would be worked at least at the same time as new ones.

DV – This is actually something that came up in a production meeting with our senior producer, Eric Davis, Lisa was there, also our UK compatriot, Ricky Jutley.

LO – With the hair.

DV – Yes, both our senior producers have epic hair.

LO – Epic hair.

DV – One of the things we have in our test management program, JIRA, is a backlog of issues that we’d like to eventually get to. What this backlog does is serves as a wishlist of issues that may not have been touched in a long time.

LO – They’re all rated by priority from blocker to critical, all the way down to trivial.

DV – What we have to do as producers is gauge on how important those fixes are. For example, if we’re working on making the Retaliator flyable for GamesCom, a little piece of clipping texture in the hangar is not going to be as important as the tech to make the ship flyable. Granted, these are two very different disciplines. As producers, we have to dictate what these…

LO – Who is [assigned] with what…

DV – Exactly, who’s going to be working on what and if we find we need resources dedicated on some important aspect of Arena Commander, than those purely aesthetic bugs are going to take a backseat until we get this finished. Now, going back to that production stand up meeting we had recently is that we’re starting to really look at the catalogue of back issues we have and now that we have some breathing room in preparation for 2.0, we really want to start addressing some of those. Whether it’s aesthetic or mechanical or technical issues, to make sure when 2.0 comes out that these are much reduced and not as problematic as they have been in the past.

(14:17) Acaro asks:

How much of the work you split up between the different studios can really be done separate and how much of it requires multiple studios to work together on one single aspect of the game? How do you manage to sync the work done by the different studios that are probably also in different time zones?

LO – This is a really good question, and actually one of our biggest challenges. So, when we’re deciding what work needs to be done for something, take Gamescom for example, we try to divvy up work in a way that makes sense. We’re not going to have an artist and a designer for the same ship working in tandem while one’s in the UK and one’s here, because it just, they can’t communicate, they can’t have that back-and-forth.

DV – Logistically, it’s impossible.

LO – They don’t necessarily know the status of everything, and it takes 8 hours to find out the answers to basic questions that might be blocking you. So, we really try and be smart about when we’re breaking up the work. There were a lot of ships… again for example Gamescom, UK did a lot of the large world tech, and a lot of the infrastructure for what you saw at the demo, and they had been working on some of the art for a lot of the ships, and they have the bandwidth of course, and the talent, to have done a great job with the tech setup and everything for the ships, but since we knew they needed to work on it, they just handed all of the ships off at a certain part, when the art was done, for us to do tech setup. Because that’s a very clean breaking point. There are parts in the ship pipeline where everything is intertwined and things are just coming in everywhere, but that actually, when they handed things off was a very clean breaking point to give to us, and we had all of the context just from looking at the files to finish everything up. It made sense for us to take on those ships because we would have everyone locally working on these essentially mini-features, and they could all focus on what they were going to need to interact with the most, between each other.

DV – On the flip side of that, there’s a lot of times where there is a lot of international collaborations. Steven Humphreys, from the UK office, is one of our engineers, and what happened, he would work on part of this GOST system, and every day the design and engineering team would have a series of handoff emails where we would send an email at the end of our day to the UK office on what’s in progress, how much progress has been done, what’s been completed, what bugs have been fixed, and so then the UK would use that as a point of departure for what they needed to continue off of, or what they’ve started, at the end of their day, they send us another handoff email, and that gives us an idea of what they did. So with GOST, whatever Stephen Humphreys had worked on, whatever he’d finished after that, the email would reach us, and then Kirk, Dan, Mark Abent, would then pick up from there, so they would get the emails for what stuff on GOST had been completed, and they’d be able to run with the ball until the end of our day. So, there is a lot of international collaboration, it just depends entirely on what that feature is. Some of it doesn’t require collaboration at all.

LO – And while it makes sense with the time too, we also just to piggyback on that, that was a really good point, we have our CG supervisor, Forrest, who’s been really championing us getting more detail into our bug tickets and our database, and that way you can not only go to someone and look them up and say, this is what they’re working on, but you can go in there and you can see what sub parts of it are finished and what aren’t, how many hours is the task going to be, how many they’ve logged so far, and this is completely invaluable between studios when you want to see how things are progressing and when you can task your developers appropriately.

DV – Ideally, through JIRA, whenever a developer leaves a comment on what work they did, if another developer opened up that ticket or that task, they’d just see everything, read that comment, they should be able to pick up where the last one left off.

This next question comes from…

(18:07) Dastardly asks:

Within the design of the simulator (SC), will there be anything other than support for networked devices like tablets and the like?

i.e. multiple monitors with touchscreens etc.

I have a 4 monitor simpit and two of the monitors are touchscreens and would love the immersion of interfacing with cockpit controls.

DV – I like this question.

LO – Because that’s an awesome idea.

DV – It is. While tablets are something that are in the works, we’re not far enough along to be able to give a solid answer just yet. So, whether we’d like peripheral devices to have some kind of functionality in game such as if they want it to span four monitors with each particular monitor having a particular command, like one’s for a side-cockpit view, the other one’s for an aft cockpit view, it entirely depends on what Chris wants, the vision of the game would be for, what he wants in the vision of this game. So, while this is more of a design related question, it’s one that we see quite a bit on, will we support this, will we support that, and the answer to that is pretty much, we’d like to, but we have to see exactly how the game evolves over time. So, it’s not a yes or no question, it’s just, we’re going to have to wait and see.

LO – And it also has to do with, whenever there’s a feature that we want, we always prioritize the more important ones like, to use Gamescom for an example, do you want to avoid this little clipping the corner of your shoe over here, or do you want to make sure the ship explodes? We need to focus on the things that are a priority, and once we’re far enough along on those we can present schedules and budgets to Chris, and he can make a more informed decision.

DV – Like, if we have, someone has two monitors, we want to make sure that the monitor actually shows the cockpit, and if someone sits down at another computer, they should be able to see the engineering screen, or the weapons screen. We want to make sure all those features are in there first before we start adding on more and more complex features. Functionality first, cool aesthetics and luxury items maybe later.

(20:10) AragornBH asks:

Since Star Citizen is first of its kind crowd funded project that is breaking new ground in computer game development, and Chris Roberts has asked you to not just build a game but a universe. Do some members of your team get over enthusiastic? How do you keep the artists, writers, and designers from implementing so much detail on ships, stations, planets, or characters that they risk derailing the production schedule? Have you avoided hiring less experienced people because you don’t have time to train them how to avoid issues like those described above?

LO – I want to address the second part of that first…

DV – That’s what producers are for!

LO – Yeah, that’s what we’re for. If we have to avoid hiring good people that means we’re not doing our job. We have definitely not avoided hiring less experienced people. Like, actually have a very high number, for a AAA studio, of people who are a little on the less experienced side but have the talent and the know-how and they just maybe don’t have that credit yet and it’s kind of their first big break which is really exciting and it also kind of brings – even though you have to rein in on certain things, it also brings a really unique perspective. Whereas, someone who has been in the industry tackling a certain problem for 10 years now, you might get someone else who comes in and maybe they don’t have all of the experience to bring to the table but they have a fresh perspective or spin on how to tackle this problem or how to solve this thing in front of you. We have, like I said, a slightly higher number than average of less experienced people but the talent is there and that’s kind of what we look for first I think… and we do have a lot of experienced people mixed in. I actually think it’s a really exciting mixture of people that we have here.

DV – So, that’s largely what producers are for – to keep everybody on track. But, to break down how our organizational hierarchy is, at least within the development side – I’m going to use the design team as an example – We have our design lead Dan Tracy, within the LA office what he does is he helps kind of steer what features we’re going to be working on and how to break those down into individual tasks to make it a lot more manageable. So, for example he may task Calix Reneau with writing the design brief on something and he may then give it to Kirk Tome to make that particular… using a ship, he would make it flyable. Matt Sherman may be working on the components of that ship. So, everybody does have their responsibilities on what they’re going to be doing but those tasks are then going to be broken down by the lead and what production does is make sure people are staying on those tasks.

LO – Just to chime in, the funny thing I think is we probably have that problem… well… problem… We probably see that coming from Chris Roberts most because he has so many ideas in his head and such a vision for this world that we’ll see him bringing up these awesome ideas and we’ll say, “Oh, that’s so great! This is what it’s going to mean…” And then we get to make an educated decision about how soon and how we want to implement something.

DV – But on top of that, I mean… when you have a room full of very creative people, they want to work on everything at once. So, you may have one designer who is working on one specific feature – once he is done with that design brief he may be completely filled with creativity at this point and be like, ‘I just want to starting working on this and then I’ll work on this,’ which starts to deviate away from the main goal of whatever fix version or patch we’re trying to work towards. So, it’s up to the design lead and the producers to say, ‘You still need to work towards this direction. Once we’re done with that, maybe we can actually squeeze that little bit of creativity in.’ So, they are creative people but it’s our job to keep them on track.

LO – It’s an art and a science working with leads to make sure people get an appropriate amount of time – not too little and not too much.

DV – Yup. Because if you don’t let them spend some time on it, they get a little burnt out. So, you do want to make sure they’re getting – I don’t wanna say rewarded, it’s not like a doggie treat or something – but we do want to make sure that they have the ability to exercise that creativity while still maintaining a goal and perspective on where we’re trying to get in the game.

LO – Alright, we’ve got another question. This one is from Kinshadow…

(24:19) Kinshadow asks:

You guys have focused a lot on the ship pipeline in the past. I was wondering if non-artistic elements of the PU undergo such rigor? For instance, storylines and mission generation: is there a pipeline of writers -> gameplay designers -> programmers for such assets or is it more typically ad hoc?

LO – So first off the ship pipeline is not just art. The majority of it is art because that is what tends to take the most time but that includes everything from ‘I have an idea for a ship’ to in your game working in Arena Commander and eventually the full Star Citizen game. So the tricky thing with ships is: ships are going to permeate the entire game so we have to have the PU director weigh in, we have to have everyone who touches every module weigh in to make sure that the way we are doing ships now is going to work with everything that they have in mind for their chunk of the game. For that reason I think it requires a lot more checks and balances for ships, however, everything has it’s own pipeline. A pipeline is a fancy way to say process of how things get done.

DV – Or assembly line.

LO – Yeah, so there is a pipeline for everything whether or not it has been formalized and it consists of people passing off different kinds of work and stopping and making sure the appropriate people are reviewing along the way.

DV – A good example of that is we have a character pipeline, we have an animation pipeline. What we like to do between each phase – for example we’ll use the ship one – is after we are done with the whitebox or before it goes to graybox or any tech set up there is a series of checklists that we have to go through, did we do this? Did we complete this? Did this person look at this? Is the lead or supervisor getting ready to sign off on it? Does production sign off on it? To mention Lisa’s checks and balances there are a series of protocols in place to make sure certain aspects are touched upon. Same thing with the character pipeline. Same thing with the Arena Commander pipeline. Anything design or engineering related. If it’s code then we have our code leads peer review the code before it gets checked into the game. So there are processes in place for all these and all the pipeline is, like Lisa said, is a process from start to finish. What does it look like? What steps are we going through? and is it going to be the same thing every single time we design that same feature? So every ship will go through that ship pipeline, every character will go through that character pipeline.

LO – And the more areas something touches or the more modules it touches, the bigger it gets. There’s a lot of talk about the ship pipeline, so many people review it and it touches so many things, that is why we talk about it so much. There is a little more to talk about than certain other pipelines but everything has a pipeline.

(27:05) Sultan asks:

Now That one of the mayor director left for blizzard, that let us thinking that he didn’t have confident in the project. Can you please let us know if you will replace him with someone better that will have the passion for this project like we all have? Ty

DV – So, I want to clarify that every single one of us has passion for the project and every single one of us wouldn’t be here if we didn’t have that and share that same passion that Chris does.

LO – Just because people have left, it’s not like if you’re here you have passion and if you’re not then you don’t. We’ve had people leave for personal reasons, we’ve had people leave to pursue dreams jobs they’ve had since they were children. You can have passion and confidence in more than one project at the same time and just because you can only have one job doesn’t mean that…

DV – On top of that, mobility between companies is a very normal thing especially during the lifespan of a game cycle. At any video game company you’re going to see people come and go, it’s a very mobile industry that you see a lot of hiring and you see a lot of leaving. So, one person leaving doesn’t necessarily mean a nail in the coffin for a project or that the project is now diminished. So, we’ve hired actually quite a few people within the last year and all these people are equally as passionate as the others. So, you’re not going to see a diminishment in the quality of the game, you’re not going to see less passion because like I said everyone of us is absolutely passionate for it.

LO – The producers who have left recently, just to add, have all been here at least a year or many years, since the beginning of the project. Frankly, I would be worried if you saw a bunch of producers come on, stay three months and leave. That might be a sign of….

DV – I think it’s a sign of lack of commitment.

LO – Yeah, lack of commitment but that’s not what you’re seeing here at all.

DV – Everybody here is die hard and passionate for the project. We’re here for the long haul. Some people like Lisa said have to leave for personal reasons, some people have to leave for professional reasons, some people may be offered their dream job out of state or out of country. It doesn’t mean they’re disappointed in the project, it doesn’t mean they have less confidence in the project. They have their own reasons. So, ultimately we support people if they want to pursue things outside of the company, we’re sad to see them go and thankful for the contribution they’ve made…

LO – We still have great relationships with all of them.

DV – Absolutely. I still talk with a lot of old friends who used to be here. So, if you or you know someone who has the skills and passion to help bring this project to reality, closer towards the vision that Chris wants. Please do check out the website, see what opportunities are available. Many of our own artists and employees came from and who were fans before, backers such as artist Elwin who helped contribute to The Next Great Starship.

LO – And Gage and Dan…

DV – Yep, so we hired them because of skills they demonstrated to us so if they have the passion, if they have skills, please apply. We would love to see you onboard. It’s a great team and great project to be a part of.

LO – Except for this guy.

DV – Yeah, I don’t know.

*LO laughs*

DV – It’s hard to sit next to her.

LO – You don’t sit next to me anymore.

DV – Thank god. So, once again thank you for joining us for this next episode of Ten for the Producers, I am Darian Vorlick.

LO – I’m still Lisa Ohanian.

DV – We would like to thank the subscribers for making this exciting content possible, without you guys, again this wouldn’t be possible so it is very much appreciated and thanks to the backers for making Star Citizen a reality. As you saw with GamesCom, this is an awesome project to be part of and we’re absolutely proud to be a part of it.