Hello Citizens! It’s time for Episode 8 of 10 for the Producers!

10 for the Producers

Transcript by StormyWinters, /u/nelerath8, and Myself

Bjoern Schwartz asks:

Do you think development of Star Citizen will become more stable(better to predict the timeline) after the FPS, Instancing, Large World and AC 2.0 are finished? Or will be a lot of friction when all this is integrated? How do you balance this problem of integrating new features and stable/predictable development between the main development branch and our live/PTU branch?

TD: So, that’s a good question and actually you know high five we got our first producer relevant question on the show… EKD: Woohoo! TD: Yes, so to answer your question. Really some of the things you highlight in here are things like FPS, Instancing, particularly Large World, and what we’re really talking about when we talk about those things are new features and they’re definitely, for the CryEngine at least, new R&D features so they require a lot of work from the programming team and there’s an end goal of what they want to achieve that’s kinda set out from the beginning but the route there is not immediately clear from the very beginning. So, it’s something you kinda discover as you go, so one of the things that you will see is that those features are far less predictable. They have a lower predictability quotient to coin a term. So, yes, that does increase our inability to predict the timelines on these things and then it cascades into other things. Well, if something relies on Large World and we don’t quite know when that’s going to be then we don’t quite know when the dependent thing is going to be and as you get closer and closer it all becomes more clear and it’s kinda our job to maintain and update, maintain and update and keep as clear a picture as we can at any given time. So, to answer the specific question of will this improve the predictability once these things are done. The answer is as we get closer and closer to the end of the project and there’s less and less R&D and less and less new feature work and more just content pushing that becomes infinitely more predictable. Content is something that is much, with the exception of design content, but I’m talking raw art assets or we need to make these levels, I mean that’s much more easy to waterfall and it’s far less unknown, so yeah that will get much more predictable and much more quick as the project picks up and we’re kinda hitting – at this point we’re around the knee of the curve when we’re going to start doing more just straight content production and cut down on the feature production. So yeah, I hope that answers your question and thank you it was a good one. EKD: Yeah, good question. Good segue, predictability.

jmack asks:

When working on timelines, how do you account for the unexpected? I imagine game development timelines would have lots of interconnected dependencies and a delay in one track of work might hold up another track. Do you just build in extra time for the inevitable issues that come up? Are certain tracks of work more predictable than others?

EKD: Fantastic question and a good producer question as well. Yes, I would say what this comes down to is the more comfortable you are with the team and the decision makers of your team will help kinda guide this. For me, for scheduling a big part is try to capture as much as I possibly can. Right so, it’s one thing just to say, you know, you talk to an artist or a developer and you say how much time is X going to take and they’ll say five days. You go, great, five days. Throw that in there but there are some things that go around that like, does that five days include just work, desktime, no meetings, cranking through work. Does that include iteration with your lead, with your supervisor, with, you know, our entire stakeholders… TD: The art director, Chris… EKD: That’s right. Does it include any kind of other buffers we might need in any other independent connections and if that’s the case then yes, that’s the five days I schedule and then we can schedule the whole thing out that way, if we understand our mass amount of work. Like you said, when we’re not necessarily R&Ding and we’re kinda in predictability, as much as that word isn’t a real thing, it’s a thing we try to use, you can get a little better understanding. Once you understand your team, once you understand the decision maker process, once you understand the dynamic and the dichotomy of your group this becomes a little bit better. I think the quote goes: A battle plan goes out the window after the first shot is fired…. TD: Yeah, after first contact with the enemy. EKD: Yeah, so every plan does go out the window and as producers our job is to iterate with that plan and those ideas and predictability is a word we don’t get to enjoy much in game development. In any entertainment creation, I mean we’re not necessarily doing something new but when you’re trying to do new stuff you don’t necessarily have a business model to follow. TD: Yeah, even if it’s just new for the team, new for the people doing it. Actually one of the things you said is a really important point to make, that a lot of people have the impression that, oh, you sit down at the beginning of a project, you lay out your budget for the entirety of the project, you lay out the schedule and then you just sit and you track against that. You’re in your ivory tower somewhere and you kinda survey the battlefield… EKD: You don’t talk to anybody, you just sit there and watch. TD: It’s much more like a World War II sergeant throwing a grenade at the front line, you know, that kinda thing. It’s much more moment to moment, I think. EKD: For sure, you know as much as I think we want to be predictable as producers are and scheduling, budgeting, it’s just very hard to account for that. So, its a lot of work, a lot of iteration, a lot of communication, and a lot of understanding in how the plan can move. So, once you understand all the players that are involved you can – you know, once I started doing schedules on projects on things I’ve done in the past, I’ve done it a few times or I’ve worked with the same group multiple times, that helps a tremendous amount. Like I know, Tim always does this, Ashley always does this and Fred always does this. I know some of their quirks, great quirks that make them awesome at their job, and it helps me plan better as a producer. So, I hope that answers your question. That’s a great question.

