[0:49] Can you give us an update on the Khartu Al particularly in regards to engines?
Khartu Al is now single seat only. There may come variants or other ships that are more than one seat. It is manufactured by Aopoa as a conversion. Thrusters are setup in such a way that the ship has high maneuverability. Currently thinking that the large engines on the Cutlass and possibly Freelancer will be locked in place during flight and only rotate during landing as it looks ‘floppy’. The Scout has two flight modes, one for landing where it folds in and another where it opens for flight like a flower. The tech behind these states will also transition over to the Reliant.
[6:22] Are there different alien brands? What is the signature of the Xi’an Scout manufacturer?
We may look to expand it in the future but at this moment each alien race is just a single manufacturer. We have consider the differences between the races, so rather than just creating a bunch of alien manufacturers we want ensure they are realistic; fit into the story; and fit into the game mechanically.
[9:40] How is the Component system coming along? Do you have plans to make a ship designer page to allow for custom builds prior to committing? Can you give details on how the component system will work with replacing, tuning, etc?
We’ve been re-factoring the components, one system at a time. We’ve finished a first pass on Coolers with Power Plants well under way and shield systems coming up next. Our goal is to have in larger ships the ability to physically access components and to be able to swap them out and as well in combat, giving players the ability to target specifics parts of a ship to disable components to various effects. With upgrading and changing things around you will be able to do a variety of different combinations and in the future, overclock or tune them beyond what their original specs are. We also want give the functionality of routing power from the rear of a ship to forward parts, etc. We have a large discussion about shields happening right now and this has been and will be done for each component down the line. The component system will be in depth, but intuitive to allow for some exciting gameplay opportunities.
[20:04] Do producers specialize on a game aspect or do you need to know everything?
Not necessarily but it helps to be able to talk to developers on an educated level about what they are working on.
[24:08] How is the size of a component chosen? Can we swap component positions around?
Components sizes were calculated to be no bigger and no smaller than certain proportions based on the metrics of the ships they may go on. This makes them interchangeable between the whole size family i.e. all size 1 radars fit in any size 1 radar slot. Generally components will have specific slots that are not interchangeable. I.e. the shield slot will only take a shield. Though in some instances you may be able to swap some smaller components for others.
[31:29] Do you feel pressure for the next patch to be more impressive than 2.0.
A ubiquitous, unanimous yes. We want to make sure that we are wowing you guys with every new release. So is there pressure? Absolutely, but we are pretty confident that we can out do it each time. And just like any other company the more and more we do this, the better and better we get at it.
[34:16] How do you feel about massively increasing the hull and shields on all ships across the board to make battles last longer and allowing to respond to system failures and to perform repairs?
We want to make gameplay more interesting and we will do that with balance. As we implement or refactor each of the systems we need to perform a thorough balance pass to figure out the appropriate range for each of the values in the system.
[38:54] How do you coordinate efforts between game play feature implementation and relative ship completion?
A lot of strategic planning and communication between production design. When we release a feature or ship we want there to be content for players to take advantage of.
[41:17] Can large ships land on planets? will the Idris have an interior?
The decision on what ships can and can’t make a landing on a planet is being determined at the moment. The current factors when deciding are things such as: ship role, ship function and ship size. It is doubtful a large ship will be capable of landing on planets. Ships are currently designed to be either capable of Quantum Travel or landing on planets. All medium sized and above ships will have explorable interiors that a player and NPC can walk around and interact with the various panels and stations aboard.
[47:03] What is the most useful suggestion you have received from a backer? Did it change the way in which you value feedback?
Any idea that comes from the backers and the community is welcome. So let us know your feedback because without you voicing your opinion we don’t know what you guys are thinking. We welcome it all and it is those suggestions that help mold the game.
Darian Vorlick (DV): Hey everyone, welcome to this next episode of 10 for the Developers. I’m Darian Vorlick, Production Coordinator here in CIG Los Angeles.
Kirk Tome (KT): And I’m Lead Technical Designer Kirk Tome.
DV: So first we wanted to thank the subscribers for being able to make content like this possible. Without you we would not be able to put forward such informational interviews and content as such as this, so from us thank you guys,
KT: Thank you guys.
DV: So let’s get started with the first question, Kirk, you got one.
Far-seeker asks: Since you are working on the Xi’an Scout, which from its initial concept had a set of movable thrusters, can you update us on the technology development to support this, as well as any effect it might have on other ships with rotating or otherwise articulating main thrusters? Specifically any comments on the Cutlass, the Freelancer, and the Reliant, would be deeply appreciated!
KT: Yes. We can start to talk about that. just to start on a few of the comments about the Xi’an Scout which i’m currently implementing for the hangar ready, in the hangar. The actual name of the vehicle is the Aopoa Khartu Al. It is the manufacturer Aopoa’s conversion of the Xi’an scout for human use. It currently has a single seat and no ejection capabilities. I just want to put that out there. We decided that for a light fighter of this size the current single seat arrangement worked best for it. In the future we may have a variant of perhaps another Aopoa manufactured seat that has multiple seats but the current iteration of the Khartu Al is single seater. The thruster questions on here. Yes, the Khartu Al will have four articulated thrusters. The thrusters themselves will orient themselves to actually be able to complete a turn a turn up to ninety degrees for the outer most axes. Each of the thrusters themselves will include the retro thrusters in the front so they’ll be dual sided thrusters which will greatly allow the Khartu Al to have a lot of maneuverability so that the main thrusters can actually contribute to horizontal and vertical thrust as well. DV: Basically it’s vectored thrusting KT: Right. The way we’re going to do this, we’re going to allow the main thrusters to contribute to sideways thrust without actually animating them as quickly as they need to provide that thrust. One issue what we had with the Cutlass, that we still currently have with the Cutlass. Is that having the large thrusters provide thrust in the actual vector that are facing makes the thrusters so that they’re really floppy and so from the rear, when the Cutlass is flying should we provide any type of vertical thrust to provide stability for the ship. We found that, they’re simply too floppy and it just looks awful. So the way to do this is to provide that thrust and actually throttle the, speed at which they rotate so that will have a ship that has this type of nice, floaty motion without having four long wings that simply flap in the wind which will make it look awful. So we’re still developing that and we will of course have that available for the engine and for future ships so that, that will become available. In the near time, we’re considering making the Cutlass thrusters only rotate for VTOL. The same is maybe true of the Freelancer that way they still will have joint rotation without that weird floppy animation. Some other technology we will need to develop, the Khartu Al is one of the first ships that will have a landing and flying mode, which are vastly different. you’ll notice it is very folded up when it’s landed and will expand out like a flower when it’s in flight mode. The same will be true for the Reliant. So what we’ll do is, we’ll create states for the ship; landed or in freeflight that way the thrusters know how they’re going to behave and will allow things like; turning them off when it’s in landed mode or for the Reliant because of the vertical orientation of them. We will know how these thrusters are supposed to affect the ship because of those two states that the ship is in DV: Yeah, how does something like… we have our Flight Engineer: John Pritchett, who works on the ICFS and SCM how would does this change what he needs to do as far as flight controls are concerned. KT: That’s a great question! We would need to discuss with him how we would need to signal the ship, so that it knows which orientation its in. I think that’s a simple variable in the ship will determine when it’s not in landed mode or when it’s in flight mode and then John can then, recalculate what the actual thrust from each of the thrusters, needs to generate in order to maintain proper flight based on that orientation of the ship. DV: That is a mouthful! KT: It’s a complicated ship!
Andy Goodstar asks: Are alien races treated as ‘one’ manufacturer each, or are there different brans of Xi’an/Banu/Vanduul ships? What is specific signature of Xi’an Scout manufacturer?
DV: I figure we would just tack this one on since we were just discussing the Scout. So right now Xi’an, Banu and Vanduul are kind of their own, I don’t want to say brand, but I guess species brand in themselves. KT: Sure. DV: We may in the future look to expand those but at this moment we are looking at just a single manufacturer. That’s correct? KT: Correct. The Vanduul components were implemented as Vanduul components. The Xi’an components will not, they’ll actually be … as we’re doing a component refactor, the Xi’an components will be actual manufacture components. So we’ll have “human” components that are on the ships so that you can upgrade them, exchange them them out, etc. In the future I think we will work with the writers and then come up with the alien manufacturers, each with their own components and capabilities. So that we can do things like have Xi’an specific components or whatnot. For now we are currently going with the human components DV: One of the things, if you guys actually watched the 10 for the Developers with Sean Tracy and Steve Bender, one of the things they talked about was human-to-alien analog components. For example if a Vanduul is how X feet taller than a human you don’t want a human wearing a Vanduul t-shirt because it’s going to be a lot bigger. So we also have to take that into consideration as far as when we create these alien manufacturers. We can’t just take an alien t-shirt and throw it on a human and say “hey we’re done”. We have to take into consideration if the humans’ size are; that their dimensions are; whether it is compatible with human ergonomics at all. So rather than just creating a bunch of alien manufacturers we want to make sure it is something that is realistic; that fits into the story; and actually fits into the game mechanically as well. KT: Right and that’s a conversation for the Khartu-Al: the control scheme are these two spherical control components that humans will put their hands on. It’s just a prototype at the moment we’ll refine how that actually works but the early example of that was on the … what are the Vanduul ships … the Scythe … DV: And the Glaive. KT: … and the Glavie. They had their own custom UI that had an alien flavour to it. DV: Right. KT: The same thing would be true for the Xi’an type of ships. DV: That’s why Zane, our UI guy, he put static across the UI as if trying to show that we are trying to translate alien technology into human use. So it’s still a little buggy in game, so it was a little flavour to that. KT: Yeah. DV: But in the future we may expand it. So you never know. Speaking of components you had a components question that I think nice tail into that. KT: Yeah so there’s a three part question here. These came from Daz, Halbard and Tommytrain (great name).
Daz asks: In regards to the component system can you discuss some of your recent accomplishments with this. Also do you expect we will be able to get a component stats page similar to the ship stats page we have now. Have you considered adding a ship designer page to the website so we can tune our builds before committing? Halbard asks: Will changing the components of your ship have a noticeable effect on its performance and capabilities? Are there plans to have multiple viable upgrade paths in order to prevent everyone gravitating to a single build? Are you considering a balancing mechanic for upgrading so that improvements in one system come at the expense of another? Tommytrain asks: Aloha Devs, how are the gameplay concepts of ‘modular components’ and ‘component tuning’ materializing themselves in design of the components for the latest and future ships coming off the pipeline? Are they interacting as these components become real things, with size, shape, mass as well as output forces/effects and corresponding draws on the components which provide energy, cooling, compute cycles?
KT: This is a big topic. We are currently tackling each of the components one system at a time. I’m sure you’ve noticed that we’ve recently just refactored the coolers that did involve resizing the components because there will be real components in the game, on the ships. DV: Taking up volume. KT: Yup, they’ll be size appropriate for their capabilities, placed on ships, with ships that have interiors such as the constellation or the future Idiris or any of the larger ships we will have access to them from the interior so that when we implement damaging gameplay, which were still designing at the moment, you will be able to access them and have a crew member run down the hall, go down to the powerplant that has been damaged and then actually repair that by access the component from a panel say in the hall that contains that particular component. So there will be real physicalized items that are in the game. DV: Treat it a lot like Scotty from Star Trek kind of thing where someone has to go down a fix the shield generator or fix the warp core or something like that. KT: Exactly. So if the engineer does notice that, “hey we got the coolers damaged, now we don’t have cooling on the right side of the ship.” You can send the engineer down to physically fix that component or perhaps even trade it out for a brand new component and get back instant access to the cooling capabilities that you just lost. DV: So just hope you don’t have to run a whole kilometer length ship. KT: Yes, So, that may be a possibility. What does that entail? Well we’re refactoring all of our component so that we actually keep in mind the capabilities, the positive and negatives of each of the functions of that particular component. Dave mentioned coolers so cooling capability, power draw, signature, these are things that are going to be integral for how the coolers will work. What we need to do then is get that system in and then take a balance pass to figure out, ”Okay we have a size one,” let’s say, drake … I don’t know if they’ve actually created a cooler at the moment but, Drake cooler well, where does that sit as far as its capabilities. Is it a C grade item? What does a C grade item mean? We define that and then we can place those on ships that would be appropriate for that part. Size two or a medium sized cooler would go on one of the larger ships. It has it’s own determinants and positives which you can decide how you want to output your ship by the purchasing the component or when we have future gameplay which you can salvage components, perhaps you can actually pry one off a large shipment and say, “Hey this is way better than mine, I’m gonna go and place it on the holotable and include that on one of my loadouts for one of my ships.” Also in the future we may allow the capability of particular like craftsman to hone certain components so that they can actually improve them. Maybe the get better at improving a certain manufactures coolers and power plants. DV: Tuning and overclocking and stuff. KT: Yup and so that would be great, it would be a great career for someone to be a specialist in. DV: you’re a ship mechanic. KT: Yup and then you can earn your credits or do whatever you want to do and become that go to person in the Star Citizen Universe to get better at that particular skill. What else did they … Oh, so the tuning, So what does tuning and balancing mean? Well it means different things for each of the components. What is ultimately does mean is that we figure out what each of the components do, what their range of capabilities are for their particular stats and then we make realistic ranges for those particular values. We’ve done a pass of coolers, we’re in the middle of doing powerplants and we are in the middle of refactoring shields as a system entirely so we will have shield emitters on the ship that are powered by shield generators. So when you upgrade shield generators by purchasing a new one, you will increase the shield capabilities of your ship. Things like, well a number of faces will most likely be tied to the ships but, the regeneration rate of the ships, the absorption of the shields rather, how quickly it can shunt power from the primary face that you set onto the ship, these will all be things you can upgrade by purchasing new shield generator components. DV: Speaking like someone in the middle of combat, you want to redirect further energy to the front or to the aft or from the you know forward starboard side. KT: So if you have a lesser performing shield generator for example, it may take longer for a shield face with zero health to recover and get back any shield capabilities. So you may consider purchasing or finding a better shield generator to upgrade that particular capability. That may mean more power draw so you actually have to purchase a powerplant that is capable of powering all the components that you decided to fit onto the ship. So that’s what balance entails. We’re currently, most of our components are outclassing their capabilities so powerplants generator more power than you’ll ever need, coolers can cool more heat than you could ever generate. What we need to do is as we implement this components, we need to step back and take a look at what the actual values for the components that we’ve created, what are those ranges? What are those extremes? How do we figure out how these components fit within those extreme ranges and then figure out, “Okay, this is the sweet spot for that particular component, and this is where it sits.” As the player, you decide by mixing and matching the components onto your ships, how they actually work and whether they provide the desired functionality that you want to implement. DV: While still maintaining usability and functionality. KT: Yup DV: I’m trying to remember correctly, I think Matt Sherman explained it to me. For example the ship had two shield emitters, it could be there’s one in the front, one in the back or one left or right, I mean you pretty much have two halves of a shell correct? KT: Right and so. DV: One has four and you’ve got much more control because now you’ve gotten quadrants. KT: So those are faces. I want to create six because to me four doesn’t quite make a lot of sense. DV: Right. KT: Front back makes sense. DV: And you’ve top and bottom as well. KT: Right so bubble makes sense, front back makes sense, I think six is the next logical step, but that is a function of smaller ships. Now when we get to capital ships, ultimately what we want to do is, you’ll want to have say four shield emitters, one that controls the front quarter, the second quarter, the third quarter and the rear quarter. Each of them controlling their own faces, that way we’ll have gameplay in which you destroy the shield emitter or the generators that are connected to the front port faces, you actually have a chance in now infiltrate the ship from the front and give you an incentive to go after the sweet spot in the front that you’ve dedicated so much time to destroy with a squadron of small fighters. DV: Well now let’s say you have a long carrier like a Bengal or Pegasus or even an Idris I mean you set up something that long, you could even have mid bulk emitters so if one of those gets taken out you still have an opportunity to have something sneak in while one of those shields are still on before it pops back up. KT: Right, exactly. DV: We can create some really cool missions. KT: And I think it’ll allow players to figure out strategies not only to attack shields, but defend themselves. If you find that you frequently outclass in the front, well let’s get some shield generators and upgrade them on the front side because we know that’s our weakest point of entry. DV: A very spartan type of attack. Or you can lower one of them and try to lure them into it knowing that’s where your main guns are. KT: Yeah, eventually we’ll get to actually figuring out how the engineer can do things like shunt power or priority to those shields and so, this is a big discussion on one of these systems and we’re doing this for each of the components as we go down the line. DV: It’s pretty exciting stuff. This next question is kind of a much more production related question from…
Perry Hope asks: Do the producers specialize on a game aspect or do you need to know ‘everything’ about that game?
DV: That’s an interesting question, one of the goals of what production is is we basically try and make sure that designers like Kirk have the resources they need to make the game possible. So, while the production coordinator for the tech design and engineering team. It’s not my job to know how to do coding, or how to do engineering or necessarily know how to do tech design, I just need to make sure they have the resources they need, make sure the information is being correctly funneled to them. Now, ultimately what can cause a bottleneck is something like lack of communication or what else would you consider… KT: That is the priority number one, communication is the most important thing that a producer can provide any employee… DV: Right. KT: In development, we need to keep those channels open and ensure that everyone knows what they need to do and are expected to do. That way we don’t have issues where, ‘hey, I didn’t know that Jimmy over here was supposed to be doing this. I’ve been waiting for him to finish this other task, which prevents me from implementing thing I wanted to do…’ DV: Right. KT: So, communication is absolutely number one. DV: A good producer will be able to keep their team in the loop at all times, an excellent producer will be able to preemptively predict what obstacles are coming down the road. Be able to foresee what things down the road are going to bottleneck, such as knowing what the other teams are working on. For example, we have Mark Hong, who is our art and animation producer, so if I am working on a particular feature as a producer… my goal is I want to be able to talk to Mark and find out what he’s working on. See how what he’s going to do is going to effect what Kirk’s team is coming or is doing down the road. So if we see Kirk is working on a particular component for a ship, if I find out from Mark early on that that ship is going to be delayed or the art isn’t coming along as quickly as possible it’s my responsibility to provide that information to Kirk say, “Hey, we have a little more cushion time as far as that particular ship so if you have something else you need to work on, some low hanging fruit that you want to complete in the meantime”. That’s where the producer comes and lets these guys know, that’s what’s available. As far as specialization, it’s useful to be able to talk to those developers at an educated level, like I said before you don’t need to know how to program but at least know what those programmers are doing and what they’re working towards. Same thing with tech design, we necessarily don’t need to know everything about game balance but we need to know what their objective is and how do producers help them to complete that objective. KT: From a developer’s standpoint, it is my responsibility to inform producers as far as the things they do need to know about that particular task so they can make an educated choices about scheduling and task party, etc. At the same time, when I do need to talk to say one of the artists or animators directly, it should be part of my duties to inform the producer in charge of that particular individual that that is happening that way they can ensure that maybe a higher priority task should take precedence or they know to follow up on that task in the near future and we can all figure out… hey, were you along that timeline, are we getting close to being done because this person is waiting on that. So, juggling tasks and figuring what priorities of things is the resource we use from the production team. DV: So, it’s kind of a nitty gritty behind the scenes look at game development, it’s not the most romantic or glamorous type of question but it is one that’s important. That’s why we wanted to address it, there are things that go on behind the scenes that help streamline a lot of these things other than just making pretty ships and cool levels.
SloanWarrior asks: How did you decide how to size the components for the components system? We’ve heard that ammo bins might be able to hold fuel when they’re not being used for ammo. Is this a uniquely interchangeable system or might other components also grant storage space for one resource or another when removed?
KT: Great questions! So… DV: I’m thinking behind hidden panels,things like that. How about a fake fuel cap? KT: Yep! Smuggling is a topic that has come up for piracy or just being able to stow equipment safely for you, on your ship. That is a topic we’re in the midst of discussion for. There was a pass on components for each of the component types, they were mostly done by, they were spearheaded by Elwin who took the, metrics that we use for the ships and for any of the buildings in FPS, the… DV: We’re talking what metrics? Volume, length? KT: Right. These are the standard minimum doorway size that we have on the ship. The standard minimum walkway path that we need. Things like seats, turret sizes, weapons, any of these components we took a look at them and decided “Ok”. A size one small component should be roughly this size, and no bigger than that size. So we took the maximum allowable size for the component and ensured that all those components fit that size, fit neatly in that box. So everythings boxed, box shape. That way we can ensure that when we build a ship that has a physicalised component when we swap out a size one, say radar, then we can actually implement another size one radar in the same space without having to have custom geo just for that enclosure, and that ensures the swapability of components and allows us to make components that are unique enough to, make you want to get a different type of component to suit a different need. DV: So it’s actually something that we’ve discussed in the past where we’re finally starting to see it come to fruition as the standardised modularity. You might have heard some of us talking on previous Ten for the Producers and Ten for the Designers that we’ve been look at trying to create standardisation for these sizes for a long time. And that was something that was spearheaded by Elwin. By creating standard bounty boxes you create a template for every single size one, every single size two because now we have a range measurements that we can utilise to put those on KT: Right, and that’s important for us as Designers because when we’re implementing a ship in whitebox we can take these bounds that we create for the ships and we know that this is going to require a size 2 component of this type. We need to ensure that it is placed in the ship roughly around here. Well we’ll need access to it, because the ship does have an interior so we can communicate to the Artist that there needs to be a core goal or some kind of wall in which there is a panel that we can access this so when we go to actually repair it or swap it out or salvage it, if you’re a pirate! There is the capability to physically access that object. What’s also interesting about that is when we eventually have the ability to damage these components from the outside, so we’ll have gameplay and you’re shooting up a ship from the outside you know you can target the shield generator because you can take the shields down. Well you know where that is roughly in the ship you can start shooting around it,and you will know that it does embody a physical location on the ship, and you know where to target that particular component. On a converse when it is destroyed you will also know on the ship. The engineering can tell you, “Hey get on down to hallway A and repair the shield generator”. That crew member will know exactly where to go, which panel to pop open and which component to repair. DV: Or in your cargo hold you could have a whole crate full of different shield generators. Your engineer runs down, take one out, go run back to the cargo, grabs the new one and throws it in there. So not actually fixing it but replacing it as well KT: Right. So that’s just part one of the question, part two was: what are the…. Are we going to allow rechangeability of components? In general no. So most components will be in a specific spot, slot put together for that component. Some of the component types though, such as ammo, fuel, I think there was one more. I can’t remember off the top of my head but there is a category of components in which you can choose to fit anyone of those types, that fit in that particular range of components in that slot. So if we do have say a smuggling hold that is placeable on our pirate themed ships. That is a component type you can choose to fit onto that ship. If however if you really want to on the same ship, fit it for longer quantum travel or further distance. Maybe you’ll choose a quantum fuel or a regular fuel canister instead. If you really want to fit out a ship with a lot of weaponry, well let’s put an ammo box in there instead. So there is a category of component types that we are implementing in the near future. However for the most part components will fit into their actual designed slot. DV: I just thought of it’s like a ship USB system KT: Yeah. Not quite that modular! DV: But at the same time. Let’s say you have one labelled as a fuel tank and technicality it’s actually a cargo hold. If let’s say a player’s a police officer that’s trying to investigate this pirate ship and he see’s a fuel tank there, well he knows pirates tend to use these as cargo holds. I remember hearing someone discussing about being able to scam them and be able to trick scammers as well? KT: That is something that we’ll have to design and implement but yeah, sure DV: Something way down the road! KT: Yeah. We can also design say a cargo hold that does disguise itself as a… DV: Fuel tank or an ammo box KT: Fuel tank. And it actually has that, when we implement that actual scanning gameplay, perhaps there’s a way in that it actually mimics the actual, the component that it’s trying to pretend to be that way you can smuggle, or use it as a smoke ring canister, because we’re only going to make a finite number of ships and so there’s no way that we can say that “Hey we can randomly generate these smuggling holds”. So each ship if you take a minute to study you’ll know that “Hey it’s a capability of it having this smuggling hold”. So let’s figure out gameplay in which you can make use of that item and still get away with that gameplay by giving us the capability to whoever is trying to scan that particular item. DV: If you use a car analogue. No matter how many Ford Mustangs you look at, you’re going to know where the engine is every single time. KT: Right.
Sultann asks: We just have a big step in Star Citizen. Do you feel more pressure now than before that the next big step will be more impressive than 2.0?
DV: Essentially asking with every release do we feel pressure to out do ourselves every time. And that’s a ubiquitous, unanimous yes. When we released 2.0 that was with much great fanfare that we finally released multi-player, multi-crew technology but we already had our sights on 2.1 and now we’ve got our sights on 2.2. And every time we release one of these patches, yes the pressure is there to deliver, but we’re always confident that we can deliver more and more. That’s kind of the … that’s kind of what we do every single time. If we tried to release inferior content every time … we want to make sure that we are wowing you guys with every new release. That’s why we are constantly showing you guys new ships, new technology. That’s why we have discussions like this to keep you guys up to date on what we are working on. So is there pressure? Absolutely, but we are pretty confident that we can out do it each time. KT: And just like any other company the more and more we do this, the better and better we get. DV: Yes. KT: This includes things like planning for the future. May not have been so great at that in the past but as we overcome more and more hurdles and get to each goal, we get better and better at planning for what we’ll need, ensuring that we can achieve these things without simply having it as a line item in an email “hey we know what we’re going to do how do we get there?” Figuring out the steps that we need to take and incrementally improving on each of these processes is something we are getting better and better at every day. DV: This is actually where a lot of production work comes in: being able to pre-plan what those objectives are. We may, let’s look at 2.3 or 2.4 and beyond, we may have a rough idea of what we want to be in those patches and ultimately Chris is going to dictate we want in those patches, what content we want to deliver, so it is up to Production to be able to pre-plan all these schedules out. And this is where a lot of our tools like Jira, Microsoft Project … what we are starting to do is standardise a lot of … in fact as Kirk mentioned, as we do this and fine tune this standardisation of our practices is going to help us accomplish those goals and make them higher quality each time because we are looking what tasks we have done in the past; what we’ve completed before; and how can we apply those same practices in the future. So I guess just as long as we keep on trucking it’s going to get better. Next question comes from Raven …
Raven asks: What are your thoughts on massively increasing the hull and shields on all ships equally across the board? Currently I feel ship battles are over quickly and this gives little time to respond to system failures in larger ships. I would like to see this as battles would be longer and more immersive, allowing you to repair systems and hull breaches for more of the “decisions matter” effect. Right now by the time you take on damage the fight is over before you can finish the chair animation.
DV: That’s kind of the nature of the smaller ships though right? KT: I mean yes and no. This is a very fair criticism of some of the, especially the Arena Commander, battles. What we need to do when we are refactoring each of these systems, shields is being refactored as we speak, we then need to take a balance pass and figure out what we need to do to change the min and max ranges of each of the values in the system. So for example, with the shields we are going to introduce gameplay in which you can do things like give priority to a certain shield; or change the way it can repair faces faster; or do shield face hardening; or the way in which faces can absorb damage or deflect damage away. So once we implement these systems and get that gameplay into the game then we need to go and sit with each of the ships and start shooting at the ship, figuring out “okay, well ships of this size with this particular shield can withstand this much damage for this amount of time” and put that all in a big chart and then figure out where each of the ship lies and if we need to tweak any changes. So to answer you question, we do need to better balance passes for each of our systems. Making hulls and shields across the board larger may not be the best way to do that. DV: We want to have more tactical combat rather than just overall buffs. KT: Sure, and so what we can do is, we can take a look at each of the systems individually, shields, hull, health, mass, damage per second, by weapon type, etc. and figure out “okay, where in the realm of the things that we want to look at, like DPS for weapons, where does that particular weapon sit? Where should it sit?” If it isn’t sitting in the right place we figure out “okay, we need to tweak these particular values and make sure that they do fit a role for that particular component type. So yes we want to make gameplay more interesting. We will do that with balance. I think this will definitely come into play as we start making larger and larger ships because as we do implement ships, or ship types, that we haven’t before we need to figure out “okay, how do we do this without breaking what already exists?” So if we make, say, the Constellation, if we made it impossible to destroy with a couple of Hornets it wouldn’t be very fun. So figuring out where, again, the ship lies; where the capability of each of its systems types should lie and ensuring that those values are correct is part of our jobs and we need to be better at that. DV: At the same time let’s look at real world analogies or comparisons: if you have two people on motorcycles that crash into each other at high speed chances are they’re both going to get wrecked. Pretty quickly. If you have a car hit a motorcycle the chances are the car will be a little dented but the motorcycle will be pretty totalled. KT: It’s true. We still need to, as game designers, we still need to figure out a way in which that is fun. DV: Yeah. Absolutely. So you don’t want it to be over quickly but you still want to add an element of adrenalin pumping with tactical strategies. KT: Right. So that also comes into play when we’re designing ships. We can’t make a ship that is just OP, in which playing any other ship types is just no fun. DV: Right. KT: So we figure out how is it better than other ships, yet consider if you have a fleet of smaller ships can they take it out? Let’s figure out a way we can do that. DV: Ultimately just establishing a really good strong meta for the combat. KT: Yeah. DV: So this one comes from Minion Soldier and this is kind of an interesting one …
MinionSoldier asks: How do you coordinate efforts between game play feature implementation and relative ship completion? For instance, if mining was being brought into the client would you automatically put the Orion into production? Or would you shelve mining until the Orion or the other small mining vessel was done?
DV: This is where a lot of the strategic planning and communication between production design comes into play. This is also where good direction from management, Chris or Ben, also comes into play. So when we release a feature or a ship thematically, for example, if we wanted to do a salvage feature, ideally we want to have content for players to take advantage of that. So, a salvage specific ship would be a good example of releasing when we released the salvage mechanics, same thing if we wanted to release a repair mechanic, you know having the what’s is it… Endeavor. Having that come out at the same time would make good sense. If we created a mining mechanic using your example here, if we created the mining feature but we don’t give players a ship to do mining on. It’s a feature that’s basically sitting there waiting until we have that feature completed or a ship to take advantage of that feature. Ultimately, this is where planning and preproduction and communication comes into play. KT: Right, so none of these things are coincidental. When we do decide to create a ship and decide a release date for it, we need to ensure that the systems that make that are unique to that ship actually exist… are designed out and are implemented from code and tech design so that those systems are in play by the time the ship is actually created. DV: A good example is quantum travel, if we released quantum travel without any ship that can quantum travel… KT: Doesn’t make a lot of sense. So, there is a lot of design that goes into that… quantum travel is a great example. We needed to decide what quantum travel was, how it realized itself in the game, how the component interaction for quantum travel was, standard things like the distance for quantum travel, time for quantum travel, quantum fuel is a thing now so we implement quantum fuel as a part of quantum travel. That’s a system that needed to be designed before we created a bunch of ships that were capable of doing quantum travel. DV: Excellent question but yes it is not coincidence that we release these like that.
Ezreail asks: With regards to the increase in ship sizes, I.E Idris, are some of the smaller capital ships still going to be capable of landing planetside. If they can when will we be able to actually walk in and around them. I’ve been jonesing to see what the Idris has become since its transformation.
DV: I’ve been waiting for this question this is a cool one. KT: Great question. We are discussing that now. However for the most part, the, we are deciding which ships are planetside landing capable or not when we design the ships. One interesting topic that came up was, for some of the snub nose or smaller fighters, we are deciding to either make them Quantum Travel capable or atmospheric landing capable. As a trade off between for having such a small ship you need to pick one that suits the needs that you are looking for. This is especially important when we have ships that are capable of carrying smaller ships. The Connie is an example of one, though the Merlin doesn’t actually function on it yet, but when it does, you’ll get the capabilities of what the Merlin is able to do when that comes online. For other ships that have snub nosed fighters for example or a carrier ship you can decide Well you know what I really wanted to park this carrier outside of a planet and then go down to the planet surface using all these smaller atmospheric landing capable ships. Or what I really want are a bunch of say like taxi style vehicles that allow you to shoot across the galaxy and then meet up with other ships very quickly. You’ll need to make a decision. So as we design each ship we are deciding whether or not they are Quantum Travel capable and atmospheric landing capable. So these are things we’re deciding and it’s on a ship by ship basis. When will we get to see this? Well that’s a great question! We’re still, we’re working on these we’re making these ships as fast as possible however all of the ships that are medium size or larger are definitely going to have interiors that you can walk around in. I discussed earlier things like being able to access the components from the inside. That’s going to be a big thing and so yes there will be interiors that you can walk around with, walk around in. And then interact with other crew members, components, systems. There will be standards things we have like beds, bathrooms, etc DV: We want to give players a reason to walk around these large ships. A reason why you want to walk down this hallway and open this door and other than just, besides having the reason of just having a large ship. We want to give you guys a reason to walk down that hall, open the door, access this panel. Apart from just being for that reason KT: And then we’ll need to make decisions such as how do we make modular components for these ships so, at least on a ship level for well when we create a ship like an Idris, it’s impossible to fill every square inch of that thing with custom geos so we need to figure out what a standard hallway is, what a standard room is like, what the engineering station is going to be like, what the, if there’s an engine housing room, if there’s a cargo area that we can make modular and place on several parts of the ship if there are landing areas for that ship how do we figure. We make choices so that we can make a ship that’s functional and is within reason schedule wise because we want to create the best as quickly as possible these are things we consider when we are designing and ultimately building the ship from nothingness to something that we can actually see in the game DV: Let me give two examples. For those who are anime fans look at the Cowboy Bebop anime series. you’ve got the Bebop ship that carries: spike’s, swordfish. And you’ve got also Faye and Jet’s smaller ships. They use the Bebop through Warp Gates carrying those ships even though the Bebop can land trans-atmospherically it still has smaller ships that it can with it. But if you look at something like Battlestar Galactica where they have giant fleets of ships and some of them are orbital space stations that are jump capable but something that is shaped like a ring or like an orbital station is not going to be able to land so you want to have shuttles and lighter ships, well they’re called lighters, that can go inbetween ship to ship or trans-atmospherically up and down. We’ll even have orbital docking yards where you get up from there and you take a taxi or a shuttle back down to the surface. It’s ultimately going to be decided by what that gameplays need is, what the ships functionality is going to be is, what the role that ship is going to fill. So ultimately there’s going to be an ultimate large size of what ships can land something like… KT: I don’t think we’ve made that decision yet. I think we’re going to decide on those capabilities based on the role of the ships. “What is that ship made for? What is the reason to own that ship?”. Then we’ll make a decision about those particular characteristics at that point DV: Right. I can figure something like a Bengal Carrier trying to make a landing would cause major atmospheric problems.
AragornBH asks: What is the most useful suggestion you have received from a Star Citizen backer? Did it change the way in which you value feedback?
DV: This is a very subjective question and we filled you with a lot of technical details today, especially as far as a lot of component information. We get a lot of input from all around because this is a crowdfunded game we get a lot of input from players on where they’d like to see the game go; what ship we should create; and ultimately while we are following Chris’ visions we still like to solicit feedback from the backers and our from audience. The most interesting one that I got was a possible cultural faux pas I did back in one of the original 10 for the Producers where I made a joke, what I thought was a pretty safe joke, it did end up offending a couple of backers from a particular geographic region. KT: Please do tell. KT: [to camera] I didn’t know about this! DV: Someone asked me how did I meet Travis or what’s it like working with Travis. And I said I’d met Travis in a, I think I said, Serbian prison camp: he took a knife for me once and I’ve been indebted to him ever since. KT: Ah. DV: It was said, just, offhandedly there was no intention … I could have said a Japanese prison camp or an Antarctic prison camp. It didn’t matter, the joke was regarding the prison camp itself that he took a knife for me once and I’ve been indebted to him ever since. That was the joke but because I used a certain countries reference that does have a history of particular turmoil a lot of viewers from that region were really upset. And I know it sounds very superficial but it actually did change the way present information and the way I think about certain answers and the way I actually approach certain individual within in the company as far as being more, not necessarily being politically correct or culturally aware, but it did remind me that we have a very wide audience. And while trying to walk the neutral line is an impossible thing ultimately there is a way information can be presented in a very humorous way and while still being able to maintain an objective conclusion. KT: Staying professional is pretty important. DV: Right. Anything from you? KT: I can’t think of anything specifically. What I will suggest though is that we do get a lot of feedback from the community and it’s terrific. Keep it coming. We do read everything and we do consider everything. Some things are simply impossible to implement or it’s not feasible within either the design or the scope of the systems or the … DV: Or technical capability! KT: … the world we’re creating. However we do enjoy all the ideas. Any idea that comes from the backers and the community is welcome. So let us know your feedback because without you voicing your opinion we don’t know what you guys are thinking. So continue that and we welcome it all. DV: Yeah. We could be working on a great idea from our perspective, looks absolutely amazing and kick ass, but we put in game and realise a lot of players aren’t using it because they might find it boring or it may not fit the original vision we had for it. So this is where a lot of feedback from you guys comes in. So I want to amend my answer a little bit: while that one instance I gave is something that changed my perspective we do look at everybody, as Kirk says, we do look at everybody’s suggestions and it is those suggestions that help mold the game. KT: We got these questions from you guys! DV: Yeah, absolutely.
DV: So again it’s been a very, very technically oriented 10 for the Developers with Kirk giving us a lot of information as far as the Components system and how a lot of that fits into the game system. So hopefully you guys enjoyed it. We try to keep it as entertaining as possible but again we wanted thank the Subscribers for being able to make this kind of content possible: without you guys none of this would be able. So from us it is a very humble thank you for making this capable. Once again I’m Production Coordinator Darian Vorlick.
KT: And I’m Lead Technical Designer Kirk Tome.
DV: So thank you again. Thank you for watching this 10 for the Developers. See you guys next time.