As per usual, anything said during the show is subject to change by CIG and may not always be accurate at the time of posting. Also any mistakes you see that I may have missed, please let me know so I can correct them. Enjoy the show!
Main focus being performance pushes
Hoping to get new builds out everyday if they can to Evocati because of the new Delta patcher
Next steps is focusing on shopping/commodities feature to present to Evocati
23 must fix issues
Jake and John broke Chris' goals into sprints and partnered with Animation, Audio, Visual Effects and Engineering
Included G-forces, hit reactions, visual effects and lighting states
Started with one cockpit type "HOTAS CL" which is used by 7/8 ships including the Gladius
Adjusted the position of the joystick, throttle, seat, main gun
Added VFX (sparks, smoke, fire, debris) to indicate incoming damage and damage states (slight, medium, heavy)
Hooked the Actor Status System into the G-force system: players consume more oxygen and use different breathing techniques
Ensured the UI screens were very consistent and of sufficient size to be easily read without zoom
Bringing back the combat visor interface support screens: by default will show player's and target's status
Improved and reapplied the control templates to the HOTAS CL ships (with scope for future actions too)
One goal is that a player should be able to work out everything a ship does through Interaction Mode
Animators are tuning G-force experience so it feels correct, adding idles and fidgets
Hit reactions are based on the direction you are getting hit, from all six axes, blended together
When the player performs an action there should be physical reaction in the cockpit (and ultimately the character performing it to)
Changed the enslavement process between seats and players which massively simplifies setup
Cockpits are now being designed with redundancy for future functions that could be added.
It was a global effort to make the cockpit redesign happen as it affects the core of the game’s code and without proper coordination, the game would cease to work.
Sandi Gardiner (SG): Hello and welcome to another episode of Around the Verse, our weekly look at Star Citizen's ongoing development, I’m Sandi Gardiner.
Chris Roberts (CR): And I’m Chris Roberts.
SG: Yes and on today’s show we open the canopy and climb into the pilot's seat to check out all the changes being made to cockpits so stick around to see the latest enhancements to the flying experience.
CR: Yes but first as you know the Evocati got their hands on 3.0 last week and ever since they’ve been busy reporting issues and helping us track down various blockers as well as allowing us to focus on areas to optimize. So the team has been pouring over their feedback and thanks to the new Delta patcher we’ve been able to easily release fixes and updated builds almost every single day which is a pretty cool thing. So let’s see how this expanded team of testers has affected this week’s Burndown.
Eric Kieron Davis (EKD): Welcome back to Burndown, our weekly show dedicated to reviewing progress on issues blocking the release of Star Citizen Alpha 3.0. We’ve not only been delivering updated 3.0 builds almost daily to our Evocati testers. We’ve also begun closing down necessary bugs and tasks to improve our cargo and shopping experience so let’s see how the team’s progressing.
Oct 9: Wilmslow Studio - Leads Meeting
Matthew Webster (MW): We went out to Evocati on Thursday for the first push which was really, really good. So thank you to everyone who was involved with making that what it was. We also put out another update on Friday as well with some further viable fixes. The main ones being a physics fix to try and help the performance and also an update to the crash handlers so they can actually start getting crash reports back cause it wasn’t working previously.
The new patcher meant that people were getting their updates anywhere between 30 seconds and 5 minutes depending on internet connections so the new patcher is really, really going down well with the community, they are loving not having to download 20 gig at a time every single time.
Chris Danks (CD): One of the reasons we’ve been able to push every day and it’s been successful is because of the Delta patcher and what that means is that instead of having to redownload entire PAK files, we can just download what’s changed. So this has brought the patching down from hours in some cases to minutes. One of the other advantages of the Delta patcher is that we can actually downgrade builds as quickly as we upgrade to them, so if we put out a build and there’s something spectacularly wrong we didn’t catch in testing… we can just roll back to the previous version and find out what was wrong.
James Stevens (JS): The main focus lately has been on performance pushes, specifically requests from Chris Bolte. Usually what will happen is we will be getting a QATR or test request from Chris to say he’s put in some new code or changed some things up to help improve the performance of the Stanton system. What we’ll do is we’ll grab his latest binaries, put those into the latest build we have and start doing usually a full blown barrage of tests on everything, so that would be in like Stanton, that would be in other sections as well but specifically Stanton which has been struggling lately especially with the rings in Port Olisar.
Christopher Bolte (CB): The performance when 24 players go crazy on a server, this is something which internally we have struggled to always reproduce to reload of the weird system and then exacting feedback loop, I think in the single player I think we had like 200 entities active and 16 players just join the Olisar place we had like 500 entities active. Now I look at the server for Evocati with 24 players playing for sometime we have 5000 entities active residing in a not optimized frame rate and this is basically the fun for the next few weeks to actually figure out why we update so many entities. Do we need to update them? What is actually necessary. We need to do more testing with 24 actual players but it’s not really practical to have 24 players constantly testing all the game especially if you want to have more players in a server. Just imagine if you actually managed to have a 1000 players in a server, we cannot have 1000 QA guys playing the game 8 hours a day, it’s not really reasonable.
Oct 10: Wilmslow/LA Studio: Live Release Sync
MW: Once we’ve figured out the last 10,001 disconnect issue we’ve got a build here from the UK that just deployed… that was kicked off earlier this afternoon that should the fixes for the disconnect seem like they’ve taken. We could get another code build done or a full build if we absolutely needed to, go through the process of putting that out to the Evocati so that we can get those fixes rolled out to them today which is good. A couple…
CR: I mentioned the Project Leadership meeting but it’s important that the qualitative feedback is filtered through Todd and we’ll make priority calls on it because there’s some stuff like the 10,001 error codes that we’re definitely fixing but then there’s some subjective feedback of like that are done like this or I do like this or whatever. Now some of those issues their calling out are things that we already know about or already working at addressing.
I always get a bit worried because first of all we’re getting kind of subjective feedback that’s sort of anecdotal and so you know some of them can have a strong opinion but that can be their opinion and it may be different from someone else’s opinion, so it needs to go through the filter of what’s on the very high level of kind of design side to make sure that it’s something we want or agree.
Because a lot of times people can’t see the big picture when they’re making feedback because they don’t know where the… they’re like, ‘well, this is missing I need this’. We’re like, ‘yeah, no shit, we know it’s missing it’s kind of on our task list. We’re working on it right now’. We understand that it hurts your ability to dogfight if you can’t see the status of your target or status of your ship.
So, I just want to make sure we do that, I’m a little worried if we automate it, suddenly the subjective feedback will get written up as a Jira to get put in someone’s bucket, maybe they get it assigned and it’s like we’ll spend some time working on stuff that needs to have kind of direction and order of priority called out. Sometimes what people want to get fixed, the solution is somewhere else to fix the issue they’re complaining out. So on the subjective stuff I want to make sure we’re going through a filter on that.
CD: So one of the best things about having the Evocati testing the builds with us is that suddenly we have this test bed of 800 people on top of the people who we employ here and it means that the number of issues that we can test and the stress that we can put on the servers goes through the roof and that really helps putting the pressure on the servers that needs to be done.
Wilmslow/LA Studio: Directors Meeting
Erin Roberts (ER): It would be handy also when we get to the stage of when we’re looking at what we’re going to launch... if we do this everyday as well we actually know what stuff is fixed today or going in today as well like that information would be great.
Ricky Jutley (RJ): Yeah.
ER: I know you put it at your fingertips but that would good so we know kind of what we actually are putting into the builds and so forth. Then that information is passed to Will and those guys because they need it to tell people but I have no idea.
RJ: I think Tuesday’s basically… I think moving forward Tuesdays will incorporate the Live Sync within the Director’s Sync and PU will have to go first and people obviously listen into that kind of stuff and then that will be the way that Tuesday has to kind of run.
CR: I think what Erin was saying which is kind of what I was actually going to bring up was the way I look at it is we’re in Evocati now. We’ve got 800 testers instead of 70 testers and we should be looking to deliver a build everyday if we can to them because we have the Delta patcher but the key is not so much about ‘oh we’ve got this one blocker’, right? There’s a crash here or deadlock here, which is sort of the approach we were taking in getting it to Evocati. The key is like ok, what bits of the things we still have left to do are vying for this coming Monday. What have gone in Tuesday? Cause I don’t want to just only have like one blocker fixed right? Cause you’ve got people finishing content, doping lighting, ok… these three areas now being lit, they’ve gone in. There’s this ship that’s now being brought over to Item 2.0 that have gone in, that’s kind of the thing. What we actually want to do is have a steady stream of things that are getting finished off or fixed up putting in and we want to know ok here’s an Evocati, here’s the things that have gone in that we think we fixed because you’re basically… you just got to sort of manage that over time. So we’ve got get into that mode as opposed to the ‘what three bugs do we have to fix before we can go to Evocati’.
MW: So the next steps for us here in CIG is we’re focusing on the shopping feature, shopping and commodities, as a feature to present to Evocati say this is now in a state where you guys can just go nuts, go ahead, buy/sell, do whatever you want.
Jake Ross (JR): We’re fixing bugs left and right, we’ve got issues where certain clothing and items aren’t showing up in the shops right. There’s issues where you can’t interact with an item through a glass case because the glass is getting in the way with the interaction system, so we’re trying to figure that out. We’re trying to also work out some kinks with the try on mode where when you look to inspect an item, like a ship component or something, the character will look around like he’s got gloves on and he’s looking at his gloves. We’re ironing out kinks getting everything looking really well.
Spencer Johnson (SJ): So right now we’re focusing on a suite of different shopping related bugs and features that we’re trying to push out to Evocati soon. Today a couple of them are focused on the weapons being attached to the item ports on the shelves, so we’ve got trying out a weapon in the shop drops it onto the floor for remote players. Weapon models disappear after inspecting them, these are the great kind of bugs because they aren’t 100% repro so they only happen sometimes, which are always the best to find and solve.
MW: So what we’ve done is we’ve taken our top issues that we want to get fixed, these are a collection of bugs and tasks, we’ve gotten those together. We’ve put them into the Evocati fixed version in our internal Jira tracking software and this is where we saw the Burndown graph from last time so when you see this report go out you’ll see the new list of numbers… sorry, the new total number.
EKD: So as you expect we’re seeing new issues daily from our influx of additional testers that we’re fixing immediately in order to improve this release and at the time of filming this we’re at 23 must fix issues. So come back next week to see how we’re doing and to keep a close eye on the in depth details of the last remaining issues blocking the official SC Alpha 3.0 release here on Burndown.
SG: Tune in next week to see how much progress we’ve made on the Evocati release, you can explore more details about what was accomplished by checking out the production schedule report on our website.
CR: Yes, so now let’s turn our attention to this week’s feature. So players are going to spending a lot of time in the cockpit of their ship so it was really important for us to make sure it was as visceral and engaging as possible. Some elements like the player suffering a red out due to excessive g-forces are already in the game but we always knew we wanted to do more. So we kicked a series of sprints focused on the cockpit experience for you in Star Citizen and in Squadron 42.
SG: These improvements involved designers, animators, VFX artists and many other disciplines across the company since the changes would utilize a lot of our new tech like actor status system, Item 2.0 and other recently implemented systems.
CR: Yeah, so let’s check out what changes are coming to your ship’s cockpit in this week’s feature.
Jake Ross (JR): So the origin of the Cockpit Experience Sprint was started with Chris take a look at the overall experience of the player within a ship cockpit. And wanting to make that experience as visceral as possible he looked at sights and sounds and effects and just the overall feeling of it. And wanting to make it really feel special. And so we all got together and brainstormed different things that we wanted to see. Chris laid out his expectations. And then John Crewe, Lead Tech Designer there in the UK, and I partnered up to make this happen.
So John and I sat down and outlined Chris’ goals into what we’re calling a “sprint breakdown”. So we started with “Okay, here’s our expectation for the first sprint. Then the next sprint. The next sprint.“ And a sprint can be two weeks long - two to three weeks - usually around two weeks long. And we started with “Just what does it feel like to be in a cockpit flying around?” And so we partnered up with Animation - Lead Ship Animator, Jay Brushwood in Austin. We partnered up with Audio team, with Visual Effects, Engineering to make this an overall amazing experience while flying a ship.
We got our design laying out the expectations, specifically breaking down the tasks based on the high level direction from Chris. That includes things like G-forces - updated G-forces - and how does that feel? Hit reactions in the cockpit so when someone’s shooting and firing you’re not just standing there static but you’re actually reacting to the … to the hits of the ship. And then what happens inside that cockpit whenever you are getting hit by another ship. So we have actual effects that play in the ship cockpit. Air decompression and flames sometimes, and the lighting changes depending on whether you’re just in default mode, if you have auxiliary power running, or if you’re in an emergency state - it’s time to get out, it’s time to eject! So we definitely wanted to make that feel real and as if you were actually in danger.
At first we focused on just one cockpit type. So we took the Gladius as a test case which uses our specific cockpit type, what we’re calling, the “HOTAS CL”. And there are seven or eight ships that use that cockpit type and so we focused just on those seven or eight ships to make those really feel special.
So what we did was we took the Gladius cockpit and we said “Okay how can we change the interior of this cockpit to make it look really … look … to make it feel and look different to the expectations that Chris was looking for. So we actually shifted the seat a little bit. We changed the positioning of the throttle and joystick. We adjusted the position of the front weapon - ship weapons - so that when you’re firing the weapon then you can actually see muzzle from where you’re sitting in the cockpit and as a result you see the muzzle effects as well. So not only are you seeing what’s going on inside your cockpit but you can actually see the effects of … when you’re firing your weapon stuff as well.
John Crewe (JC): It’s a huge, ongoing process. We’ve obviously got so many ships that we just can’t do everything we want to do with them all in one release. For 3.0 we’re starting with what we call the “HOTAS CL” ships which is an animation template. So that’s Gladius, Buccaneer, Herald, Cutlass, Sabre, Vanguard. And they’re all getting a range of improvements to the cockpit which will hopefully make the overall experience much more enjoyable.
Michal Piatek (MP):In previous versions of the game we had no visual cues on whether you vehicle was damaged or not. We only had a simple implementation where we had some damage effects playing when your ship was about to explode. But that was very simple and not very informative. So we wanted to represent different stages of being damaged - so slightly damaged, medium damaged, heavy damaged - and we also wanted to inform player that their vehicle is actually being shot at this very moment.
So we created some VFXs - such as sparks, smoke, fire, debris charges and things like that. So whenever your vehicle is being hit you will see some effects playing. Also depending on the health level of your vehicle you will see more or less of these kind of damage effects.
So we took these effects - I placed them manually - and using basic implementation we incorporated that into game to see whether it works - whether it is giving enough information for the player. And because it does we’ll take it a level further and we’ll create a proper implementation of that.
JR: So the improvements.
First up we’re tying in the Actor Status System - so you’ve see that with all the breathing and stamina - that’s all now tied into the G-force system from the ships. So as you suffer G-force from your actions in the ship it causes stress which builds up stamina, makes you consume more oxygen. It actually changes your breathing in the ship so you get all the … like you see fighter pilots have to do various breathing techniques to manage breathing under high G-force.
So as you’re pulling high G-forces you’re going to hear that physical change on your character. If you ever got to the state where you were pulling so much G-force and you suddenly got out the ship, you would feel that stamina effect. You’re not instantly getting out the ship back at full stamina: you’re paying the price for your actions previously.
Another aspect is ensuring the UI screens on the cockpits are very consistent and minimum size on screen. Because a lot of our cockpits were done two/three years ago and the UI is significantly changed for 3.0 and we need to make sure there’s a minimum amount of screen space dedicated to these UI elements so you can actually read them without having to zoom in. ‘Cause there’s lots of issues with some ships where, to read them, you have to zoom all the way in to read the text which, in the middle of combat, is not something ideal.
So we’ve got templates for all the screen going across the those. That’s why you’ll have see in previous ATV’s things like the Gladius cockpit screens have changed. They were way too small to be visible so we’ve brought them closer to the player, made them larger, we’ve angled them in towards the player to reduce reflections, and added more of them.
We’re also bringing back the combat visor interface which you see up on the top left and top right of your screen. So you can have … they’re essentially support screens so you can move information from your support screens up to those if you want. But by default they are your self status and the target - or pinned target - status so you can get an overview of those.
Another thing is we’ve worked with the Animation team about the poses in the cockpits. So across all of our 60+ ships we have about six to ten different poses. So every ship fits one of those poses. There are a few that are unique, like the Nox, but pretty much every other one is used across multiple ships which dictates the throttle, seat, control or yoke status as well as a range where they can interact with within the cockpit.
So over time we’ve picked templates for certain ships. Modelled the ships around those. As we’ve found they’ve been adhered to in various levels of accuracy. So you’ll find one ship had the template put in. When the artist was modelling they thought “Maybe if I move the joystick one centimeter to the left that looks better in this cockpit” which is fine - the IK solution can deal with that. But then what happened was the next artist came along and went “Well that ship uses that template, so I will use that template that they’ve got in that ship. So I’ll take their geometry oh but this is actually move … well if I move this another centimeter to the left it fits this ship better.” So over time some of the joysticks have got further and further away from the player. So when you get in the seat and the animation plays - which is the same animation of grabbing the sticks - you get this horrible snap where they go to the actual poses.
So for those ships earlier that I listed we’ve redone all the controls. They’ve all come back to the default position which we actually changed - so every ship had to change to match it - because we had decided was the template wasn’t as good as it could be. So all the ships have their joysticks and throttles changed slightly. They’ve all been remodelled to fit the hands better. They’ve all got buttons on the control inputs so we’ve got enough geometry and animations to play with for firing your guns. You can move buttons on it using afterburner or boost. You can use buttons on the sticks. We’ve gone through all the screens - which are now larger - they now all have buttons on there so all the future actions - will be interacting with the cockpit - have space.
One of Chris’ goals was someone that only knows how to use Interaction Mode can sit in the cockpit and just use that to workout what everything does in the ship. So they’ll be able to go into Interaction Mode and work out how to turn the ship on just by looking around the ship - looking at the buttons that highlight, looking at the feedback they get and be able to do everything from that.
Jay Brushwood (JB): Primarily what the animators are doing is … we’re working on tuning in the G-force experience so it feels properly … where the camera sits in the cockpit in relation to where you see all your UI and stuff like that. Finalising finger poses, adding in idles and fidgets and anything that can breathe life to the cockpit. It’s been something that we’ve been focused on over the last three or four months and there’s still more work to do - there’s always room for improvement - but I think for the 3.0 release we’re going to be at a healthy spot that will give a lot of players some satisfaction flying around.
We’re improving our technology and we’re improving the animations that we’re doing but we’re also putting in these systems that can rely on the overall health state of the ship. So the UK programming team have implemented hit reaction animations that happen based off of what direction you’re getting hit from - from all six axes - and they blend together and basically you get jostled around in the cockpit on the direction that you’re going. And that gets overlayed on top of the character animating his hands - throttle and joystick - and in addition to that the overall posing, fighting of G-forces that we have for the third person. So it’s a culmination of a lot of different things.
There is a lot of technology overlap between animation and design and the programming team to get the overall desired effect. And we have review gate meetings where we all take a look at it, look for ways to improve it, think about new features like “Oh, maybe your health … the health of your ship gets to a certain percentage then the red lights start blinking, there’s fires going off, and there’s sparks flying. Emergency lights are going and then that way you know you have to hit the eject button.”
The G-force animations and the blend spaces we’re using are all hooked into the IFCS system that drives the ship. So we’re using actual G-force simulations that result in a blended animation state for a particular set of G-forces coming from x, y and z.
JC: The objective is to make it feel like a living, breathing vehicle. It not just you press a random button on your keyboard or HOTAS and stuff happens. It’s … that’s tied to a specific action which will have an in-game reaction to that. So you press the “engine on” button in the cockpit and it will move and rotate, and long term, your character will go out and interact with that automatically to do that when you press the button. So your finger will reach out and touch it - twist it - whatever the button is.
The first step is getting all those buttons mapped out on the cockpit and interactive. The next step is those buttons animating themselves - so you do the action Interaction Mode or you press the shortcut key - you see a physical reaction for those things. And then the final step is the whole player leaning out, touching it. Which is another reason why we’ve had to adjust all the cockpit screens: so they’re all within arm’s reach of you because we don’t want the player to … you press a shortcut key whilst you’re flying to change something, you don’t want your character leaning forward - bend double - trying to reach a button that was too far away because that’s going to mess with your view; it’s going to be unpleasant to deal with.
On top of the animation unification we’ve also changed how our enslavement process works between seats and players which massively simplifies set up across the board. So when you’re sat in a seat that allows you to do other actions that you could do standing up. So for instance it instantly allows you to do upper body animations that are set up anywhere else. You don’t have to have to set up, say for the Gladius, an emote for saluting. That would have had to have been a Gladius-specific emote, whereas now we can have a HOTAS CL emote that works across all those ships, probably in fact across all of them. So the actor enslavement changed which is great.
JR: So we’ve had a lot of new technologies in place specifically for the cockpit to make it feel a lot more visceral. Romulo Espinosa, who’s one of our gameplay programmers in the UK, has been a really huge help with that. At changing the way the seats are set up, the way the IK in the arms works so you can have a little bit more reach and things like that. So there’s been a lot of different new features developed just for this sprint that enable the artists and the animators and the visual effects artists to make their stuff look as great as possible and feel as good as possible.
Romulo Espinosa (RE): For the cockpit experience we had to implement a different type of enslavement. So what we were doing before this new enslavement we were using the old one. So for the old one we had was two ADBs - an ADB is just an animation database with all the animations we use for that entity. So in the old enslavement we had one for the vehicle and one for the seat. And then all the animations were banked with that.
But the point with that is we were deactivating the player basically. So it was the seat that was saying “I need you to play this animation which is stored on my database.” But in this case that’s … for this project, that’s madness because if you need any animation on the player you need to copy those animations to the seat. So you need to play emotes, you need to fire your weapon while you are sitting, or whatever you need to add all those animations into every single ADB and we have a bunch of ADBs: one per seat, per ship. So it’s impossible.
So we created this new enslavement which is the seat is still in charge - it’s who says “I want you to play this animation” but the player is still active so the player itself can still play animations. So we don’t need anymore have to add those animations into every single ADB we just say “I want you to play this animations player and because it’s on you it’s up to you to play it.” So the player is just going to do it.
You have two options really can enslave the player to the seat or the other way around. But in this case the seat can move or we have these animations with the canopy opening and stuff like that. So you want the player to move accordingly to the seat and not the other way around. We don’t want the player to stand up and then the seat move or whatever. What you want is, you want to move the seat and then the player react according to that movement. So that’s why we enslave the player to the seat and not the other way around.
JC: Another part of the sprint is setting up the light group and light group transitions for cockpits so it’s something we’ve had in our multicrew ships is the damage states, VFX and lighting triggers so when your ship is damaged you have all this cool VFX and lighting of the ship in the motion state but we never really had that on the single seaters so we’ve started doing that in those ships. So rather than just purely relying on UI element telling you you’re low on health which when you don’t have the CVI in 2.6.3 it’s incredibly hard to tell where you now have the cockpit lights flashing red, we have all the damage effects… smoke, flames coming in the cockpit so it really does hammer it home what state your ship is in and when you repair it, it all goes away and it all goes backwards and forwards.
Mike Snowdon (MS): For the cockpit experience for the VFX team it was more about the damage, specifically directional feeling of the damage. So currently in the game we do have interior damage but it’s more… it’s not really directional so you don't really get a proper sense of where the attack is coming from.
MP: All the VFX are coming from the cockpit model itself. We are not creating the cockpit, we are taking whatever is being created and we making sense out of it. So you won’t see random effects coming from random places. It is thinking about what will happen like what devices are on in the cockpit and what type of distraction you would see on an actual vehicle of that type. There’s a lot thought into that.
Placement of effects has to be done manually so each vehicle has a different cockpit. So I need to not only place these effects so it makes sense, we don’t want for example fire coming off a fire extinguisher unless it’s made in U.K. but that’s a whole another story.
So the placement is done manually, but we are creating a library of effects so we can use the same effects made for a Gladius on another vehicle, but it will look different because the context is different, these VFX are coming from different objects and locations so it is making a huge difference.
MS: When you’re in the cockpit, the type of effects you’re going to see will be sparks, smoke, nothing that’s going to be too kind of in your face so you can’t see where you’re going as you’re not going to want that necessarily either, unless you really are in big trouble and that is new compared to what we’ve currently got in the game. Currently in the game it’s either the damage is on or off really so we don’t really get a sense of where anything is coming from.
RE: So for the cockpit experience we always try to give the player more feedback. So we decided to create like different blendspaces for hit reactions and pass out and wake up animations. So basically a blendspace is an asset that allows us to have any number of animations blend between them according to different input. So for instance if I pass out and I want to give the player different inputs according to the Gforces, we cannot just create one hundred animations. We can have like 10 different animations or maybe 5 different animations and according the input in this case the Gforces we can blend it in those assets, play really nice animations in between that.
So we did that for the pass out and wake up and the hit reactions are the same thing so in that case the inputs are distance of the impact from the ship and then how heavy is the thing that is impacting the ship so it’s not the same to be on a Gladius and someone throwing you a four or throwing you one of the big ass missiles so we needed some kind of different animations to give the player some feedback from impacts.
Apart from that we worked on animation driven IK. with animation driven IK we have two different systems in place: one is the limb IK, and the one is the animation driven IK. The base for both is the same thing, but the way they are activated is different. So for the animation driven IK it’s the animator who says I want to use IK at this point in animation, I will want to use this IK. What is that IK for? So when you try to read an object or in this case of the cockpit the throttle on the joystick or maybe this thing will because those objects are moving, we need the hands to move with them otherwise you will see some kind of delay that you can see in other games. So that’s why with this IK we can put together good together hands on those objects and that’s why the animation driven IK is for. The limb IK is the same thing, but we activate it in call.
JC: Before the official sprint kicked off we did about 2-3 weeks with myself, Jay, and VFX guys just going over various alterations. So we picked the Gladius as the test case because it’s used by far the most in Squadron so you’re going to be sat in there for a long period of time so it needs to be something that good. An easy place to understand, we went through so many iterations of is this seat in the right the place? Move the seat up, down, left, right, backwards, forwards, move the screens forward, move the canopy bars around, move the buttons. We had a list of 20-25 actions that we knew we would need in every cockpit so that’s in the new guidelines and then there’s about another 10-15 that need to go on the control inputs. So either your stick and throttle or your yoke or any combination of those things.
We’ve built more in for redundancy so that anything in the future that needs an action that doesn’t we’ve got space to do it and don’t need to go back and redo it again. There was a lot of backwards and forwards with multiple departments to getting where we’re at.
While we could do this with the old item 1.0 ships it would have been a huge amount of throwaway work so once we were in the process of doing the conversion to 2.0 as we started doing this sprint. So we managed to tie them both in together, but with item 2.0 it makes it all incredibly quick and you set it up for one ship it takes minutes to set up on the next ship rather than hours or days, having to manually duplicate everything we would have had to have done before.
I think that the most challenging thing was the amount of ships that we had to deal with because there was some pretty big decisions we had to make whilst doing it knowing if we change this template then we have to go and revisit 10-15 ships and it’s getting all the directors and leads onboard and agreeing that if we do this, it’s a big change, departments are going to have to do lots of work, but it unifies everything nicely in the future and any changes we have to do automatically happen across all the ships. You don’t have to do that change 15 times anymore, it’s you do it once and it just works, but it means you don’t get to work on these other cool features so no one likes going back and feeling like they’re redoing stuff, but sometimes you just have to bite the bullet and revisit what you’ve done to make it better for the future.
RE: In our game getting into a seat is not just a personal battle about getting there, no we need to move the ladder, we need to open the canopy, we need to move the taskbar, we need to move the seat, we need to take a sit and push some buttons. All the sequence that you need the player to be enslaved, I think that’s the most difficult thing in our game which is do you play all that sequence and they still don’t lose control of the entire sequence and the entire thing. Another thing that was quite challenging was the animation driven IK. We have to basically rework the entire thing that we were using for animations. We had to basically reinvent all the way we were processing all the animations in order to get rid of that one frame delay we were having so basically we were having an object in our hand, we were trying reach this object and basically the hand was always behind because this object, this hand was moving first before the object. So were always one frame behind, but in the case of this new animation IK, after our changes what happens now is because I’m enslaved my hand is kind of enslaved to this object and when I leave the object to move first and then with that up to date decision when I move the hand and then we are in sync all the time.
In this case it was kind of a brute force, a gigantic email between all the clever people: Chris Roberts, Evo, Jenz, bolte, everyone in the company was trying to get this thing right because this goal has been there forever, but if we break this code, nothing is going to work in the game, absolutely nothing and everything is going to break, mannikins are not going to work, the character is not going to work, the editor is not going to work, of course the game is not going to work.
JR: So the plan for right now is to release the various features apart of the cockpit experience is chunks or phases. So the changes we’re making on the cockpit experience spread was things that were always things that were in the works, they were always planned to happen, but really it's been Chris’ vision from the beginning, but because it required so much attention from so many teams across the project, there was never a considerable focused effort between all those people at the same time to make it happen. So what really it took is this gathering of people, coordinating everyone in a sprett structure to get everyone focused all at once into making the cockpit experience really to the same high quality standard that has had since the very beginning.
CR: So as you saw smoothing out animations, adding hit force reactions and damage indicators are just some of the ways that we’ve upgraded your flying experience.
SG: Yes, very cool and you’ll see some of these features in 3.0 while others will be coming in later releases and Squadron 42.
CR: So once all these features are in it’ll help create the immersive gameplay experience that we’ve all been striving for especially me.
SG: It sure will and that’s it for today’s show. We’d like to thank our subscribers for supporting all of our shows, October subscriber flair will be released this week so scout out a spot in your hangar to display the next set of ship schematics.
CR: Yeah and finally it’s been just over 5 years since we first announced Star Citizen at GDC in Austin on October 10 which was two days ago and it’s incredible to think how far we’ve come in such a short amount of time. It’s only been possible because you support us along the way, so a big thank you to all the backers out there and for all you’ve done over the years it’s really, really appreciated. Actually in the light of you guys backing it there’s a couple of cool little gifts that we got recently so if I pull them out here. One we got a really cool patch from SFCMoon, who’s just returning from his tour in Iraq and he I think even arranged a Bar Citizen or a get together at least in Baghdad, so it’s pretty amazing how far we have… we’re everywhere, it’s really cool. So yeah, thank you very much for sending this very cool patch and much appreciated and then also I got a really sweet letter from Louis Carrian, who is obviously French and probably can pronounce his last name far better than I can. His father is I guess the biggest French collector of meteorites and also has I believe a kind of mineral…
CR: Yeah, and he sent this so I’ll open this on camera but anyway he said ever since he was 4 years old, his dream was to go and explore the moon and as he got older explore the entire of space. He’s always thought he was born 100 years too early then he discovered Star Citizen a few years ago and it was a revelation and in a way his dream is going to come true so he was a fan of Wing Commander in the days of Freelancer and he’s really thankful and so he sends this gift and with a book that was written by his father and also a very cool…
SG: We can open that after the show, we can open it in the credits… rolling credits, really?
CR: Really, why not?
SG: Yeah, rolling credits…
CR: Rolling credits…
SG: So we can get a close up on it.
CR: We’ll see, we’ll have credits I’m going to get started, all finished. There we go and...
SG: What is it?
CR: It’s a meteorite so here we are, really cool. So thank you very much Louis that’s really, really sweet gift and thank you very for your support and thank you to everybody for your support, it’s pretty amazing to be here and building the game at this scale and scope that we’re doing and it’s all down to you guys. Thank you very much, looking forward to many more years of expanding the Star Citizen universe and giving you amazing stories to experience in the likes of Squadron and beyond so thank you and until next week…
SG: We’ll see you…
SG/CR: Around the Verse.