Newt asks:

Is it possible to give an example of how long each aspect of a feature or asset takes. For example, what percentage is spent in concept, design, coding, and polish, etc? Does each asset/feature follow a similar breakdown or are some more resource heavy in certain areas? If so, are there any indicators to each asset taking longer at a certain phase?

TD: So, this is a good one… EKD: This is good. TD: I think one of things first off is know that they’re all going to be different. Every feature is it’s own unique special snowflake. Generally you can categorize them and say – ships for example, ships will probably, if it’s this ship or that ship will probably spend commensurate ratios of time in each step of the pipeline. If it’s this radar system versus this missile system, yeah, it gets a little more nebulous. So, I guess I think a ship would be a good one to break down to answer his question. So what percentage of time was spent in concept, so totality of a ship I would say probably 20-25%, sound about right? EKD: Yeah, and you know concept, to speak to concept, I think that’s a place we want to spend a large amount of our time. Right, we get all of our designer questions answered, our gameplay groups questions answered, our art leaderships questions answered. It’s the ‘cheaper’ portion essentially of the whole creation process. TD: That’s a really valid point, it can be viewed in the same way as pre-production for the entirety of the game. That’s where you get everything out of the way so everybody else can just execute without having to stop and go – “what if the bike needs a bike chain…” EKD: Yeah, yeah exactly. So, 20-25% I think that’s good. TD: Then the design side, well design is kinda wrapped into that so let’s call it 25-30% for concept, design, animation review, all that happens during that phase. The coding side, you know, in this case I would say the modeling for the ship and that would probably be about 70% of your time. That’s the lion’s share. EKD: And you want spend a lot, a lot there. That’s the look, that’s the feel, that’s it’s going to work an engine, that’s everything, right. TD: Than you know, audio, VFX, last 5%. EKD: Yup. Very important part but definitely. TD: That is actually one thing in production that always tends to happen and something to keep aware of and combat if you ever want to be a producer is, VFX and audio are the oft forgotten but very important but last step in every process. EKD: Yes, going back to the predictability part of the last question, as things you hope won’t push but as things might push different aspects there has to be an end date somewhere and so a lot of times that end date doesn’t move and everything gets kinda crammed down and you can talk to our audio team and our effects team… they kinda plan on it which you don’t want, you want them to have the ability to be as creative and make the coolest thing possible too. So, some of the ways we’ve kinda combated that is we get them involved as early as we can, like maybe back in concept, like just start thinking how this ship might sound or think about how this character… TD: Look at what the moving parts will be… EKD: Yeah exactly, for when it gets to animation, totally. TD: All right, you’re up next.

[TAC] BuzZz Killer asks:

When it comes time to staff a project, how cost effective is it to outsource vs hire a new team member? How is that decision made?

