The developers discuss which ships can land planetside, the single-seat Aopoa Khartu Al (Xi'an Scout) and alien manufacturers, and the ongoing component refactor (coolers, shields, sizing, smuggling storage). They also cover balancing ship durability, and pairing features with ships.
TL;DRThe Xi'an Scout conversion is a single-seater with four articulated, dual-sided thrusters that can turn up to ninety degrees; Cutlass thrusters may rotate only for VTOL, possibly the Freelancer too, with landed and flight states for the Reliant.
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.
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.
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.
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.
TL;DRXi'an, Banu and Vanduul are each currently a single species-wide manufacturer, though more alien manufacturers may come later, with care that alien designs fit human ergonomics and the story.
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.
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 componentsDV: 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.
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 ...
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.
TL;DRComponents are being reworked one system at a time into physical, size-appropriate parts that can be repaired or swapped, with balance passes so upgrades involve trade-offs, while shields are being refactored into emitters and generators.
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.
Yup, they'll be size appropriate for their capabilities, placed on ships, with ships that have interiors such as the constellation or the future Idris 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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
TL;DRProducers don't need to master coding or design but must understand what teams are doing, and communication and anticipating bottlenecks are described as their most important job.
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...
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...'
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.
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.
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.
TL;DRComponents were sized into standard boxes so same-size parts can be swapped without custom geometry; most fit only their own slot, though some categories like ammo and fuel may be interchangeable, and smuggling holds are under discussion.
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...
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.
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 onKT: 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.
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 wellKT: 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.
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?
Fuel tank or an ammo boxKT: 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.
TL;DRThey say they do feel pressure to top each release and are confident they can, claiming that planning and standardised production practices keep improving.
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.
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.
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.
TL;DRKirk Tome says ship hulls and shields shouldn't simply be made bigger across the board; instead, once systems like shields are refactored, each ship and component gets a balance pass to make combat more tactical.
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.
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.
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.
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.
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.
TL;DRThe developers say features and ships are planned together so a feature has content to use, such as a ship for a mechanic, and the supporting systems must exist before the ship is built.
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.
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.
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.
TL;DRLanding and quantum travel capability is decided ship by ship based on role, with no size limit set yet, and medium-size and larger ships will have walkable interiors, though no date is given.
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, etcDV: 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 reasonKT: 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 gameDV: 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...
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 pointDV: Right. I can figure something like a Bengal Carrier trying to make a landing would cause major atmospheric problems.
TL;DRDarian Vorlick says a joke that offended some backers changed how he presents information, and both developers say they read and consider all community feedback, though some ideas aren't feasible.
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.
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.
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.
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 ...
... 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.
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.