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!
A huge thank you to Sunjammer for soloing this mammoth transcript this week!
Last week there were 94 total must fix issues comprised of nine blockers, 62 criticals, 21 highs, two moderates, and no trivials.
Focussing on the must fix issues they currently have, triaging other.
Game development is like life: you can have good days and bad days:
A developer can pull on a thread, it unravels and it fixes the next few bugs stacked up behind it.
Conversely a feature or fix can be given to QA and it doesn't work.
Similarly QA can find one issue and extrapolate it "go down the rabit hole" and end up with 6 or 7 more.
Found and fixed an issue with how the fog interacts with rectangular lights.
Got some new animations to fix a "stretch to talk" shopkeeper issue.
Reworked the turrets to use the correct seat and all designers to better control the turret’s turn speed.
Fixed an issue with the Room System rooms not touching in Surface Outposts.
Reduced must fix issues by 18 (down to 76) and checked in 773 updates to the 3.0 branch.
The Actor Status System started life as a system to determine how to breathe/suffocate in space
The Room System (a necessary precursor) defines a room's volume, its atmospheric composition and how air travels between rooms
All doors, airlocks and elevators had to be refactored to work with the Room System
The Stamina Component defines default stamina, default stamina regeneration and optimal regeneration requirements
The Stamina Component queries the Room System on every breathe and determines regeneration based on atmospheric composition
The player's helmet is considered a room: it has a purifier and is connected to the suit's air tanks
Without a helmet you breathe whatever atmosphere is available or suffocate
Movement and actions consume stamina and the rate is affected by stance, equipment, weight and slope
Think tactically: sprinting into combat means poor aiming, bad recoil and an inability to run away
Player's status is shown using various post effects, like brightness, that had to be made to stack nicely
The Buff System/Actor Buff Component allows virtually anything to modify the player’s status using a simple interface
Actor Status System = buffs + stamina + health + breathing + g-force
Many tricks used to keep the player aware of their status: VFX on screen, additive animations, UI work, and audio
The Audio Component controls the breathing audio and drives (and syncs with) animations
Three main sonic elements: breathing styles, grunts/vocalisations and SFX support
Two breathing suites (FPS and piloting) consisting of 13/14 breathing styles including AGSM
Breathing rates from 20 to 190 bpm were recorded
Procedural breathing animations were developed, driven by data from Maya (imported DataForge) to stay in sync with the audio
Animations are applied on top of the current aim pose so the player breathes correctly wherever they are looking
The new G-force solutions monitors accumulated velocities of an entity and each nested physics grids it may be in
The UI indicates the player's stamina as an ECG both on the mobiGlas and the visor
The mobiGlas also shows the atmospheric composition and pressure of the player's immediate surroundings
It may be possible to find/access better equipment in game that lets players know the atmosphere in adjoining rooms
The Actor Status System will continue to develop: poison, inebriation, sickness, disease, alien races, etc.
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.
Jeremiah Lee (JL): And I’m Jeremiah Lee.
SG: Nice to have you here today. On today’s episode we investigate the new stamina system gameplay and learn how various actions will be affecting your avatar ingame.
JL: But before we dive in let’s focus on the most important action happening around the offices: Alpha 3.0.
SG: That mean’s it’s time to check in with Eric Kieron Davis and the rest of the team for this week’s Burndown.
JL: [with jazz hands] Burndown!
SG: [with jazz hands] 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. Last week we ended at 94 total must fix issues which was prioritised as nine blockers, 62 criticals, 21 highs, two moderates, and no trivials. So let’s check in with the team to see how we’re progressing.
Matthew Webster (MW): So the main things about 3.0 at the moment. We’ve been drilling down more on the PTU/Evocati must fix issues. Todd and I, and Paul as well, got some more triaging still to do. We’re able to get through at least the criticals before we’re definitely signed off on going “Yeah these are the must fix issues.” But in the meantime I’m aiming to send out an email the team about the must fix issues we currently have. Those are the ones we want to start working on in order to push forward for Evocati. So focus on those.
The thing about game development is that with bug fixing, and particularly drilling down on the must fix issues that we now have, is that like most things in life you can have good days and you can have bad days of stuff.
Developers can have a really good day where they just pull at the thread of a bug - something they’ve been working on for a little while - and all of a sudden they have that eureka moment, they pull on it and then everything else unravels and it allows them to fix the next few bugs stacked up behind that.
On the flip side of things you can potentially have a really bad day where a feature’s got a little bit further, developers have put some more fixes in, given it to QA, over to testing. And QA goes in, starts testing and they can go “Well that doesn’t work. There’s an issue here. There’s one there. There’s one there.”
Or you can get a particular issue with a feature - or anything really - in that you can come up against one issue and then extrapolate that out and QA will just go down the rabbit hole essentially and go “Right well if this doesn’t work, well how about if we do it like this? And what happens if I do this? And what happens there, and there, and there?” And you can end up from that one … just initial find you can end up with another six or seven bugs.
Ben Parry (BP): We noticed there are these occasional black flashes - as you’ll see one there - in Grand Barter. So as we’re going around we’re … notice that just as you approach these lights they get more and more extreme. So what we’re seeing here is actually … it’s usually the lens flare that’s just spreading a problem out. But what’s usually happened is something has divided by zero or it’s taken the square root of a negative number or just something impossible. And so having one pixel wrong it then just smears it all over the screen.
So you turn it off and there’s just a little bit of it still visible. And going right up to it - I think the depth of field starts picking it up as well - but you can just see there are these tiny little … tiny little stipple effects. So we know that the fog uses this jittered … per pixel jittering so this kind of matches the pattern. So we think - if you turn off fog it goes away - it’s probably fog.
And what we realised was this is basically … when it’s doing the rectangular lights what it has do is it has to … at one point it takes the position that it’s sampling and it finds the nearest point on the light, near to it, and then it tries to get the direction to that. So it subtracts the two distances and divides by that distance. So if you’ve actually managed to sample it dead on the middle of the light, somewhere on the plane of the light, it ends up with a zero, divides by zero, it just screws everything.
So actually we just put in a very small fix. Yeah. So literally just checking to see if it is zero. If it is zero we just use a completely different vector that’s … it’s not exactly the right vector that it should use but it’s not visibly different. So yeah. Ta da! It works.
Robert Gaither (RG): Last few weeks we’ve been working on some shopkeepers and the admin office workers, sort of like a general purpose location or NPC we have whenever you need to deliver or pick up something from a location that has lots of sub like a station or a truck stop or something. This will be a general point where it’ll go there before it’s delivered out to where it’s supposed to be on the station.
And as you can see we have one of our NPC’s here who just got some new animations from Dave over there which should hopefully fix this stretching to talk issue, which has been cursing us from being able to test it properly or use it properly.
Max Hung (MH): For 3.0 we’re reworking the turrets for all the ships. Not only the ships but also you might have seen it in the rover as well. So with the turrets we’ve added the ability to … for the designers to define dead zones and and active zones to control how fast the turret turns back or forth. And then recently we’ve added a feature to have you get into a seat and have the turret rotate while it’s getting ready for you to shoot at enemies or other pilots.
Turrets are basically like a mini vehicle where they have seats in them and other seat components. And so our existing code can’t tell the difference between the turret seat and a ship seat and so it just chooses whatever it finds first. So we have to define “No, for this turret we want you to use the turret seat.” or “For the ship we just want you to use the turret.”
Tobias Johansson (TJ): We got this Jira ticket for a bug that you were randomly dying when visiting our outposts on one of our moons. It happened in all of them so we had to open up the editor - as you can see here - and find out what the issue was.
And if you look here you see that we have these blue boxes. I made them a bit higher than the outpost for this example but this is the atmosphere … well, this is the box that contains our Room System which contains atmosphere and actually air so that you can breathe within our locations. But as you can see there’s a gap between two of them, or between all of them, while it should look like this. Because when they’re not touching it means the air goes nowhere which makes it disappear in time. So you would randomly die at different times because you wouldn’t know when the air actually runs out.
And that was the bug report we got so we found out “Okay, they’re not connected. We need to fix this issue.”
Our first solution was just to make all the rooms bigger, to make sure they touched each other. As you can see in this example here. But we soon realised - or straight away realised - that also means you can breathe outside. You can technically stand on this window - even though it is outside - and you can still breathe and survive without a helmet, which also shouldn’t happen because you are on one of the moons that doesn’t have air you can breathe.
So what we had to do was use the Custom Shape tool, that Lumberyard provides, and actually make these shapes fit so they go out an extra bit where the door comes so the rooms still touch each other but they don’t reach outside, so you can actually not stand outside also being able to breathe.
EKD: At the time of filming this we’ve reduced our total must fix issues by eighteen. Which brings us to 76 issues stopping this first release. At the same time we’ve checked in a total of 773 new updates to the 3.0 branch. And now this week we’ve also made some more important decisions on what we’d like our first round of non-CIG testers to help us evaluate, as well as provide feedback on and keep polishing and fixing.
We’re really going through this release with a finetooth comb, making sure all of the new tech and feature work harmoniously together. So while we’re all passionately working knock out the mountain of blockers, as Matt said, uncovering one thread may unravel and reveal a whole myriad of issues that we always hope will knock out more than one big issue at a time.
But putting my personal dreams aside, as we’re completing and polishing features, those numbers are going to change and sometimes dramatically: sometimes higher, sometimes lower. So come back next week to see how we’re doing here on Burndown.
SG: For a more detailed look at what bugs we’ve been smashing be sure to check out our 3.0 Production Schedule Report which we update every week on our website.
JL: Now it’s time to talk stamina. The dev team has worked hard to build a robust stamina system that numerous factors into consideration to provide a more realistic experience.
SG: For example if you sprint into combat you’ll discover that your aim suffer due to the deep breathes being drawn by the character.
JL: Or worse that you don’t have the stamina needed to escape if the situation goes south. Creating a system that requires players to think strategically about their movements was one many goals this team had to tackle.
SG: To see what else had to be considered when designing this system let’s take a look at this week’s feature.
Dan Trufin (DT): The Actor Status System started life as a much smaller piece which we’re trying to figure out how to breathe in space - how to breathe also how to suffocate in space - how that works. The initial implementation was a pretty dodgy thing we did just so we could get to 2.0 out the door. We’re putting some kill triggers outside the airlocks just to make sure people don’t walk outside in their t-shirts. Obviously people managed to do that because of our wall collisions not being 100% there and people ended up floating in space in their t-shirts. Not such a good thing.
So eventually we started working heavily on this system but there were a lot of other things that had to come online before this system could actually be fully functional. The main thing that had to come online was our Room System. Our Room System defines the space of very room, what the atmospheric composition is in each of these rooms, and how air travels from one room to the other. The other problem we had to deal with was how do doors opening and closing react to this? Our doors initially did not support this feature. So we had to redo all our doors, all our airlocks, elevators, so that when a door opened it actually allows gasses to travel from one room and another.
Cristian Nechifor (CN): The Stamina Component defines a default stamina cost and default stamina regeneration as well as the requirements to maintain optimal stamina regeneration. On every breathe the stamina queries the Room System for the atmosphere composition and volume of the current room, then replaces a fraction of the oxygen with carbon dioxide and updates the stamina regeneration based on the amount of oxygen replaced. If there’s no oxygen in the current room there’s no regeneration and the player has a limited amount of time before suffocating.
The Stamina Component in, we were able to implement a life support system for the player to survive in space by turning the player’s helmet itself into a room. So the player automatically enters this room when equipping the helmet and the Stamina System can maintain optimal regeneration because the room queries will always find a helmet. We also added a gas purifier that removes noxious gasses from the helmet, including carbon dioxide, and a gas tank that maintains the pressure in the helmet by feeding it oxygen.
DT: When it comes to having no helmet on or simply having a helmet that does not have a breathing system you will not be connected to your suit: you will breathe whatever is available in the room and that will have some consequences especially when get into places that either have low pressure, or not enough oxygen in the atmospheric composition in the room, or simply noxious or poisonous gasses in the room. So that will create interesting gameplay.
And we’re trying to make sure the player doesn’t always keep his helmet on. It should become fairly costly to keep a helmet on as this brings a lot of interesting gameplay possibilities to Star Citizen where you have to rush to suit locker, get your suit quickly on because your ship is getting depressurised and there’s no other way. You either get to that suit or you die.
CN: Now the main stamina consumer is the player’s movement. While the player is moving their stamina drains depending on stance, equipment, weight and movement slope. So walking up the stairs is more expensive than walking down the stairs.
DT: So basically every action the player does consumes stamina. If you’re sprinting, jumping, crouching, vaulting over obstacles: that will consume stamina. Even idling consumes stamina but just on a very low scale compared to the other actions.
We want to encourage the player to think tactically when they perform actions. We don’t want them just to constantly run, bunny hop everywhere. We’re trying to achieve a level of realism here. Basically people who will constantly abuse their actions and not think about what they are doing will get punished while people who are mindful of every little thing they do will get an advantage.
Consider yourselves sprinting into combat for, I don’t know, 30 seconds and when you get into combat you’re so out of breathe that you’re just cannon fodder for everyone else. You’re aiming will be really a bad. Your recoil will be unmanageable. You won’t even be able to get out of trouble because you don’t have enough stamina to sprint away from the mess you got yourself into. This way people who arrive fresh in combat will be way more effective that people who’ve just rushed there and, yeah, not achieved much.
Walking instead of sprinting will still consume some stamina but your regeneration, if nothing is wrong with your character - like chest wound or something like this - they will still regen more than when you walk. But you also have the option of completely stopping, and when you completely stop you get the maximum regen because your character is not doing anything. He’s still consuming stamina because he’s idling, because we want to start consuming oxygen out of your oxygen tank.
Basically if you just idle in … for two hours in space you might run out of oxygen but if sprint for ten minutes you might run out of oxygen. It’s the same because you start consuming way more.
CN: The player abilities are the secondary consumers of stamina. An ability consists of a type, a stamina requirement, a stamina cost and two checkpoints in the game code saying, “Okay this is ability starts and this is where it ends.” You can only access this part of the code if your stamina is higher than the requirement for it.
The cost can also be processed in different ways. There is instant cost like for jumping or vaulting. There’s lasting cost like for sprinting and holding breathe. And there’s also conditional cost which is instant cost that depends on what other abilities are running at the time.
And all that was good until added equipment weight into the mix. Jumping with heavy armour and a railgun on your back on Jupiter is a lot more expensive than jumping with light armour on the moon. So this meant all abilities suddenly had variable cost. So the designers couldn’t reliably adjust the ability cost to ensure the player experience. We fixed that by taking the remaining stamina into account instead of current stamina. So instead of saying “you need 20% stamina to be able to jump” we say “jumping is not allowed to drain your stamina below 10%”.
To show the player’s status we’re using different combinations of post effects. The problem is when several status conditions are used in the same post effect, like for example when breathing at low health and low stamina and all these conditions modify the brightness. So we needed each effect to be noticeable enough on its own but also not go crazy when stacking with each other. So we implemented a centralised component that runs with customisable rules. With the new implementation we can say, for example, all contrast modifiers after the first one have their strength reduced by 50% and together they can never exceed a certain value.
The Buff System has been in the game for a while but we never really had a reason to use it extensively. Buffs are pieces of data that contain an assist of a type, a value, and sometimes a time limit. Their purpose is to allow virtually anything in the game to modify the player’s status using a simple interface.
The Actor Buff Component receives all the buff requests and automatically stacks the buffs of the same type together and broadcasts the value over the network. Bleeding is implemented as a debuff in the game right now. When a body part takes damage it applies a stack of bleeding with a value of one. That means the player will take one damage per second from bleeding. Taking damage on another body part applies another stack of bleeding so the player will now bleed for two health every second. Healing one of these body parts will remove the corresponding buff.
The buff component together with the stamina, health, breathing abilities and g-force components make up what we call the Actor Status System. We use it to change the gameplay experience depending on what happens to the player. So, for example, in the new version 3.0 taking damage from the arm will affect the player’s combat abilities like recoil and weapons sway. Damaging the legs will affect navigation, reduce the movement speed and increase the stamina cost for jumping and sprinting. Damaging the torso will decrease your stamina pool and regeneration. Running out of stamina or pulling too many G’s will make the player pass out and so on.
DT: One of the important things for us was that the player understands what is happening to them. Just having stamina there is not enough: the player constantly needs to be aware by looking at the screen what condition the character is in. We had to employ a lot of smaller tricks in getting the player to figure out, “Oh I’m running out of breathe. I should stop a bit: catch my breath.” or “Oh, my oxygen tank is out.”
So we had to go add a lot of visual effects on the screen when you’re running out of breath. We had to add a lot of audio breathing. We had a lot of animation additives happen to the player. We had to affect the player’s aiming moving up and down with every breath. It’s also a lot of UI work that had to into this to tell the player what’s going on every step of the way.
On your visor you get information about what’s in your suit. What your condition. How much stamina do you have. What’s in your suit. What’s in your tank. What’s in your suit. What your stamina is. But if you want informations about the outside then it’s the mobiGlas right now that gives you all the information about the room that you are in.
Philip Peers-Smallwood (PPS): My role, based on the Actor Status System was to outline the sound design elements of it. Speaking with Design and Code, Animation, and basically coming up with a sound design system that would be able to play a breathing sound effects in relation to what the Actor Status System was doing.
I worked closely with Ewan Brown, who’s one of our audio programmers, and together we start to build this system to be able to give audio feedback to what the Actor Status System is doing so the player hears what the player character is doing.
The Audio Component drives the animation for the character - for the breathing. That is going to sync, so the audio will sync with the actual animation of the character breathing and also on the mobiGlas you’ve got the heart rate monitor and we will be syncing with that as well. So heart rate, breathing rate will be in sync: it’s all driven from the same system.
First step for me was do a bit of research to find out what breathing styles we’re going to need and their relative speed and characteristics. So I thought best thing to do was to record myself, rather than getting some talent in, because I didn’t know if it was going to work.
And what I did first of all is set up a tempo map. I decided to go along and just record myself at different beats per minute (bpm). So we started at 20 beats per minute and then every couple of bars I increased the speed by five bpm. So it ranged from 20 bpm up to 190 bpm. So in actual time we went from three second inhale and three second exhale up to point three of second inhale and point three of a second exhale. Which is really, really fast. So I had a lot of fun recording that.
The benefit of recording to the tempo map is you got a lot of variation and you got a lot of assets down very quick. However the downside was I didn’t realise how breathing rapidly, without needing to, how much that can mess you up. I did nearly pass out a couple of times at the upper end of the bpm scale. Fortunately I didn’t.
Once I’d got enough material what I did is I edited it all together. So I split all the inhales and all the exhales for the specific bpm and then bounced them all out of REAPER so I had individual inhale assets and exhale assets.
The Actor Status System sonically consists of three main elements. So you’ve got the breathing styles, which are the different types of breathing. Then we’ve got the grunts and vocalisations. And then we’ve also got the SFX support, so that’s sound effects relating to your suit like alarms and like UI elements and stuff like that.
Currently we have thirteen breathing styles. That will most likely increase. That’s currently split across two suites. So we’ve got a breathing suite for FPS (so we’re just running around) and we also have a breathing suite for piloting because in those two different situations you will be using different styles of breathing.
So in FPS you’ll be normal breathing, recovery breathing, when you’re fatigued, taking damage and injury. But then when you’re piloting we use specific breathing styles for that situation. One of them's call AGSM which is Anti-G-force Straining Maneuver - also known as the Hick Technique - and it’s a technique pilots use to stop passing out over high G’s. You force … they force their blood pressure to remain high in their head and stuff like that. So when you’re pulling really high G’s you’ll start hear him go “HICK!” I watched loads of reference material on the stresses and strains that these pilots put themselves through is insane.
So the game actually calls discrete inhale and exhale triggers. Which is great. The level of fidelity that we’ve got is brilliant. So the Actor Status System and the Audio Component in tandem pass particular values in relation to stamina, O2, health - even the composition of the oxygen … atmosphere in the room. That feeds into our Audio Component which I’ll control through via DataForge. There’s a DataForge record that I can control the breathing suite, the breathing styles, and all the conditional transitions. And through that I can dictate which breathing style is played at a certain time and how that breathing style correlates to the values that are being passed from the Actor Status System.
So the actual audio exists in Wwise which is our audio middleware tool. With it … is currently thirteen different styles of breathing that all live in their own discrete actor-mixer hierarchy. Within in that actor-mixer there’s a blend container which contains inhales and there’s a blend container that includes exhales. So they can be triggered independently, one after the other. And within that they each have a range of random containers ranging from the 20 bpm all the way up to 190 bpm. And then the blend containers actually respond to an RTPC, which is a real time parameter control, which takes the values from the Actor Status System and the Audio Component and that select which of the bpm breaths it should play. Then the game calls the play trigger which is like “play breath inhale” or “play breath recovery exhale”. It triggers it from Wwise and that’s what you hear in the game.
The animation for the breathing is driven off the DataForge record. And you can control the curves of the breathing which can influence the curves of the animation. And for Audio it represented a unique challenge for us because normally we’re at the end of the stream - we’re down the stream process normally everything gets done, we add audio to it - this is the first time I’ve ever worked on system where audio drives another feature. So Audio is actually driving Animation so we have to make sure we sync with Animation very closely because normally our footprint is post - it’s never normally directly impacts the input of another department.
Have to have it sync. You can’t have a breathing … breathing going in and out and the animation going out and in.
Gordon McLean (GM): I was involved with the breathing animations - the procedural breathing animations - so making the player arms and chest move up and down as he breathes. And mostly focusing on getting it in sync with the audio. And getting the feedback there for the player once they’re tired or exhausted.
So the system itself is fairly complex on the back end there’s a lot of variables involved and a lot of different states and levels to it. But from the player’s point of view we try and keep it as simple as and easy to read as possible. Because obviously it’s all about player feedback, it’s all about them being able to see “Oh, I’m tired. Oh, I’m exhausted. I need to slow down a bit. I need to stop exerting myself.” and communicating that to them simply and easily while also having the complexity at the backend system and having these more advanced systems behind it.
It doesn’t slow you down but it will tell you that you’re more tired. You won’t be … if you are running along you won’t run slower but you’ll run heavier. The audio will get more intense, you’ll breathe heavier, your arms will move more, it will have more of an effect. If you trying to aim at someone exhausted your aim’s going to be all over the place.
Obviously this is quite a … it’s fairly subtle at the normal stamina levels. You won’t really notice it - that’s the whole point of the breathing system: if you’re doing things normally you don’t notice you’re breathing. It’s only when you’re properly exhausted - you’ve really been exerting yourself - you will know about it. You’ll know: you’re panting, your arms are moving about, your chest is heaving, and you’ll be exhausted.
From the breathing animation point of view, the primary feedback for the breathing is the audio. That’s the thing ... normally in games that you hear yourself breathing that’s how know you’re tired. The main thing was getting the animations to match up with the audio. We can’t use just a baked animation because the breath lengths are different. You breathe deeper or shallower. You take long breaths, you take deep breaths. You take short breaths. So we couldn’t … we thought about maybe having animations captured and then blending between them and lengthening them or shortening them.
But then we had to go procedural. And the way we did it was we’ve got curve data and it comes directly from Maya - directly from the animators tool - we pull that into DataForge via script - and it was written by Rob Howes down in Derby - and then that data’s then read by the game and it can be played back. We can adjust the speed of it at runtime so basically it is … the audio tells us “this is the length of your next breath”, we go “that’s how long the animation has to last”.
It also ties into the Aim Pose System. So in Lumberyard you’ve got an aim pose over the top of the player which determines where he’s aiming. So that plays on … it’s about the last layer it plays on the animation. And it points the gun where he’s looking, it adjust him: if he looking straight up it points the gun straight up, if it’s looking down he looks straight down. And obviously it’s adjusted for different weapons. You’ve got different pivot points and such.
Using the procedural animation we can put it over the top of the aim pose so if you’re looking up you’ll breathe correctly. It’ll be the right direction. And it works smoothly and it works non-obtrusively.
DT: As we started only with a breathing system we really thought our job was mostly done but eventually … we were asked whether we can add the G-force System to go through the same process because it’s basically just forces acting on the player and causing various good or bad conditions on the player.
CN: So the current G-force simulation - the one in the live version right now - is very accurate, is very realistic. It goes as far as simulating how the human naturally adapts under the effects of G-forces. However moving forward we need a more generic simulation that works with any type of entity in any context: not only human players piloting a ship. And we need it simple enough to run on all entities at all times. For example we need unsecured cargo to fall over when the ship accelerates.
Our new solution monitors accumulated velocity of the entity and all the physics grids they are inside of. So we take the linear and angular velocity of the entity, transform them into the parent’s space and add the parent’s velocities, and transform them into the parent’s space, and so on until there’s no parent. Then we can track any change in the accumulated velocity. Any change in velocity means acceleration and acceleration means G-force.
DT: This became the birth of the Actor Status System which is a larger unifying system. Brings together every little thing that can happen to the actor: to the player or to other characters. So we wanted that all the effects that appear on the screen - all the things that happen to him - go through the same filter as we don’t want them to conflict with each other. If we would have made separate system for every little thing that can happen to the player, let’s say he’s hungry or he’s thirsty or he’s affected by G-forces or he’s out of breath, each of those would have conflicted with the other and that would have been a nightmare for all of us. So that’s why we had to unify and this became the Actor Status System.
Ewan Brown (EB): It seemed to take off and every single idea from how the player reacts to G-force and exhaustion and do abilities like jumping and jumping over ledges are all affected by this. So we’ve got grunts and the other sounds in his dialogue all need to interact with breathing so it’s become rather complicated.
So I’ve set up a system in the code to link quite a few different systems. The lungs of the player are how he’s animate and how that affects the wobble of the gun need to be driven by the breathing. And that needs to be in sync with the audio that we’ve provided.
The challenges we had were … we’d start off with something simple and it would work fine for one scenario. So we’d basically just try sprinting and when you stopped sprinting it quickly became apparent that it didn’t sound very realistic. So we just quickly just start breathing at a normal speed and we would expect him to sound exhausted for a lot longer. So to fine tune all of that - how long it takes to recover and how he sounds when he’s recovering - lead onto new styles of breathing. So that one was the recovery style of breathing. When you’re exhausted you take deeper, longer breaths until you’ve recovered.
I set up a system using our usual user interface for the dev team, DataForge. And we started off with - basically it just looks like a table of number and parameters for the different ranges of breathing speeds and lung volumes that would need to be taken in to give the player the amount of oxygen back into his system to make him recover his stamina which is the ultimate goal of the breathing. Given the amount of oxygen in the atmosphere or the room we calculate how much stamina he can regenerate.
So for each breathing style we tend to have bezier curve to make it possible to fine tune amount of stamina that he’s got or needs translates into how fast he needs to breathe or how deep he needs to breathe. Quickly from there we realised we had some many different styles of breathing, like when you’re injured or recovering from exhaustion or piloting a ship and experiencing high G-force. The transitions between these became so complicated to manage we couldn’t do a straight interpolation between each one.
I set up a new thing which we term a “breathing suite”. That was a FlowGraph set up to join them all together with different transition nodes. And the transition node itself has a flexible number of conditions that would make it follow the different parts of the the FlowGraph to a different style. So we’ve expanded that with so many parameters - like checking the health or stamina or the G-force or whether you’re blacking out - and we can get it to react in so many ways that make it sound realistic that I think we’ve got more than fourteen different styles and it really gives the player a feeling that something realistic is happening.
Zane Bien (ZB): So the Actor Status System in general tracks a whole lot of variables. Things like exertion, we have stamina of course and that all ties into the Room System which has oxygen. But a room may not have just oxygen: it has other things. It might not have a full pressurised atmosphere. So it’s important for the UI to communicate state of your surrounding are: what kind of oxygen is present, and your current atmosphere.
So if you go into an airlock and you depressurise then your oxygen tank won’t be fill any more. Or if you’re on a planet with low oxygen or there’s a low atmospheric pressure then you know your oxygen tank probably wouldn’t refill as quickly as it would in a regular atmosphere.
One of the big things that we track in the UI is, basically, an ECG graph which is an indication of your stamina. So if you run up a flight of stairs or you sprint for a long time then you obviously see your heart rate going up, your ECG graph getting a bit more intense. So then that lets you know that you’re exerting a lot of energy, you’re maybe take a rest if it’s getting to high. So it’s very … it’s cool because it’s not an exact value that you’re seeing: it’s a bit more indirect. Which is kind of cool and it’s a nice visual in terms of the UI as well.
This displays on your mobiGlas and we’re also going to be displaying it on the visor as well. So I mean obviously kind of a very important piece of information that you’ll pretty much want to have, most of the time, and be available to you at all time so we have it on the HUD. But there’s additional information in the mobiGlas that we have.
I was the … another good thing to know about the Actor Status System is what is the state of your surroundings, in your immediate atmosphere, because you can go in and out of rooms. Different planets might have different atmospheres, different atmospheric pressures, different atmospheric compositions and that all affects how quickly your gas tank would refill. Let’s say if you’re running low on oxygen or something and you want to refill it, or whether or not it’s safe to take off your helmet or not, you can pull up your mobiGlas to see - like in that movie The Martian where he’s checking his status.
DT: For planning ahead this will be only dependant upon the tools the players have. We want to give them the most basic tool, which is the mobiGlas, to just check what is available in their room right now. But they might have access to some better equipment which will give them … they can scan two, three rooms ahead or look at a door and go “What’s on the other side?” That will help them choose whether they open door, whether they don’t.
Also on the doors the refactoring of the doors, we have indicators now that … what the conditions are on the other side. You’ll always get a warning: there’ll be a red light if something is wrong on the other side. You’ll not be able to … you will be able to but it’s your … it’s your problem if you just want to open a door to outer space. But the game gives you the information: it’s up to you to … whether you use it or not and you’ll suffer the consequences if you don’t.
Work on the Actor Status System will not stop here. This will be a long, ongoing process of adding multiple things to the conditions that can affect the. We’re talking here from small little things - of getting poisoned from whatever’s in the room to getting drunk, needing to go to the toilet - all the little things that can affect the player temporarily. And then we can expand this to go even to stuff like long term diseases and all kinds of depressurisation sickness, radiation sickness, and all these things that won’t be something that the player can get rid of instantly: they will have to go find a medical specialist in the game that can treat those things and that treatment might take a while. We’ll have to see how we implement that but the possibilities are pretty, pretty large here.
The ultimate goal for the Actor Status System is to have it support multiple races as they get introduced into Star Citizen and players will have to be aware that certain races breathe a different atmospheric composition. When they enter their ships and their territory they need to be aware they can no just remove their helmet. And if they have to deal with this races - as in transport them across the universe - they have to cater for those races needs. They can’t just shove them in a place full of oxygen, they might not like that: they might simply suffocate or they might have adverse conditions to certain chemical elements that humans just love.
It needs to feel real. It needs to … you need to be aware of every little thing that’s happening in the world. You need to be aware of … this room might be completely depressurised. That’s why we give the player tools. They have the mobiGlas app that they can use to check “Oh this has 0.1 poisonous gas. This does not have enough pressure. This oxygen is too much here rather than just too little.” And you might have a hyperoxia problem if you breathe that for a lot of time. So it’s … players need to be aware. We give them the tools to be aware of the environment but they need to check and make the tactical decisions and good choices whether that allows them to survive or not.
JL: As you saw stamina is but one component in the Actor Status System. Combining stamina with these other factors, like health and G-forces, makes your avatar feel more like a real person; not just a game character.
SG: Yeah, this new system also creates a lot of interesting new gameplay scenarios. Players must consider how the armour they’re wearing, or room’s atmosphere condition might affect their stamina. Decisions like that will help make the game feel more immersive.
JL: Well that’s all for today’s episode. Thanks to our subscribers because of you that we can produce all our shows and provide constant updates for the community. September subscriber flair will be released on Friday so be sure to keep an eye out for it.
SG: Very cool. And finally a big thanks to all of our backers for their support.
JL: Until next week we’ll …
Both: … see you, around the ‘verse!