TD: For the record, I really like this question because this is a debate in the industry as well. EKD: Yeah. For me, a lot of times is just comes down to: How much time do you have for the project? How much money do you have for the project? When does the project need to be out? Those will obviously guide the quality of the project. But once you understand at least one of those three – or as many of those three as you can – it helps you make a better decision., right, so you take into consideration hiring people locally versus hiring people regionally or nationally. You look at – for a lot of things in pre-production it’s a big ramp up, you’re building a lot at the beginning but you’re not necessarily at the end, so it does make sense to staff up but it does it make sense to staff up for permanent staff, forever? Not necessarily. So, I think the idea is to try to get as many people in the game industry jobs and to keep us all employed and to have a great time making great games. But the realities do come down to: How do we make this for the best price possible but hit that quality bar we really want? TD: Yeah, and I do think outsourcing gets kind of a bad rap in our industry because it’s like: “They took our jobs!” or “It means lower quality”. And actually there are a lot of super talented people out there that do outsourcing work and so it doesn’t necessarily mean lower quality. The taking of the jobs thing is the other one that I wanted to address too which is: If you have a guy like Chris Smith. Chris Smith, Lead Vehicle Artist, makes some beautiful ships, made a lot of the beautiful ships that we have in the game – to ask him to make 34 variations of boxes, barrels, and potted plants is… you know, maybe he’d dig it… I don’t know, I’m not going to speak for Chris, but it would be a misuse of his talent. Right, because you can’t get anybody to make one of the ships that he makes but you can get a lot of different people that can make those potted plants or those boxes. EKD: And for me, giving somebody with more of a junior… or just getting into the industry, the opportunity to work in a game – that’s perfect for them. TD: Exactly. EKD: It gives them a sense of: How does it plug into the game? How does it fit in the master system? TD: What’s the pipeline… yeah. EKD: Yeah. Right out of school or just looking for a job or somebody between some work… absolutely. Trying to balance giving as many jobs as we can but also the realistic goals of the project without getting this ballooned… anything, budget or schedule, right? It’s a balance. TD: Right. That’s another thing that a lot of studios struggle with, I mean in this industry for longest time it was just feast or famine, right? So you ramp up, up, up, up, up… and then you finally have enough team to ship the product… and then a quarter to everybody gets laid off because you can’t sustain that. And then there was a popular idea: “Oh, we’ll have two teams simultaneously at a studio so that when one project is in pre-production the other project is in full blown production and we’ve rolled most of team 2 on to team 1 and then once team 1 ships then everybody will roll over to team 2 and we’ll do pre-production on team 1. And that one actually worked for quite awhile and that has gone better, I think, but one of the things that outsourcing allows us to do – and this has been really important to Chris – is that you want everybody that you hire to know that you’ve made a commitment to them. The company has made a commitment to them to take care of them, to nurture them, to grow them in their professional career and in exchange we get this beautiful art, we get beautiful code, whatever it is that that transaction is. And you want to be able to have people have security and trust and faith in the job and outsourcing is a tool you can use to scale without risking not being able to make good on that contract. EKD: Yeah, I think to talk to outsourcing for a second longer: When we say outsourcing we don’t just mean taking jobs away from people locally or whatever word you want to use because I think that it gets negatively branded. The outsourcers we use – some are local. They’re just called outsourcers because they’re not in-house. TD: Yeah. Guys like ?Ether?. EKD: You got it. There’s full teams out there that work with multiple studios – they hire on artists and programmers or whatever it is and then they work with companies like us to build their games and it’s actually a very large industry. A lot of people are getting jobs because of that outsourcing opportunity. TD: That’s the other thing to point out is that their entire business model is predicated on… they make a social contract with their guy that may be a freelancer otherwise which is really feast or famine and unstable and he gets a regular full-time job and they’re going out and they’re hunting for work basically… getting 20 projects at once and that’s how they maintain their company’s stability. It’s an interesting ecosystem. You know, I never realized how much of a business/production nerd I was until I started getting these kinds of questions that get me super excited. EKD: That’s what we get excited about. To kind of go back to your original question, we look at all of those factors and then whatever makes sense for the project at the time. Because no project is the same, even when you’re making… I’ll throw out Madden 25… there may be some kind of formula but it’s still a new project, new tech, new artists, new players on the field. There’s still new stuff to it, so it all depends on the project. TD: That’s gotta be horrible. They’ve gotta remake those jerseys every time. EKD: Every time… new pipeline, yeah. Horrible… or you know… fun if you love jerseys. TD: Yeah. I just like to think that somewhere out there is a guy who did nothing but make hubcaps for GTA. EKD: *laughs* Sure did. And he loves it. Full time job is making real hubcaps, part time job is virtual ones. TD: And on the weekends… he installs hubcaps on his car. *laughs* EKD: Love it.

