As is with any information on our transcripts and summaries, everything posted is subject to change by CIG and in some cases may not always be 100% accurate at the time. While we strive for accuracy, mistakes do happen so please let us know if you find something amiss that we didn’t catch. Enjoy the show!
Chris Roberts (CR): Hello. Welcome to episode seven of Around the ‘Verse, our weekly update behind the scenes of Star Citizen. I’m Chris Roberts
Sandi Gardiner (SG): And I’m Sandi Gardiner. We are another week closer to CitizenCon.
CR: Yes, yes we are. Pressures on.
SG: Pressures on.
CR: So on today’s episode, we’ve got the Austin office for an update on Star Citizen’s first data runner
SG: We’ll also check in with the U.K. Audio Team to showcase the Music Logic System we’re building.
CR: Yup, pretty excited by that one, but first we're going to go out to John Erskine to explain what else they’ve been working on in Austin.
John Erskine (JE): We have our Senior Audio Designer Jason Cobb - he’s going to show detailed look at some of the sounds that he’s been crafting that were actually requested by many of our players.
Jason Cobb (JC): So I’ve been working on the sound of debris that you fly through if you are behind a ship that explodes in the game. During dogfighting we’ve had a lot of really great explosions - visually and sonically - but we’re lacking any sort of feedback for flying through the debris cloud that remains and so I’ve been working on sounds for that aspect and to do that it’s really not feasible to have a physical particle for every bit of debris that is generated. So what I do is I take all of the output I generate one-by-one and drop them into a digital audio workstation where I can set up an effects chain of a reverb for the front and a reverb for the back - I’m using Altiverb in this case. Model of a Sikorsky.
So when we play the output of all these generated files.. [plays sound] …they are very dry but then when I enable the… [effect plays] …effects, they start to take on some character of impacting of a hull and if I can adjust some of the equalities of that, we’ve got the front and the back here. You can sort of start to place these impacts into more of a space and so I would take all of this output and render it through an effect and that can be one ship and then maybe we need a slightly larger sounding ship well, we’ll have to render it through another effect. There’s a chance we might be able to do the effects part in real time but for right now in the prototyping we’re just hard baking the assets with reverb in them.
And so now, into gameplay - let’s check this out. I’m going to solo just the explosion and the debris cloud so that we don’t have to listen against the other- the ship noise mainly. Just to isolate for this test.
It seems like maybe the debris cloud’s lasting a little bit longer than it should but it’s hard to tell. You want to hear something as you get around it but you don’t want it to last too long, although that’s not so a big a deal. So you can see that the random position of the particles and the random mist of the prebaked sounds kind of works usually - there’s a few times where you’ll see a large chunk go past your screen and you’ll hear a sound and you you’re like “oh my god, that was perfect!” But there's other times when you’ll go by and not hear a sound and be like “well, OK” - maybe it didn’t hit me.
So now I’m basically sitting still, this really doesn’t happen in gameplay much so it’s not really a valid test - I suppose it’s possible you could be still next to an explosion just by happenstance so we need it to work in all cases. Now you can also tell that the debris clouds are maybe a little bit loud compared to the explosion so the mixing and the fine tuning is stuff that we’ll definitely do and I can do a demonstration of that right now.
I think that when you are in the explosion and then fly away, it lasts a little bit long, but sort of like this. This is a level of decoration, of polish that it really adds to immersion in that prior we had these great explosions and you see it happen and if you fly through it, you’re really not hearing much, you’re just sort of like “there was the explosion but where is the rest of it - I see all of this noise, this scattered noise, but I’m not really hearing it, I don’t really feel it’s affecting the ship it all.” So this is just one of those tiny little details that a surprising amount of work goes into it but it just adds one other little complete fleshing out of the experience of dogfighting so that you a lot more visceral reaction to the “yes, there used to be a ship there but now it’s a bunch of tiny bits and I just ran through them all” - it’s something that we didn’t have before and when we put it in hopefully it’ll help people have a little more joy out of the kill they just did.
JE: Thanks Jason, that’s really great - it’s amazing the level of detail that goes into making these sounds - things people might not normally think about, that’s the things that really make Star Citizen great, is that level of detail and attention to detail that really sets it apart. Next up, we have a report from the DevOps team. We’re going to talk about the various things we’re working on and show a little bit about what happens behind the scenes to make Star Citizen run.
Mike Jones (MJ): Well the DevOps team is made up of three main functions here as we’re configured in Austin. We have a Build Ops section of our team; LiveOps and Publishing - and all of this makes what we call DevOps. They are small groups and we bundle it all into the same overall term of DevOps. So, the Build Ops team is basically managing and configuring the systems that we use to put all the builds together that are used in the company and those are the builds that once they’ve passed QA will also make it out to the PTU and also make it to a live service.
So that’s a little bit of an overview of the Build Ops. The Live Ops team does a lot of tools and automation systems that we use in our Live Publishing operations. These are things that would automate the build out of the services that we use on the PTU or the Live. They are also building the tools that we use for internal development, this could be how we interact with our source code.
This could be how we deliver builds internally throughout the company to the QA testers and the engineers - pretty much everyone, and then we also have the Publishing Team which does the actual publishing of the game. This is the fun part where we take what’s been approved by QA and our leads throughout the company and we can- this team will publish that throughout the process through PTU and eventually to the live service.
This includes everything from taking the build in it’s raw state, bundling it up, sending it out to the servers and then managing the whole patch production process.
Logan Nelson (LN): So I feel like DevOps is kind of like Scotty, to make a Star Trek reference, you’ve got all these different crew on the ship that all have their own different jobs and things like that - you obviously need a medic to make sure that the crew members are healthy; you need the captain to drive the ship - Chris Roberts is kind of the captain - you’ve got all these different roles but if the ship doesn’t run, if it doesn’t move and the warp core is broken then it doesn’t go anywhere and so I view us as the guys that are banging in the engine room hoping to make sure the ship still runs. It’s a very critical part of the mission.
MJ: So what’s happening in the current patching system is the data that goes in that’s changed is compressed into these large PAK files that are then bundled up and put into the patch. Well the problem with that is even if there is only three files that changed in a 2 gig file size once they are recompressed, the patcher sees this as one giant two gig file and you make these changes across a large number of files, you wind up with a 20 gig patch. So what we’re doing is we’re breaking all this apart so that now we can- at the patcher can actually look at only files that have changed, not the big bundles of change. This way we’re hoping that we can deliver- we’re really hoping for 10% of overall payload that we’re delivering now, so that would be a 90% reduction in patch size.
I think a lot of people are going to be happy about this. I think it’s going to get a lot more people into the PTU because they can get in faster, it’s going to help a lot of people out on the edges in the extreme areas that have maybe low bandwidth or a data cap. It’s something that’s really difficult for us because this actually goes down the core of how the game engine actually loads files off the disk - so we’re making changes to the engine itself with the help of our team in Germany because who of course, that’s what they do. This will allow us to be able to make use of this new patching process and I’m expecting this- this is going to be a big deal for the game, for all the players and it’s really going to help us on delivery times with all these publishes.
Andy Anderson (AA): All the tools we would use to deploy things, manage configuration for them - they are interesting at the time, there has been a whole lot of work, a whole lot of development. But the new tools that we’re rolling out really make it easy for us to change things very quickly - and when I say quickly, I mean, sometimes it’ll be waiting on these tools for even minutes just to change a line in some server somewhere - now it really feels like we can just issue commands, the whole deployment and they all obey - it’s really great.
MJ: I think that a lot of what we do, it’s so behind the scenes, most people never get a chance to see all the little nuts and bolts of how all this works - what does it take to set up a server, what does it take to run 50, 100, 150 servers and keep them all running and keep them all talking and keep the network security up - these are the type of things that we do and it’s really fulfilling work because without this backend infrastructure that we’re building and the automation to keep it going fast - I don’t think we would be able to move as fast as Chris wants us to move and as fast as the game development is moving - and that’s a rewarding experience.
JE: Thanks guys, that was great. This patch size reduction is really going to make a big difference for all of our players and especially all of our developers who actually have to patch the game multiple times a day - it’s going to make a big difference. Now, it’s back to you, Chris and Sandi!
CR: Thanks John. DevOps and LiveOps are definitely some of the unsung heroes that make Star Citizen go - so thank you guys for your hard work. So when we last saw the Drake Herald on Ship Shape back in May, it was entering the modelling phase - it’s come a long way since then, it’s heading into it’s final art pass. We’ve actually been doing a lot of Drake ships recently for some reason - I’m not sure why.
SG: Yeah, and the Herald has been an interesting one to watch - it has definitely has been one of our more divisive ships.
CR: Yeah, maybe. We sat down with Josh and the rest of the team to see what makes this courier run.
Matthew Sherman (MS): With 2.6 we’re excited to release the Drake Herald and it’s our first “info runner” ship. What that really is going to mean is you’re going to have these big data banks on the outside of the ship. They’re going to have a lot of volume to store intel assets. This’ll be stuff … locations of where research data might be found, mining sites, salvage locations, a ship black box. Any of the intangible you can think of is what we’re looking at with intel and what an info runner is going to be carrying around.
Josh Coons (JC): So one thing when flying around in the Herald that players are going to notice is that the ship is really, really fast. It has, I think, the biggest engines per mass on a ship so far. So if anybody knows what a “funny car” is or a dragster, it’s very dragster. I would assume you’re going to see a lot these in races. Like I said they’re hard to catch. Super fast.
We’ve got it loaded as well. The players can expect lots and lots of counter measures.
So with all the ships - pretty much any asset - this ship - when I read the specs, the design, the intent of the ship I usually break out a few keywords and those will be my motif for the ship. For this ship I used “speed”, “science”, “tech”, “evasion”. Also the motif of Drake had to be integrated in when designing the ship. Which is bare bones, it’s wires exposed, it’s trellis work, it’s … It’s not as fancy as some of your other branded ships.
MS: Some of the redesign was in part to make sure that we could get everything built to the metric standards that we need for how big guns are, how big components are, how much space a player actually needs to walk in and through the ship. One thing that always looks great in a lot of sci-fi movies are these nice creepy, cramped corridors but unfortunately with a lot of game logic it’s like “Well now we’ve got to make a little bit more space so your average standing guy can get through and move around stuff.”
So you can definitely see that with the interior of the Herald where just the comm station in the back: the seat for that is going to slide you in and out as you’re using the station to optimise the space as much as possible. But then also some of that back wall area was restructured a bit to open up enough room to make sure that even if that seat’s extended and someone is getting out of it another player or an NPC can walk behind that seat cleanly without having to clip into the walls or bounce all over the place.
Patrick Salerno (PS): When we start the design process for the Vehicle Destruction System. We come in and I will talk with Art and Design. And we will work out in 2D and 3D how to tear apart the ship.
So to start that I would say, for example, I would look under the model. Now damage comes in in layers, right? There’s a bunch of different features that work together. There is the exterior hull of the ship. Underneath the exterior hull of the ship there is an underlying damage skin and “gubbins”. Now the reason we have this is because now we’ve added a damage shader that you’ve probably seen that creates a sort of warping metal effect and you can punch through and you can see through the ship. That consists of the outer shell, the underlying gubbins, and the actual geometry. Now all of these have to blend together at the end of the day so part of my process is to check for all the different parts of geometry.
I want to check for what are called “UVs”. UVs are what the texture’s placed on that creates the actual visual of the asset. And then we also have another layer called “UV2s” and these are what the damage shader actually works on. We can see that in the Editor here in the top left corner. These would be the UV2s. This is what the Damage Map shader is actually applied to. So when I shoot the ship there will be ripples and distortions and metal bending.
In conjunction with that I also have to create little explosive charges around the ship.
Now most of my work is preliminary. Basically I take the model and I set it up for destruction. I’ll break off the pieces, I’ll make sure all the checks and balances are there, and I will prep the work for other people. So for example the particle guys: I would come up with them next and I would set up these things called “helpers”. And helpers are little green cubes. They have a direction - they point x, y and z - and they are basically an explosive charge. Now what I did here is I set up a little group of them and this group of them is just a bunch of different effects that generalised and used on different ships. Explosions, sparks, fire, etc., etc. So when a piece takes 100% damage, it pops off, the explosion activates and creates more shader damage.
So its layers. You’re peppering the ship with your own guns. You’re coming in. Parts are exploding off. It’s all melting and at the end of the day you should have a pretty broken looking ship. So we’ll come in, I’ll start hiding pieces. So I’ll come over here …
We’ve gone into Max and done initial ship set up. We’ve checked that the mesh has UV2s. We’ve checked that the mesh has underlying geometry for the shader to show underneath when bullet holes are taken into effect. The shader’s pretty cool with the damage system in that the shader actually lets you poke holes in the meshes with what are called “vertex colours”. So when I go into Max I go onto the mesh and I start setting areas where there’s translucency, transparency, etc., etc. for damage to shoot through. Not every area does need to be shot through though. You need to make sure that you’re not wasting extra geometry, costing performance, adding internal structure to places that don't’ need it.
But you also want to make sure that every piece blows off, has a neat effect, looks pretty cool when it’s flying off. So on, so forth. Now as you see some pieces are floating away, some pieces are just sitting around. Those are called “vectors” and those are little force pushes that are set in the XML. That tells the piece how hard it should fly off the ship and in what direction.
As I come in, I just keep going around the ship looking for areas that are not working correctly. So this area, for example, is working correctly. We see we are getting bullet holes. The procedural system is working. UV2s are working. So on and so forth. But an area I know it doesn't really work is up here. If we take a look we see we’re kind of getting a bullet hole but nothing really going on there. Well that means I have to go back into Max and figure out why. Maybe reproject the UV2s. So on and so forth.
Like I was saying testing different weapon types. Seeing how they affect the damage system. Testing different lighting conditions. Making sure all the pieces blow off. All that fun stuff.
But pretty much, in closing that’s how we put together some of the damage. It’s a mix between 3D Studio Max, XML and the CryEngine. It’s a very iterative process: going back and forth until it’s refined and then you hand it over to the professionals at the end and they tweak the graphic … the VFXs, they tweak the explosions, health, damage and lighting.
So that’s it, hope you enjoyed it.
CR: There you go. I’m pretty excited about the potential of more non-combat focused specialty ships in Star Citizen. Especially as we move towards 3.0 and the full persistent universe.
SG: And it’s faster than an M50 in a straight line.
CR: That’s what I hear …
SG: That’s what I’m happy about!
CR: … that’s what I heard. In cruise mode!
SG: While it’s been another week of development it’s been another week of amazing fan content.
CR: Yep. So let’s go to Tyler Witkin to present this week’s Community Update.
Tyler Witkin (TW): Hey everyone, Tyler Witkin, Community Manager in the Austin, Texas studio here to bring you this week’s Community Update.
Last week the origin M50 won the title of Galactic Tourist Fan Favourite Flyer, landing in a spot in our pledge store for one week. Just a reminder that there’s only 24 hours left on that sale. The battle continues this week this time between the Super Hornet and the Vanguard Warden, look out for those results on the website tomorrow.
Tomorrow also brings a whole new issue of Jump Point for subscribers, this time taking a look at the Anvil Terrapin, definitely worth checking out.
Also last Saturday we had a blast at the Austin Bar Citizen and just as a reminder there’s another Bar Citizen this Saturday, this time in Orlando, Florida. Find all the details at Tinyurl.com/floridabarcitizen
This week’s RSI newsletter coming out tomorrow features an extra special sneak peek from Ivo Herzeg in our Frankfurt studio showcasing some of the work done behind head stabilisation and FPS which you can watch in 60 frames per second, so make sure to catch that in the newsletter tomorrow.
Lastly it’s time for this week’s MVP award. A huge congratulations goes to J. Coren for his detailed efforts in creating a travel guide for CitizenCon. This was actually brought to our attention from our events manager and I can see why.
So I highly encourage anybody who’s traveling to CitizenCon this year, check out the guide. Congratulations again J. Coren, you’re this week’s MVP. Thanks again everyone for all your support and we’ll see you in the ‘Verse.
SG: A few weeks ago we profiled some of the dynamic sound effects as we walked through our crashed ship demo.
CR: Yup so now we’re going to shift our focus to music. Ross Tregenza, Senior Sound Designer at Wilmslow is going to give us an inside look at the new Music Logic System which I’m pretty excited by.
Ross Tregenza(RT): Hey, I’m Ross.
Sam Hall(SH): Hello there, I’m Sam. I’m going to describe how the interactive music system works in Star Citizen. So from a code side, we’ve got a system that will basically driven off music events. The way it works is, Ross can decide what happens when the music events occur. So, if he wants the event when your ship gets hit by a bullet, if he wants that to be really significant then he can decide how that happens by using the data driven tools we have provided for him.
RT: Whatever you’re doing we’re making sure that the music system knows what you’re doing and is responding in a way that is appropriate and cool and cinematic. So, I’ll show you some examples.
*3 Ambient States*
So, a really nice example we’re working on right now is the ambient music. This is when there is not really any, you know, combat or anything going on, we’re just exploring spaces and stuff. At the moment, we’re hearing some FPS music so this is just… the engine knows we’re on foot, it’s playing sort of a slightly synthy, slightly tense underscore that’s very ambient and as you move into the ship… it will slowly transition to a more grand kind of exploration kind of feel to the music. And that’s based on the conditions we know, we know you’re in the ship now and we know the engines are starting.
We get out of the ship, if we’re in space now, we wanted to EVA directly into space, it would work there as well. We’re going to take a cool little jump off the platform here just cause it’s a great example. As you head towards the edge of the platform and for a big leap out into space, you’ll hear the music transition. There we go, now we got this really cool ethereal almost craft workesque ambient music, all of this by Pedro.
See all this is based on conditions, Sam Hall and I have been working on. We know we’re floating, we know we’re not in any immediate danger so we got this beautiful exploratory quite sort of sense of wonder music playing. As we come back down, we’ll land back on the platform, we know again, no danger at the moment, just FPS, no threats we go to FPS ambient music.
*Flight Combat Music*
So you can hear this system the most when you’re dogfighting. Here we have a few pirates coming in, immediately we’ll be getting some tension music, that’s based on the fact we have some unknown guys approaching. So the system’s told us two guys have just arrived, they seem to be a threat so that’s pushed up that tension parameter, now I’m starting to fire on them and they’re returning fire. We’ll start to really see the system ramp up now, the intensity number which is the real backbone of this system is going to start to go crazy as your shield is getting hit, you’re hitting the guys, these numbers are constantly being fed in. As that number rises, we move through way out of the ambient area into the lower action, medium action and eventually high action which is really crazy.
You see if you eventually manage to take out of these guys, you get a boost to the mood parameter which is coming from the Y axis, here we go. We also get a little sting there that plays whenever you kill one of the bad guys cause the engine has a chance to play a little victory sting, ta da. Here we’ve had a boost that’s pushed us into the hero state now so the music come and gone all heroic, we got big brass sections and that will swell back down again. All these parameters seem to decay back down to like a stasis. There we go, another guy taken out.
*Flight Combat with our debug system*
The code that Sam Hall… what he’s provided me with which is incredibly valuable is all this debug information. This tells me everything that is going on from… we have all the stings, that are momentary events that could happen this is things like ships passing by, as you might have heard you sometimes get a little trumpety sting that when a ship passes by to successfully hitting bad guys, your ship getting blown up, all manner of parameters, those are all momentaries.
Then we have the long term information, we have the ship’s intensity that’s the big number that’s our backbone. The mood, all manner of other parameters we use to feed into the system in any combination of ways. You can see we’re getting information in about events here so we have… we’ve hit the shields of the ship, so that’s good, that feeds into it. Yup, the player’s ship’s been hit in turn, this constant feeding of information that’s what I can rely on to work to tweak the numbers in the music logic system to make sure, you know, the system doesn’t go too crazy. Go up in high action too fast, things like that.
Never saw that ship destroyed, that gives a cool momentary sting. All of this although we’re seeing this in the flight mode at the moment, we’re working on it for 2.6 to make sure that these numbers translate into the FPS game mode and eventually also just in EVA combat as well. So no matter what you’re doing this stuff is always appropriate and the music will shift to suit the EVA or the FPS environment.
We have a theoretical example just to show you using some console commands here. We can simulate what it would be like when we have EVA combat working in conjunction with the music logic. So, I’ll throw in some numbers here and just like when we saw with the pirates attacking the ship when the music logic was going nuts, I’ll be simulating the player getting attacked or attacking the enemy and we’ll see that the EVA music, that gentle kind of craft workesque music, so that’s ramping up in this cool kind of coral way. All of this again, this is all Pedro’s beautiful music.
Just like with the flight combat music, we have heroic EVA music, we have grim EVA music, exactly the same set up but just with a whole different mood of music and a different set of music loops. The same thing here with FPS, this is something we’ll be seeing very soon, same system again but this time we’re getting hit by… it could be pirates attacking us and we’re on foot so the music is a bit more kind of personal, a bit more synthy and dark. You get that kind of grand space music for the space flight, we wanted to go a little more intense and synthetic feel for the FPS. So again you hear that music swelling and falling, this will be a constant background between all these systems and as you move through different parts of the galaxy the whole overall suite of music will move from one set to another but there will an understandable language across all of it you’ll get used to. This will be on it’s feet and working forever, it’s a system that is self managing and autonomous really and will just work which is awesome.
So, that’s music logic. It’s what Sam Hall and I have been building in DataForge, we’re really, really proud of how far it’s come. It’s going to be available in 2.6 and that’ll be just the beginning, it’s just going to get bigger and bigger and grander and grander. Hope you enjoyed it.
SG: Thanks very much Ross. That is super cool and is going to be an exciting addition to the game and I'm really looking forward to that.
CR: Yup. So that Music Logic System’s actually an evolution of the dynamic music system that I first created for Wing Commander called Origin FX. Obviously it’s a lot more powerful and robust, but very cool.
SG: It definitely gives a player a more personalised experience and everybody's going to feel like they’re in their own movie or something, very cool.
CR: Which is the point of it.
SG: There you go. Well that's it for today's show, check out Reverse the ‘Verse tomorrow for your chance to ask the Austin team questions about today's features as well as some exclusive videos. Also Ben Lesnick will be hosting a live playthrough of Wing Commander 2 to celebrate its 25th anniversary of release.
SG: That’ll be on Saturday the 17th so tune in if you can.
CR: As always, a big thank you to our subscribers whose monthly contributions help us produce videos like this.
SG: And thank you as always to all of our backers for the opportunity to be here in the first place.
CR: Yeah, thank you guys.
SG: Next week we’ll head out to our Frankfurt office and make sure to tune in for that one.
CR: Yes so that’s the show for this week. Thank you all for watching and we’ll see you.
Both: Around the ‘Verse.