TL;DRNew engine features like Large World and instancing are R&D with unpredictable timelines, but the speaker says development becomes much more predictable as the project shifts to straightforward content production.
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.
TL;DRProducers handle the unexpected by capturing as much as possible in estimates, including iteration and buffers, and by learning the team's habits, while admitting plans constantly change and predictability is rare.
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...
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....
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.
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...
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.
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.
TL;DREvery feature differs, but using a ship as an example they estimate roughly a quarter of time in concept, most of the remainder in modeling, and a last small share for audio and VFX.
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?
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.
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..."
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.
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.
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...
TL;DROutsourcing versus hiring depends on time, money and deadline; they say outsourcing isn't necessarily lower quality, frees skilled artists from routine assets, and lets the company scale while keeping commitments to permanent staff.
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?
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.
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.
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.
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.
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.
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.
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.
TL;DRThey limit one release's impact on others through a layered branch structure with team streams feeding main and separate release branches, plus spacing releases and keeping backup plans, though delays can't be promised away.
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.
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?
[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?"
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."
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.
TL;DRThe hardest part of senior producing is balancing people, schedule, communication and budget rather than any one of them, and it depends on each producer's strengths and on building a team that complements them.
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.
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...
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.
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.
TL;DREstimating is both math and gut: knowing your team and applying baseline adjustments for people underestimating big tasks and for a roughly 70% workday help, and experience fills in the rest.
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.
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.
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.
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.
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.
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...
TL;DRProducers sharpen their skills through books on leadership and people, project-management training, learning the team's software and tracking tools, basic programming, joining small projects, networking, and constant self-reflection.
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.
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...
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.
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.
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.
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.
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.
TL;DRImplementing a feature is not like fixing a bug: it moves from identified needs through design documents, engineering review and a strike team to building, with bug fixing and QA time built in at the end.
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.
TL;DRDisagreements are resolved by getting everyone in a room to reach a compromise, but the better fix is clear roles and ownership so two people don't work on the same thing.
We're going to do it right here. Example. Role play it, role play it. Uh, that is a great question. And, and this goes back to some of our other questions about the soft skills of the job. And the communication portions of the job. Um, it is very important I think to, to help everyone understand that their ideas matter, their opinions matter. What they have to say is totally important. Um, and I think Travis actually talked about this earlier when it was... How do you have that, that professional debate, where you can ultimately come to a compromise. So, for me - at least how I would try to resolve this is understanding what they're both looking for. Right? Honestly one of the best tools of our trade is getting in the same room and helping us all hash it out. Because in, in this industry, we're all professionals, right? We may be making entertainment and maybe be really passionate about what we're making.
The best argument you could possibly have. So you're already starting off with strong, in the right way. So, helping them come to a compromise is now your goal. Helping them come to an understanding that whichever one is right is also your goal. So getting them in the same room, helping them guide that conversation, giving them both a platform to speak out whatever it is. Make sure all the key stakeholders are there to hear all the sides. And then the hope is to walk out of there - and that's one of the things us as producers try to do when we're helping guide a meeting - is to walk out of there with a set solution that we all feel good about.
We may not feel great about it. Especially, like you mentioned AragornBH, that it's hard to tell somebody, great idea but we're not going to use that idea. But when you're all together and you've come to a compromise. Honestly, it's not that difficult. Again, they're professionals, we're all professionals, we're all adults. And we all understand that you know, "Okay, I got what you're saying, I still would like to do mine, but that does sound the best for the project, let's move forward with that." It tends to resolve itself through just simple guidance, communication, and getting the team together to come up with a good plan.
I think what Eric said is exactly how you approach solving a problem that has happened, a conflict that has happened. The best problems are the ones you don't have to solve. I think the example that he's giving here is probably, when I listen to it I hear the situation is kind of like... That's something that maybe before could have been completely eliminated just by having like more clearly defined roles and responsibilities.
Because these two guys apparently were working on the same thing and had a competing method, going for some amount of time before we had to sit them down and talk with them.
On the same thing, that's a great point. I think what we came to here is a symptom of a more root problem. That root problem is establishing clear defined roles for each person on the team. I am going to jump around what you just said. Once everyone kind of understands it. It's totally okay to have opinions about what everyone else is working on, but also respecting each other enough to know, "Alright thats your field of expertise, this is how I've done it for many years in the industry. Here's my perspective.." But they're very clearly defined that this is that person's role.
Yeah. We've had a lot of success with establishing clear ownership on different pieces of the game. Even pieces of features. That's the thing everybody should understand, everybody has opinions and actually a lot of people on the team, like Zane is a great example. Zane is super dedicated, Zane spends an amazing amount of time working on his art. And he will be the first one to walk up and ask you, "What do you think? What could I do better? How could this be better? What's it like to play with this. Did you guys like this thing I did or not?" So everybody is very open to feedback. I think everybody just needs to have ownership and then they can run a nice little operation.
I love that last point too, about Zane. And that's pretty true with everybody. I think even as producers, right? I'll bounce something off Travis, be like, "Does this make sense? This is what I am going to do, this, this, this." It gives you just another perspective to improve. We want to make a really cool product for our backers and for our subscribers and just for people that want to have a great experience. That's what we're all fighting against each other for, right? That's ultimately what we're doing. And as you said at the beginning of this interview, that's the best problem to have.
TL;DRPicking up debris or severed limbs as melee weapons could be done, but letting players grab arbitrary items is hard to maintain, test and balance, so probably not in the near term.
Something like that. I believe name I don't know did that as a fatality in Mortal Kombat 4, so...Yeah, maybe some reference to that. Good game.We could do something like that, but I think just having an item that you could just pick up around the level, or any kind of item that the players are able to interact with may be difficult to maintain, because pretty much any part of the geometry of the world would be rippable, and I just think the player holding many different items or anything they can grab would be difficult to do.
Yeah, it would be a difficult thing to do. A lot of people saw the system with grabby hands and they thought, oh, you can just pick up anything and use it as a weapon, but once you start using those things in the Universe, and using them to react especially with other players, especially in a fatal way, it becomes much harder to maintain, much harder to test and balance. So, maybe that's something we could do in the future, probably not in the near term.
We'll probably have like, one prop that's a dead guy on the floor, and that's the one prop that you can rip arms and legs offTD: Just for you, just for you.
TL;DRYes, the first FPS release will use CryEngine's default in-game chat on local servers, with a richer social-module chat system with channels, whispers and presence coming later.
And the answer is yes. So, with the first iteration, of FPS we're going to use the in-game CryEngine chat, so the default chat that comes with CryEngine. Later though, in the social module, one of the things that's been worked on by Austin team is the new chat surface, so this will introduce things that people are more familiar with from most MMO titles, giving you the ability to chat, in the long term, from the website to people in the game, this will come with the idea of rich presence. meaning you can see when they're online or offline. So you can chat with them in game, you can have private whispers, or tells, or whatever you want to call it, and it'll also allow for things like different chat channels, i.e. your party chat, your guild chat, so that system is coming with the Social module. But yes, in the initial FPS release, there will be local server chat, meaning that you can talk trash to your enemy team, and I guess talk trash to your allies as well.
TL;DRThe aim is for all controller types to be balanced enough to be competitive, using tools like finer stick control and gimbal-size limits, but it is a work in progress with community input planned.
Well, I think with the different controller types now, obviously trying to maintain controller balance across the board, with a HOTAS, people use X52, X55, KBM, whichever gamepad they decide to use, the aim will be to have something that is balanced enough for everyone to be able to have fun with and enjoy, and not feel that there's one that's quite hax over the other, not feeling that overpowered if you're using mouse and keyboard or launching missiles just like rapid-fire. Ways that we'll do that are still something that we're trying to perfect.
And there's a couple of avenues. You've seen the first iteration of what we called ESP, giving people with sticks the opportunity to have a little bit finer control as you move closer to your target, so we can do things like that, attenuating the acceleration curve on the movement of the ships themselves, we can also do things from a game design perspective, like the refactor to gimballed weapons and sizes, so gimballed mounts and the more they gimbal having lower sizes that they can accommodate, so sure you can move around with a mouse and have pretty good aim with the gimbals, but then we'll reduce your ability to do damage based on the size of your weapons, so there's a couple of different avenues, and one of the things I've seen a lot of talk on the forums about, specifically mouse vs. keyboard, and I know we did that... on Around the 'Verse... there was like a controller summit with some of our designers, and one of the things I want to make clear to everybody is that it is super important to us that everybody is able to enjoy the play experience, so everyone can participate and be competitive no matter what peripheral device they choose to interact with the game. That said it is a work in progress, it's still a pre-alpha, controls are normally something you wouldn't do until right near the end of the game, where you start to refine and hone, right near the Beta phase, so while we are actually making efforts on this balance ahead of time, because we are released with Arena Commander, it is something that we will have to continue to balance and continue to tweak and tune, and we do have some ideas about doing more community involvement about that, so stay tuned for that. A little too soon to say, but we have an idea for how we'll actually get you guys to participate more in helping us to tune control devices.
Yeah, and you guys have been really good so far, giving us your feedback and everything you've listed out. I've seen so much detail from the backers already on what they believe should be default configurations, and different types of preferred control types, so yet againTD: And we're listening. Cause how many times have we gotten emails from Chris, cause he's reading the forums, and he's like...'hey, is this real? Is this really a thing? Can you verify cause we've got to change this!'
Yeah, those are... something... those emails. Good to read. But it's good cause it keeps us on our toes, and it makes us believe that hey, we're looking at sometimes a particular feature in the game, and it brings us back to controls, so it's like how can we do better to balance.
TL;DRRomance is much easier in single-player than an MMO, and Chris is planning decisions in Squadron 42 that affect relationships with wingmen, though how far those relationships go depends on the player.
So this kind of question... it's always interesting to add different types of relationships, and romance in particular. You see games have developed over time, you can actually visualize that romance between characters with different cinematography, different scenes. Usually by the cutscenes, but also in the actual gameplay and actions that you can do, being able to develop a good personal relationship with significant others, so to speak, and I think Star Citizen's going to give you a great opportunity to probably do that, because there's going to be so many different people, so many different beings, in the 'Verse, yeah. I think that's something we need to...
Yeah, I think Squadron 42 too, I mean, what they're calling out is Mass Effect and Dragon Age which, it's obviously much easier to handle relationships and romantic relationships in a single player environment, not really in an MMO, so one of the things I think that Chris is famous for, in the Wing Commander games, is having those interactive cutscenes, having the ability to make those kinds of decisions, and the branching relationships that we had with some of the wingmen in wing commander, and I know that's something for a fact that he's definitely planning on doing in SQ42, where your decisions, your actions, they will matter to your wingmen and they'll impact your relationships. Now, how far those relationships go, I guess that's up to the decisions that you make.
TL;DRFollowing a ship into a jump point is expected to work eventually, starting with single ships, but whether you can fire on or board others inside is undecided until jump points exist.
Okay, so, yes. I believe the answer is going to be that you can. Obviously our first iteration of jump points will be just handling a single ship, because, as we build the technology, that seems like a logical place to start. Down the road, I do know that, there's a concept of a stargate wormhole for example, where you cruise through and arrive at your destination, I think our concept of a wormhole or jump point is much more in line with having something that's much more of a physical space, so something that you can actually traverse, and it has a finite distance and there are obstacles, as we saw in the SXSW previews we did for the jump points, so I believe the natural extension of that is yes, we'll start with one ship, and then I yes, you'll have multiple ships travelling through simultaneously. Whether or not you'll be able to fire weapons at each other, board each other, that simply hasn't been fleshed out yet, because there's no jump points yet, but once we have that and we determine what's fun, it'd suck to go into a jump point and have that not be fun, but as we build out the game we'll know more, but I know that's something that Chris would like to do, there's a lot of designers that would like to do, it's just something we'll have to build out to determine whether it's good for the game.
I think as like a base iteration, the first element would be making sure you can actually traverse and end up at some destinationTD: Yeah, getting through it is a good step pointRJ: Yeah, lets get that right as well. But totally, i think going down that route of approaching into your jump point, and just as you're about to come out, something comes up to you...
TL;DRChris wants in-game voice chat that fades with distance and reflects helmet muffling or radio static, but third-party plug-ins for TeamSpeak or Mumble are probably not planned and the direction is undecided.
So I'm guessing, compelling people or, incentivising people to use in-game chat, and in game chat systems over say, TeamSpeak, Mumble, Vent...So the first answer, to the first question, what are the plans for in-game voice chat, Chris is very strongly of the idea that he wants to have in-game voice chat that attenuates over distance, the same way it would in real life. He also wants to do things, depending on the type of helmet you're wearing, actually have the muffling of the helmet, or the radio static if you're over in-game radio. So there are definitely plans for that, that's something he really wants to do.As for plug-ins for different popular voice apps, I don't know that we would do that, I think we may do our own, but that's something we'll have to figure out when we get to the point where we're actually implementing in-game VOIP, determining the route we want to go, and we haven't done that yet because we haven't determined the direction we want to go.
TL;DRThe current dollar-to-UEC rate is an arbitrary placeholder that will have to be rescaled once UEC can be earned in the PU, with an economist consulting and early pledge packages possibly revalued.
Yeah, and I know we've gotten an economist to consult on the economy for just these kinds of reasons. The one thing I see in this question is you purchase 1000 UEC for about a dollar, that right now is just an arbitrary correlative value. As we go to PU, at some point there has to be a switch-over that says, okay, either these items cost more in UEC now, and we change the whole scale, or we change the dollar value of UEC, but, that's something we're going to deal with when the PU is actually a thing, that we have UEC in the game as a thing you can earn, that will all have to get figured out.
Yeah, I think once we develop more of the features, and more of the in-game items and purchases, we'll be able to have a scale of exactly what's lower end, what's higher end, to find the scale, and actually give values that are going to be fair and applicable.
One of the things I've seen people related to this asking questions on the forums, related to your initial KS pledges, saying, oh this package has 20,000 UEC, or 20,000 credits i think it was called at a time. And lots of people are going, wait, that's like... one big missile. Is that all I got with my pledge?
Yeah, the rattler is a powerful missile. But in the end, I do suspect that there's going to be a time when, once we have a value of UEC, then we can look at the value of those packages, and kind of re-appropriate everything along those lines.
TL;DRThe speakers say AI crew for multicrew ships is being discussed, but there is no final design yet on what AI characters in the PU can do, with an update promised from the PU team.
So I think a lot of the AI behaviours are kind of recent ?? (word I can't understand) that's kind of come into play when we started to think about Multicrew. As I've been here, Travis and a lot of the leads here have been discussing, if you're an owner of let's say a Retaliator or a Constellation, and you launch into a match but you didn't necessarily have people to form the other crew roles that are all those seats, what would be those roles, who would fill them, and the obvious answer to those people is AITravis Day: Yeah, so with regards to Multicrew, it's interesting, because AI comes with its own sort of subset of problems, which is one of the things we talked about and Dan brought up, which is if you go into the game, and you have all AI in their suits, and the're all fully human AI and they're sitting in your seat, you land, your buddy gets on your ship, and now you have this AI sitting in your seat, and you're like, okay, hit the elevator button, he comes down from your turret, do you like GTA him and throw him out of the seat and out the airlock? And what happens if you leave, so.
Space him? Well, you know, in the longer term, I think there's been a lot of discussion about what capabilities does AI have. Like, if I own 5 Freelancers, can I have them all fly with me? They're all different AI pilots, different AI gunners, or is it just going to be the ability to say hey, take this from this planet to this planet, and I'm going to go be over here, and this is just going to happen, and hopefully it's a good AI pilot, what will their skills be, what can they get better at. These are all things that the PU team is exploring right now, and we don't have a firm solid final design on what exactly AI characters in the PU will or will not be able to do, and what kind of areas of learning that they have, but I do think there are some cool ideas floating around now, that are in the process of being locked down. So, that's something I think you'll look forward to an update from the PU team on, cause I know it's important to you guys, and it's also important to us, cause it's going to be a very cool part of the experience. Alright!
TL;DRThe third-person camera will be disabled in FPS combat but may be allowed outside it for showing off gear, and switching to third person would cost you your visor-rendered HUD.
So yeah, we actually made a recent decision, to actually convert the FPS into a third person shooter, kind of like Gears of War style, so you'll be able to corner creep and...no, I'm just kidding. Yes, we're actually completely disabling the third person camera for FPS, so don't be concerned about that. One of the things we were talking about is, we have these beautiful models, we have these beautiful animations, we want to be able to show them off. We want you to be able to be in your hangar, dress up, check it out, that's kind of the fun part, you play an MMO, you get some new gear, you get fitted, check it out, you take a selfie or whatever, so that part we want to be able to have that experience.
So, to that end, I think what we're talking about is a system that dynamically determines what cameras are allowed based on whether you're in a combat situation or not in FPS. So, when you're running around on Stanton, for example, or ArcCorp i should say. There's a real chance you could just have 3rd person all the time, run around, check out all the cool animations, see yourself, your gear. If you get into a situation though where you draw your weapon, or there's a known combat situation, we just disable the camera at that point, so that way we remove that... advantage.
Yeah, exactly, and I think one of the things that was asked by Grump, is if I get over from just protecting myself and turning around a corner, will I lose my HUD if I go into third person, and the answer is you would. If you got shot at that point, that's just your own fault for going into third person, I would say.
So if you could go to third person, then you would lose your HUD, because your HUD's on your visor. And it actually literally is on your visor, it's not like a cheat. You move the camera away from the player's head you can't see the visor, cause it's actually rendered there.
TL;DRYes, radiation and hazards such as nebulas and solar flares are planned, with suit radiation ratings limiting EVA time and possible mission types built around them, though these are still ideas being looked at.
Yes! The answer is absolutely yes. Early in the design for the FPS mechanic we were talking a lot about EVA, what advantages or disadvantages different suits had, one of them was a radiation protection rating that would limit your ability to stay in EVA permanently so you can't just float around forever. So we have the concept of life support, but also the idea of radiation that could build up over time to a toxic level. Different types of suits would be rated differently for different types of radiation. We've also talked about, on the Arena Commander side, different hazards that you could have, both in the gameplay environment but also in the PU, things like nebulas, solar flares, and other kind of time-sensitive or system impacting natural hazards, like what you're talking about.
And another thing we kind of, I'm just imagining now, if you turned up with your suit at a particular area, a nebula or an area that had a particular gas cloud that you were surrounded by, and you believe that your suit is able to combat that kind of area, and another person flies in and they're trying to get into your area, but they get totally wiped out, those kind of things are going to be really cool, just to make sure the player is on their toes of knowing what different suits do, different areas and different environments and how they can kind of affect your gameplay.
Yeah and one of the mission types, cause we've started talking about the concept of the mission generator, or the instance action sphere generator, and some of the mission types we've talked about have been, oh, there's a disabled constellation that is floating towards the sun and it's not under power but there's a high radiation level, so you have very limited time windows in which you can interact with it to try and reconstitute it, rescue it, or just go to hell with it and let it fly into the sun. So yeah, definitely something we're looking at, cause I think it adds a cool level of immersion and gameplay moments.