Amontillado asks:

When delays occur in the production stream such as what’s happened with Star Marine, what are the producers at CIG doing to minimize it’s effect on the overall schedule of the game’s development? I’m aware that various modules are being run in parallel to help offset this, but are there other specific things that are being done that we may not be aware of?

TD: So, this is actually a really good question for Sean Tracy, Jeremy Masker… These are guys I am constantly having discussions with, sometimes arguments with, about what is the best way to offset and mitigate the risk that this will delay other streams. EKD: Healthy argument. TD: We do have healthy arguments – you know I think that’s another thing that’s important in production is you have to be super open to: ‘My idea is not always the best idea.’ – and everybody needs to be that way in game development in general and it’s kind of… to borrow a term from our old friends at Activision: “It’s the battle for the best idea.” And it really is true. I love having those conversations because you may think you’re right but then you get into it and… ahh okay, that’s a better solution. Anyways, back to your question. The real point of this is… yes. What we do is have an interesting stream and branch structure. So, you talk about main is like the main code stream… and actually that’s really no longer the case for us… we do most of our game development in… it can be best described in two pyramids – one an inverted pyramid and one below it, a regular pyramid. In the middle sits Main and below that we have Game Dev, so we have Game Dev FPS, Game Dev AC, Game Dev Social, Game Dev… and that’s where each of the teams works in their own little discrete area. Now, there’s a bunch of intermediate streams that are constantly synchronizing with one another and what this does is if two guys in two different streams work on the same file, it will push into here, they’ll integrate with one another, they’ll send an e-mail to both of them saying, “Resolve this. Make sure this comes together in a clean way,” and everything that is clean, stable, and beautiful – theoretically – then propagates up to main. Then it’s from main that we’ll branch out to do a release so the where we get to the upper pyramid is when we say: “Hey, we want to release Star Marine.” Which… we’ve said we want to release Star Marine… because we do. So, we then create a branch above that that is the Star Marine release branch and this is what will end up going to Public. So, that is created off of main which theoretically – with the system that’s going on in the lower pyramid in that ecosystem – remains pretty stable and we do final polish, bug fixing, and much to Sean’s chagrin… maybe some feature development, in that release stream which is then later integrated backwards once we release down through the whole tree structure again. So this is the technical structure of how we’ve arrayed our Perforce to try to mitigate the impact that one release has on another. But then there are also, you know, kind of social, psychological, or marketing impact that it does have, where you want to try to space out your releases a little bit to give a release time to breathe, to give the team focus and time to focus on that release and make sure that they support it after its release and everything else so in that way you do kind of want to space out your releases a little bit or else you’re going to burn everybody on the team out and divide the focus. Do you have anything to add on that? EKD: *laughs* No. You mastered that one. That was great. I don’t have anything to add… I think that what we try to mitigate is any individual module impacting the other module negatively. I think that’s really what we’re talking about and so as producers we are trying to find ways, as Travis has done excellently over the years, of trying to find ways to… “How can we keep pushing down this module so we can not impact each other?” TD: That’s a really good point too that you make… it does happen. We’re just trying to minimize. A lot of things in production are: “I can’t promise it’s not going to happen but I can try to minimize it happening and minimize the impact that it happening makes.” EKD: Yeah, and having as many plans in our back pockets as we can. Right, like… here’s the plan we’re all shooting for… but here’s our other 10 plans we have in the back pocket in case things… that we have in the back of our heads or part of our schedules, for sure. TD: Thank you, good question. EKD: Yeah, great!

