Citizens! Check here for Episode 5 of 10 for the Producers including a transcript by /u/Nocturnal_Nick!
Usual Producer intro and Thanks
Travis Day (Back from FPS work) and Darian Vorlick are here to answer your questions!
– On to the Questions! –
DV: The vanguard and hornet have a “swing wing” configuration, but in space there’s no atmosphere to create drag, so swinging them back won’t have an effect of lowering a drag coefficient allowing them to fly faster. So in the case of the vanguard I went to a designer, Calix R, and he replied that there will be a button to toggle whether you want the wings to deploy on the vanguard. On the wing-tips there are thrusters though, so if you want to go really fast, you could swing the wings back to point the thrusters rear-ward to go quicker, but if you want manoeuvrability when they’re fully deployed, there is more “leverage” so the craft can change direction more quickly, but it does increase your cross-sectional signature, so more susceptible to getting hit, though increasing your axial rotation.
DV: Again, I went to Calix on this. When you’re dealing with fusion powerplants, or thermo-nuclear weapons, you’re talking about thousands of Kelvin, or thousands of degrees C or F. That’s not something you’re going to want to shunt inside the cabin. You’d Ace-Ventura Rhino yourself instantly. Talking to Calix, he wanted a system where you can temporarily keep heat, but that’s going to put wear and tear on the ship. Components will likely heat up and fail more quickly etc, so it’s not something that’s likely to be used all the time. It’ll temporarily give you a quick IR reduction.
TD: It’s a cool idea if say you come out of a Jump Point in your Vanguard, do your stealth attack run, then dump whatever that thing is. It’s also one of those things we’ve always talked about, having something to store thermal energy on the ship, it’d just be another thing to have plugged into a hardpoint on the ship. laughs I keep getting back to the thought of finishing a long battle in your constellation and makes prying rhino-butt motion getting out of the ship slowly.
DV: Or also Star Trek First Contact, where Data releases the plasma coolant, and the borg get fried…
DV: Yes and no, we HAVE thought about it mostly in conjunction with capital ships. So if you’re on your Cap-ship leading your armada, and you’re in the large bridge part and the admiral can say all ships converge on this target on a holoscreen, so all the ships in the fleet see that and can follow the directions given on their own maps, yes. It’s all part of the command and control system. But concerning smaller ships like constellations etc, maybe we’ll have a map that a captain can pull up in kind of like a party-mode, where you could see where things are clicked etc.
TD: I could see that kind of system working on a Carrack especially with that giant map-room thing, sketching out plans with a holo-pen with friends.
DV: It seems to be standard MMO fare.
TD: Seems like something you could do on anything, command and control would be present, it’s all been built into the holo system.
DV: I like this question because it’s something we were talking about with one of our animators John Riggs since we were working on that facial capture system. The idea of setting up a booth like that, while cool at E3 or something, it’s not something that’s viable in the immediate future. It’d take a MASSIVE amount of work to translate that into the engine.
TD: I mean, it’s really an economical choice, do we really want to spend however many man-hours of modelling it’d take to individually make, what, a 1000 heads we shoot at E3? First we don’t need that many, we make variants just by pushing around sliders, and secondly it’d probably take us until the NEXT E3 just to process them all.
DV: What about scanning your own face to play your own character?
TD: Yeah, that’d actually be… Well to get the fidelity you’d need to do it on one of our setups, and it’d take a lot of work for character artists to get them into the game anyway. I mean, look at the two British looking heads we did recently, one of our cinematics guys cleaned the models up really nicely, but that took a fair amount of time.
DV: The TL;DR version is that it’s not as easy as taking a few photos and converting them to 3D with a click, it really wouldn’t work like that.
TD: As soon as it is ready and meets with CR’s expectations.
DV: How’s it looking so far?
TD: It’s looking really good, but there are a tonne of things we need to do internally, so when you go buy a new game at the store, for example BF: hardline, and you play it for a month, then think “Man I wish I could do X, or Y, or Z!”. We do that internally as developers too, so we’re seeing the FPS module all throughout its development cycle, so from the very beginning concept to prototype, then to testing and play-testing. I mean, we’re going over it in detail multiple times a day at illfonic. You actually get player fatigue, the same way that a player does with any game, so you see what its missing that’d complete the experience. So one of the first things I did when I got out there was to look at options, so do we want to ship in x amount of time, here are the things we can or can’t do. We do three of those options, and in this case we’ve decided to go to the maximum amount of fidelity at the cost of time. It’s going to be really cool, though, and lots of things happen in the middle that affect it too, like we’re going from Fmod to Wwise audio middle-ware etc. In making that transition, we have to re-setup all the audio. Then we have to bring the FPS branch back into the main branch’s system, which has since had changes like lighting stuff, and ragdoll physics etc. We also have a new item-port system to work in. We’ll have all of these features integrated when we move into main branch, which’ll mean a much cooler release which will also come with AC updated etc, but it does take more time. Sorry that didn’t quite answer the question!
DV: Quite a bit I think! We do integrate a lot of feedback that we get from experts in various fields, but at the same time because it’s a science-fiction world there is a certain amount of suspension of belief involved. For example, the Vanguard is a swing-wing spacecraft, in terms of aerodynamics, it doesn’t matter if it’s a swing-wing or not, but we gave it a purpose anyway, because it looks cool and we wanted to have it in-game. Same thing with a torpedo, traditionally it’s a projectile launched underwater, so it might retain its fins in space, but they don’t really do anything. So while expert critique does factor into our decisions, we have to make it fun, and if a really realistic sim gets in the way of that, I’d rather go with the fun route.
TD: Yeah, it’s the same with what was pointed out on the retaliator, based of his feedback on the original behring marksman, that the torpedos look a lot like Mark 48’s, and don’t have any thrusters on them for attitude adjustment, so we should probably add thrusters on them. The other hard thing about the internet is that a lot of our forum community ARE armaments experts or engineers, but it is also the internet. I mean, when I’M on the internet I’m a soldier of fortune for example.
DV: And I know a lot about physics. I got to teach the art team about gravity for example. No seminar yet, couple of weeks.
TD: talks about the mark 48 torpedos with someone behind the camera
DV: This is an easy question for us. I actually just had this discussion with a few other producers, one of the things we have to look at is whatever given development time we have with internal deadlines, say we have a patch due out in a week, is it feasible or even wise to get all of these bugs fixed and sacrifice feature development. Do we want to take a developer off a feature to fix a bug? It depends in part on how big a problem it is, if it’s a blocker, or prevents a player being able to play at all, then that’ll take priority, but if its something that will ultimately be fixed in normal development, we’ll not usually assign any time to it, because there’s a good chance that down the line a re-design or change made in feature development might actually fix it without costing more developers time.
TD: That’s a great example I was talking about with Paul with regards to the Gladiator release recently. There are certain behaviours within the ship that are exposed in the production of multicrew that are supposed to be handled by the GOST system, like the position of turret seats when a player gets in or out etc, the same thing applies to the constellation etc. All of these issues are handled by GOST, but we get into a situation sometimes where things are broken with multiple people trying to access different parts of the ship, a seat might not reset or whatever. We have to fix that, BUT there are other funny issues where if you use something before another animation is finished that should be mutually exclusive, like maybe deploying a stairwell while closing a door that it goes through, that’ll all get fixed by GOST in the long run, and doesn’t affect the actual game experience.
DV: Actually in the context of the Constellation, because we’re in the middle of a redesign of the ship, it doesn’t make sense to do anything about those bugs, because they might not be present in the new version of the ships. As producers this is what we manage, we might close those bugs or shuffle them off to later versions to check if they exist then.
TD: This guy definitely has some good questions. The answer to that question is both. In the same way that the damage system on the ships was introduced so that it would perform better, looks better and takes less work, the physically based damage of projectiles will reduce the workload (once everything is converted). Right now we’re putting in arbitrary values for damages etc and trying to base those values on what we think should happen, where once this is introduced everything should make more sense relative to everything else. It also makes it so that the barrels for different ammunition types will have to match etc. Yes we do intend to tweak just as many and the same knobs, but they’ll be a part of the physics simulation instead, changing density, size etc. They just come now with physics based names rather than arbitrary “damage” values.
DV: And they can be called meaningful things, like if you want it to be depleted uranium ammunition…
TD: And any changes would be standardised across ships, so if weapons are the same they’ll FEEL the same, which is the cool part! If you make something a real physically based system, what comes from that are game elements that feel right to the player. That’s what makes this such an important thing. AND it’s easier. So.
TD: This is something we already see, like the 300i lineup. The 325 has a better targeting computer so it’ll lock onto targets quicker for its missiles etc. The Aurora LN has better cooling, so it’ll dump heat (without a sump). We definitely do this on a default component basis. That said I think the question was also about whether we have a size 1,2,3 size CPU like we do shield generators etc, and to that I say absolutely. The idea is that the larger the CPU you have the more data it handles coming through in a given time. It may be that the avionics unit itself has a certain size, so you might be able to put a new motherboard or something with more slots for things like targetting computers etc, and how many slots that takes up etc. There will be a level of customisation under the hood that you’ll be able to tweak and change. It is a bit odd that larger CPUs handle larger amounts of data etc, when in modern times CPUs are getting smaller and smaller.
DV: We ignore Moore’s Law.
TD: Yes! Every 8 years OUR CPUs actually get slower.
TD: Yes, 500m/s at one point was a cryengine limitation, but it probably won’t be once we finish moving to the 64bit float system. The question is do we want to. Do I see a need for something to travel faster than 500 m/s in normal space-flight travel? One of the ideas that’s been floating around is for every ship to be limited to a speed with a realistic explanation, is that each ship is designed to perform within an envelope up to that 500 m/s. Everything in that envelope is governed by accelleration. So maybe it’s 300 m/s. You might be able to reach that in, say, 10s. Then when you push out beyond that, you can really only move in a straight line (mostly) because your thrusters are so weak they can’t do much to change your velocity, and your ability to accelerate up to that 500m/s falls off dramatically after you reach the edge of your envelope. That was one of the ideas, which makes the game about acceleration rather than just flat out speed. We’ll see what happens!
Usual thanks and Extro!