Nostromo1977 asks:

As a senior producer, what is the most difficult aspect of the job – managing people/time, hitting schedule milestones, facilitating communication or staying within budget?

EKD: Yes, balancing all of those… TD: Yes, they’re all related. EKD: I think the hardest thing for me, I apologize for jumping in.. TD: No, no it’s your question. EKD: How dare you…(laughs)… is balancing all of those, that’s the hardest thing. I don’t think any one of those specifically is harder than the other. Each of them take different types of skills, right. So, working alongside people, leading them, helping inspire them to do great work, that takes a lot more soft skills, right. So, it depends on your ability as a producer, I talked about this in Around the ‘Verse a week or so ago was there are different kinds of senior producers. Everybody has complimentary, hopefully, skill sets that help each other work together, make a great team. So, some people are really focused on soft skills and just helping unify a team and building that communication hub, that just syncs together. Some are more technical, some love to build schedules, we all kinda have synchronistic skills, I think. TD: I think you and I kinda exemplify that relationship… EKD: Totally. TD: I’m…eh…at scheduling. As far as things go it’s not my strongest suit and I think you’re really strong at scheduling and you excel on that side. We both, I would say, have pretty good soft skills we’re commensurate in that and then your focus is much more heavily on the art and the scheduling and the pipeline side and I think you know that really well. My focus is probably more on the technical and the design side… EKD: Totally. TD: So, I think that’s why we’re a good team. EKD: Totally, I agree. I don’t think one would be harder than the other for each of us, using as examples, I think it just depends on what your core strengths are and then finding the people in your team to help round out those skills so we can all get this thing done. I think Nostromo pointed out some great points, that those are the main things we are looking at as producers. Those are the main core items and trying to come in under budget with a fantastically, greatly working team that communicates awesome, we’re hitting as many milestones as we can to get out the best possible experience we can. That’s our goal so we have to look at all those different, going back to what you said, pillars of producing. I think balancing is the harder part for sure. TD: Yeah, I think that is the most difficult, it’s a juggling act. I don’t know how many times I’ve used that analogy but it’s like plate spinning, juggling, it’s all that. EKD: Great question, thank you.

Logical Chimp asks:

How much of planning is a ‘science’ that is calculable, and how much is ‘gut instinct’ – and how do you work out the reliability/accuracy of a dev-estimate for implementing a feature?

TD: I’ll answer the last part of the question first. Every developer super different. As a producer, it is difficult to get accurate estimates out of people until you know them so the more time you spend with them and the more you can go like – ok, so 4 hours for him really means 2 or 4 hours for him really means 8. It’s not like one is slower or faster, it’s literally just the way they think about how long it’ll take. EKD: Yeah, we talked about this I think on jmack’s question, the better you understand your team the easier it becomes. These teams that have worked together for years and years and years you know exactly what they mean or you don’t even have to do it, a lot of times I would get to a sense after working with a certain team for a certain amount of time I could pre-fill their bids. Obviously, you would talk to them afterward to make sure they’re accurate but you know: I know it usually takes Jennifer three weeks for that, you know it takes… there is a science to it and that science is understanding your team and then also understanding the project you’re working on. TD: Yeah and knowing what the technical details of what they are doing. We got to a point, during the 1.0 crunch for example, 90% of the tasks that came through I could assign what I thought was a pretty good value and then look at it with the guys and they’d be – yup, yup, yup, cool. Another fun game to play for any aspiring producers out there, is play the, “What if?” game with anyone who’s giving you an estimate, especially the longer the task, if it’s a 2-3 week kind of a thing – yeah, we could probably do it in 3 or 4 weeks and it’s like oh, you feel like taking a day off? What if you get sick? What if your dog gets sick? You know, it’s kinda evil, all these bad things that can happen in your life that could derail you but there’s a lot of things that people don’t account for, it’s totally natural. They’ve actually done studies on it and I’ve read them in books which – books like Drive by Daniel Pink – which are great. EKD: That’s a great one, yeah. TD: Anyways, you as a human being have a natural predilection to underestimate a large task and overestimate a small task and so you can apply some baseline modifiers mathematically so back to your, is it calculable? Average good one is everybody works about 70% of an 8 hour day between going to the bathroom, eating lunch and blah, blah, blah so that’s another one you can look at. If I have 40 hours of tasks that’s going to be about a week and a half worth of work so there’s little things like that you can do mathematically and the rest is there is gut, especially when you’re looking at the finaling of a project you can see, oh okay what’s our burn down saying – how many bugs entered versus how many resolved. You go, okay what’s our rate of increase and change in that and you can start to do your own little math that says – ok, we’ll probably be around this date – I remember for Arena Commander 0.8, I knew in order ship we needed to get all critical and majors done and so I just applied that math and I think the date was May 30th and we ended up going on June 4th. EKD: Not bad. TD: That was back in like March. EKD: That’s not bad. TD: I was actually quite proud of that one (laughs). EKD: Well done. TD: So it’s both – it’s math and gut. EKD: You know to that point – I think experience, the reason they say the more time you’re in something, this goes with any kinda job, the more time you’re in something the more comfortable you get with that information so the more experience you have whether it’s with a team or just working in an industry or working with a certain type of product, maybe you just always make FPSs, the better it is for your bidding and your gut then reacts to that experience but the one thing I challenge people on with that experience is to always still start with experience, start with that knowledge but then add to it, break it, don’t just… a lot of producer’s get stuck in that. TD: You sit in your zone. EKD: Yeah, it’s like the technology is constantly changing, new fantastic talent is coming out of college, right. There’s new things that people are out there doing with a smaller team than you’ve ever done 20-30 years ago… TD: Entirely new ways to manage your time. EKD: You got it, so be agile enough to move with that stuff but you know, a good foundation of experience is good. Great question.

Zero Lambda asks:

What do producers do to sharpen their skills? Being tired is obviously a factor and it can affect performance and how quickly things are managed, so that’s a given that a good night’s sleep can increase your capacity to handle things. However in terms of other things outside of work what sorts of activities can you do to improve your skills for “production?” Are there exercises in a software program that you can use as a resource or an extracurricular group of other producers you’re a part of? Books you read to garner inspiration?

EKD: Yes. Great question. TD: Okay I feel bad now. Because actually this is a fantastic question. I read this question on the forums this morning when we were picking our questions. And I was like, “Wow that’s a great question, I should just answer that.” And I wrote him an answer in the forums. EKD: So go to the forums. Next question. TD: No, no, no. Honestly we should answer. Because it was a really good one. EKD: You already posted about it, you had some prep time. There is a lot of things you can do. There’s a lot of different aspects to being a producer. And so there’s a lot of different skills you can learn in different places to get ready for this kind of role. Books are great like you just talked about drive. One of my favorite kind of leadership books is “First, Break All The Rules.” It’s fantastic. And then they have a strength one after it. And then there’s the Game Developer’s Handbook and there’s a production book out there, there’s a team leadership for the game development written by Seth Spaulding that I loved. It was just kind of overview picture of small studios. THough there’s a ton of really cool books out there from very talented… TD: Dale Carnegie’s “How to Win Friends and Influence People.” EKD: Yup, that’s a fantastic one. Cause I think what’s cool about this job or strange. Is that we have so many elements we can learn from so many different things, right? So being a manger at your local convenience store is still helpful for becoming a producer, right? Leading people, managing a process, being responsible, being held accountable for things. That’s very important. There are tons of people out there making games all over the place with the amount of SDKs out there and the amount of opportunities nowadays. Not just including the schools that are popping up everywhere. But there’s tons of cool game – I can’t think of some of the websites. But there’s some websites you just google, “Looking for writer, looking for producer, looking for developer.” Jump in on one of those and say, “Hey I’ll be your producer for it. I don’t know what that means, but how can I help?” And then try to start forming a team, and then help that team achieve one thing. Even if it’s just your first sprint. Use different types of project management, scrum, agile, waterfall, the PNP program that talks about the whole large project management process. It’s really cool. So there’s tons of really great schooling and there’s tons of different things you can focus on to be good at this job. Playing games is awesome, but that’s not the only part of this job. In fact you need to love making games or making entertainment as much or more than you love playing them, to I think do this job. TD: Yeah, no there’s a lot of… Like Eric has covered there’s a lot of great project management training, resources, reading. There’s a lot of great books on psychology and people management and dealing with people. A large part of your job is dealing with communication and individuals. You can also – another great tactic, and I’ve done this myself, which is learn each of the pieces of software of the team that you’re dealing with. So you can actually speak to them and talk to them and understand when they describe a problem to you, what that problem means, how long it’s going to take. I mean there’s other things that you can’t do unless you’ve been in the industry. But it’s like, you know, a good characteristic, always stay self aware. It’s kind of horrible but I’ll probably spend a lot of my time at night or you know kind of “bathroom time” or whatever; thinking about past decisions I’ve made, past things I said, how I handled this interaction, and replaying it in my mind over and over. What if I did it this way? What if I did it this way? And trying to absorb some new outcome. And it’s kind of like running a permanent retrospective on your life I guess. What did I mess up, what do we do okay but could be better, and what did we do well? Other things like, E3 is great we’re going to go to E3 a little later today. E3, GDC, seeing old coworkers is like developing a network of mentors, respected coworkers, even if you’ve never worked with them before you could have people that you respect and have a relationship with. A lot of times when I have a big problem or a big question I need answering, I kind of go to what I call my Small Council, you know what I mean? I try to bounce it off as many people as possible and come to consensus of opinion. EKD: Yeah. To speak about the software thing. So to give some examples, right? Like 3ds Max, and Maya are used a lot. For production tracking: JIRA. Getting a handle on JIRA, Shotgun software, any kind of production tracking software. Microsoft Project I’ve seen used at a lot of companies as well. TD: Project Hansoft. And you can get free trials of all this stuff. EKD: You totally can. What other programs can people get their hands dirty with? TD: Visual Studio. Actually I think, if I am not mistaken, I think they’re going to make Visual Studio free. EKD: Hey, get it. TD: I think that was an announcement recently. I can’t remember exactly. But yeah visual studio. I mean learning, seriously just the basics of programming. Like there are so many tutorials out there that will teach you about what’s a virtual function, what’s a pointer, how do these things work, how do they interact, how to setup a program. You know and you might do something stupid like me and just make a little MS DOS calculator. But you know it gives you a little bit of a foundation that you can build from. EKD: Yeah, and I think understanding a little bit about what team – you know because being just a generic producer that helps everyone is fantastic. But you’ll see as we talked about earlier with different skill sets. There might be a certain thing you have a passion about in kind of the back of your head. So I am a big fan of art, I did a lot of art growing up, I have a BFA. And so I like working around artists and helping encourage them to do a great job. Doesn’t mean I don’t want to work with everybody, the designers and the programmers. But that’s kind of my thing that I know the most about. So I would like to help them. The more you know the better it is – to go back to another question we talked about earlier, was understanding bids and how much time people take. The more you understand about what job they’re doing, not in depth but just a base knowledge. The better it is when they say, “That will take me four days.” You can kind of go, “Well that seems like… normally it has only taken us two, because I know what software you’re using, I know how it takes generally to make that piece of art. Because I’ve seen somebody else do it.” It just helps fuel that producer inside you. TD: Yeah. EKD: So great question. I hope that answered it. That was a lot of questions, I hope we got them all. TD: Yeah, yeah. EKD: And if you have other questions always feel free to reach out to us. We love answering questions. TD: Absolutely. we’ll answer you on the forums. EKD: That’s right, that’s right. Both: *laughing* EKD: I hope that lined up with what you said on the forum. TD: Mostly, yeah. Alright so, our next question comes to us from Wyound “six” of Imperium.

Wyound “six” of Imperium asks:

Dear Producers, We have seen the process of fixing bugs on bug smashers. “Awesome programer sits down, thinks, and magic code fixes fly out of his fingers” Is the process of implementing a new feature similar? A lot of people seem to think so. Could you walk us through beginning to end, the process of taking a feature, from an idea out of Chris Roberts’ head (or someone elses) all the way to being played on our computers, including some obstacles you run into and how you over come them? Of particular instance to me are localized ship physics-instances, GOST, or grabby hands!

TD: So lets take uh, of this, I think the best would be… GOST. GOST is a really good example and we’re going through it right now. So to step through that process, is the process similar to implementing a feature as fixing a bug. No, fixing a bug is part of implementing a feature. There’s a whole stage for that at the end. The reality is every feature is a package of bugs that you haven’t created yet. So with every feature you have to build in a bunch of QA and bug fixing time at the end, because it will happen. Even the best engineers on the planet, it’s not even that they’re making mistakes, it’s just things evolve over time or this thing over here impacted them in a way that wasn’t forseeable. So with the example of GOST though for example, we have a need in the game or a need gets identified. And that’s really when you’re talking about a new feature it’s either a need or a new idea. In the example of GOST it was a need. We have the need to be able to understand where the player is versus where the ship is and what their respective states are so that we can have them interact in appropriate ways. Like not being able to get into a turret when somebody else is already in that turret or being aware that the ladder is down thusly you should climb the ladder rather than playing the deploy ladder animation. Or detecting the player to turn on lights. Anyways, tons of examples I could give you. But these were a list of needs, that were identified by Chris, by the designers. And so what basically happens is they go in, they write up a list of, “Hey here are all the needs, here are the problems that we have that we need to solve in order to accomplish these things.” And now generally this would be described as your GDD, your game design document, or your level design document or in this case a feature design document. These are the thing that we have that are a list of problems and then you take those and you hand those over to the engineering team. And they’ll tell you, “Okay, we think the best way to fix this would be…” And then they document their technical design document. And they all peer review it and then they sit back down with the designers. They hold the two together and they kinda say, “Okay is this really, is this the best solution for solving all of these problems in one holistic way.” Then it comes to the, “Okay! Greenlit, everybody is happy. This is exactly what we want to do, this is how we want to do it, everybody is onboard.” We have the strike team formed. Then we literally sit down and break it down from beginning to end, and some of these things take 6 months, even longer. Then you say, “Okay well here’s where we’re going to start. Here’s the easiest, simplest, and then build, build, build. And you usually start with the framework, the foundation, and then build and add features on top of that. And then at the end or, throughout the process, but then at the end you’ll have a long kind of buffer time, for QA, testing, bug fixing, integration into whatever the relevant stream that you’re supposed to be in. So for example this feature might be built on that double pyramid down in Game Dev -> Arena Commander -> subset feature branch of GOST. And then it’s getting constant integrations with Arena Commander and then eventually it needs to get integrated into that, integrated into main. So you have to put in maybe a weeks time, to solve any issues. So that’s really the, the super basic and I could talk about it forever but I’ve probably gone too long already. The super basic process of taking a feature from an idea, to getting it all the way down into the game. EKD: Yeah, great question. Cool. Am I the last? No, no, this is the last? TD: Uh, I think so, yeah. EKD: Last but, it went fast. From AragornBH. What do you think BH stands for? Bad.. TD: Bad hands. EKD: Bad hands. Cool, cool name.

AragornBH asks:

Imagine that you have two artists, designers, or other CIG employees working on a project within SC that you are producing. Along the way they have a professional disagreement about what they should do and it is clear that it would not be possible to accommodate both versions. How do you determine which version to keep and which one to scrap? Is it difficult to tell a fellow employee that, even though they are working hard, they need to change how they are doing their job because it doesn’t fit into your plans? What tools do you use to minimize the possibility of the situation described above?