Star Citizen: Around the Verse - Breaking the Game
Transcript — every row opens the video at that moment
- 00:00:16
Hello and welcome to Around the Verse, our weekly look at the development of Star Citizen. I'm Sandi Gardiner. And I'm Chris Roberts. So, in last week's ATV, we shared a look at the Banu Defender and some of the law behind the Banu species. On Tuesday, we followed that up with a subscriber's town hall that went into more depth on the Banu culture and the design of the Defender. And since this is the last weekend of the Defender concept sale, it was a great opportunity for the team to answer subscriber questions about the new ship. Yeah, I know. So, definitely I would recommend if you haven't watched last week's ATV or perhaps had a chance to check out the subscriber town hall to do so cuz it was a really interesting deep dive into the Banu culture and the sort of design thoughts behind creating the Defender. So, also this weekend a number of CIG
- 00:01:05
team members attended CitizenCon. It was a great opportunity for us to connect with the community by participating in two Q&A dev panels. We're so grateful to the backers who organized the event. Thank you guys very, very much. Yes, thank you. And the photos that Brian Chambers shared about the panel were pretty fantastic. It seemed like a really great turnout and we can't wait for the next one. Indeed. And speaking of Brian, let's go to Frankfurt for that studio update. Hey everyone, welcome back to Germany. I'm Brian Chambers, development director of our Frankfurt office. Thanks for all the support and comments on our recent progress. Our global teams are working hard as you can tell, and it's honestly fun to give you some insight and show off what we've been up to. So, let's start off this time with the VFX team. Work is steadily moving forward as they
- 00:01:53
continue to work side by side with the engineers to flesh out the tools and tech required for the procedural planets. They've also made progress on the manual setups required to spawn the effects in engine, and we're starting to see the moons slowly take on their own subtle personalities, which is cool. Here's an early work in progress of some of the geysers on the moon Cellin. This month, cinematics had a new designer join the team, Philip. He's working closely with Hannes and the team to get up to speed on the script and the remaining work for everyone. Uh the team's continuing to churn through performance capture scenes across numerous chapters of Squadron 42. The current priority are scenes that take place on board the giant Shubin Arshavani facility. So, they're doing a push on all the story scenes for that
- 00:02:42
location, so the level designers and artists can finalize the Shubin environments. In addition, they're in the process of doing edits for a big sequence for the middle of the story and progressing with setting the vista for a major story event during the opening of the game. The environment art team has been flushing out the different procedural terrain elements of Delamar. With the surface being mostly covered with steep, spiky, mountainous shapes. When placing the Levski landing zone on the planet, we had a couple of challenges, such as what's the best workflow to create the large bore hole in front of the landing zone and the roads leading up to it. What specific elements do we need to make the station blend smoothly with the terrain and not feel like it was an afterthought?
- 00:03:30
Uh the exterior of Levski had a few changes made to it, such as integrating garages on the lower levels, so players can make an approach with ground vehicles. The team also made progress on the mining structures in and around the bore hole to give them a more functional feeling and a polished pass. They also did some final touches to the moons to help give them more unique flavor from one another. The level design team finished their
- 00:04:42
design pass on the surface outpost and it now gets handed over to the art team. They'll continue to work on its modular system for a bit longer. They also started work on integrating Levski to the procedural version of Delmar. They created an upper lobby that will connect the Levski interior to the planetary surface via airlocks, as well as serve as a place for a future possible air rail to outline landing areas. They implemented garages on the surface so people can spawn or park their vehicles, as well as added new approaches to the Levski side itself with roads and parking zones with cool vistas. They also did some custom works such as planning out the elevator network and workers area as well as adding administration offices. The tech art team this month did some R&D work
- 00:05:30
regarding foot constrained locomotion with the end goal to get the feet properly planted on the ground with each step and really give the character a true sense of weight at all speeds and all angles, etc. In its current state, we're getting good results and we still have some refining to do for certain velocities. Uh they also worked on some skinning tasks to widen the range of character customization. And they also continue to work with our weapons team both on tools to help programmatically spot errors in the pipeline as well as rigging for new and updated weapons. The system design team is progressing well with the actor status system. It now incorporates all the things that can happen to the player from breathing, suffocating, stamina, G-forces, drinking, getting injured, etc.
- 00:06:18
They added subsystems for suits getting punctured as the player goes through combat and the ability to patch your damaged suit and recharging your oxygen tanks. The usable system is reaching its full production status and we're now starting to mass produce them for both Squadron 42 and the PU. Once implemented in the levels, these will make the world feel so much more alive as the AI will be able to interact with almost any item in the world. The system is incredibly flexible from simple actions such as AI leaning on a wall to more complex ones like opening up a service locker, accessing the power supply inside them, inspecting that item inside, removing a broken item, replacing it with a new one, restarting the power supply, etc. The system allows us to have either the player or AI perform those actions or
- 00:07:06
have both players and AI working on the same usable together. On the social side of things, we're finalizing the design for the Spectrum game integration which will allow players to access core Spectrum functionalities inside the game like party creation and management, chat, friends list, orgs, etc. The goal is to keep the great majority of the stuff available in the Spectrum app while the core functionality needed for minute-to-minute gameplay be available directly in the game. The Frankfurt QA team began testing the new Stanton system persistent universe level this month with a focus on finding any major gameplay blockers. The entire process of connecting to this new PU level has changed, which led to additional tweaks and testing done to our in-house server launcher tool called
- 00:07:54
catapult. With Port Olisar now in the Stanton system level, we're currently able to test traveling between the different moons, as well as landing on them, getting out, etc. In the Subsumption editor, the new conversation system was recently added and was available for our initial round of testing. All issues encountered were entered in Jira and sent over to our Austin studio to be investigated. The QA team also worked together with our internal system designers to fix up the AI basic feature test level and add behaviors for all NPCs so their designated tests could be run. The feature tests are kicked off whenever new code changes are submitted to the game dev stream. With the AI basic feature test level, we're able to catch any AI-related issues that could potentially be caused by code submission.
- 00:08:43
They also spent time to further expand QA's depth of testing with the particle editor. New VFX test cases were created, added to our editor checklist, and these tests will continue to be maintained as we gather additional feedback from other technical testers and the team. Our lighting team has been fully focused on supporting the upcoming 3.0 release of the moons Cellin, Yela, and Daymar. Particular attention continues to be on the surface outposts and defining the level of visual quality we want to achieve for 3.0 and all subsequent surface outpost variations in the future. It's important for us to give a level of personality, interactivity, and quality to the lighting in the outpost so players will want to seek out and explore these locations. We're staying in sync with the UK studio to keep the lighting up to date as
- 00:09:32
assets and layouts come closer to their final state. We're also implementing the first stage of our new light group system, which gives us the ability to alter the lighting and mood of surface outposts based on various states like low power, emergency, or hazardous conditions. The AI team in Frankfurt grew by one member this month, so they spent some time getting them up to speed. For ship AI, the team did some refactoring of the movement system to unify the movement pipeline between NPCs and ships. This enables the NPCs, while piloting ships, to truly control them amongst other things. This will ultimately give the AI a finer level of control and a way to contextualize their actions. For NPCs, they did some general improvements to the AI pathfinding and navigation.
- 00:10:20
AI were at times getting blocked in certain configurations of corners, and this work will resolve that. They also made some fixes for the mesh regeneration to correctly exclude areas that AI should not be able to get to. Regarding the mission system, they focused on two different chapters of Squadron 42 missions, expanding existing functionalities and adding new ones for the designers. Designers can now define and initialize through DataForge, which default missions play when entering specific game modes. Through the sub-assumption visualizer, they're now allowed to override the starting mission for a specific level they're currently working on. This ultimately makes the setup and review of missions much more efficient for the entire team. Designers can now create what we call a platform. In simplified terms, you can
- 00:11:09
think of it as a list of items that live within an object container with their own known world coordinates at runtime. A platform can be accessed by the mission logic and customized in numerous configurations. For example, an Idris would be a basic platform, and in the game you can find multiple Idris setups in different ways, occupied by pirates, another by UEE, etc. All those unique setups would all reference the same base platform of the Idris and have their own unique customization layers on top of the pirates, of the UEE, etc. The weapons team has been incredibly busy blocking out new FPS weapons. This past month, they blocked out two Vanduul weapons, four from Kastak Arms, three from Gemini, one from K&H. For ship weapons, they completed a first pass on
- 00:11:59
the Knights bridge arms ballistic cannon size two and three. And this is the first ship weapon through our new pipeline to prep it for the modular upgradeable system. This month, they're also assisting the UK team with props on their spare time. The engine team continued work on object container streaming to help with our huge seamless world, as well as Soul Ed, which is our internal tool to help easily build full solar systems. Star Citizen and Squadron 42 are developed with C++, a programming language known for high performance. But due to the language design, large projects can suffer from long compile times, if not careful, the time spent between translating program code into machine instructions. And even with careful code design, compile times for a large project like
- 00:12:47
ours tend to always increase over time. So, we recently spent some time doing house cleaning on existing code. For this, we had to touch all the game code files, nearly 2,000. And in the end, we improved compile times by several minutes, which will have a positive impact company-wide. The engine team also spent time further improving the procedural planet tech. This clip of a seamless transition of the yellow moon ground surface out to space is showing off some of the improved terrain blending, improved blending of terrain and scattered objects, and improved transition dissolve blending. In the video, as the camera gets further away, the objects that were procedurally spawned on the surface are gradually blending out. There's still some work to do to get it to its fully polished state, but the progress is impressive.
- 00:13:38
That wraps us up for Frankfurt. Thank you so much for all the support you give us on a daily basis. The team really appreciates it, and we'll see you in the verse. The Crusader moon environment and the Levski level design are going to be pretty fun to explore, it looks like. Uh no, definitely. So, the moons are Well, they get cooler every week, and uh they're actually a really great test example where we're sort of pushing our tech for the planets, which will also sort of pay off on sort of the the more involved planets like Hurston or ArcCorp or MicroTech and beyond. So, it's a it's a great test bed, and it's kind of fun for me, and we share it with you guys, but I sort of see the progress weekly, and it gets cooler and better. So, I think this universe is going to be
- 00:14:26
awesome. And with all this new content coming to Star Citizen, it's important to constantly playtest for any bugs. This job falls on a very important department, the QA team. For more on that, take a look. I'm Justin Benford, the QA director. I'm senior technical tester at Foundry 42 UK. I'm the lead live QA tester here at Wilmslow, Foundry 42. I am a specialist quality assurance tester. I'm a QA specialist, and my specialty is the planet side. I'm the QA control specialist at Foundry 42. I'm a senior tester. I am a QA tester in the LA studio. I'm a QA character art specialist.
- 00:15:15
I'm a QA lead originally from the UK office, now residing here in sunny Frankfurt. QA specialist. I am the QA ship I'm the QA manager here in Los Angeles. Uh QA technical lead here at the Frankfurt office. QA specialist for FPS Star Marine. Destroyer of worlds. Oftentimes people will say, "Oh, QA, that's just sitting there playing video games, isn't it?" And it's like, "To an extent, but our game is not playing the game. Our game is breaking the game." My day is awesome. I come in to work and play Star Marine all day long. I can't complain at all. Basically, I come in to work, start up Star Marine, and try to break it all day long. It's fun.
- 00:16:01
Weather's free. Let's do this. I test the technology that's going to go into our build to make sure it doesn't break anything existing within the game. My favorite part of the job is basically get to break stuff. And uh people get mad at me for it, but it it's pretty funny cuz then they think, "I didn't think about breaking it that way." And you're like, "Well, I broke it that way." In uh QA, we definitely work to try and break any kind of feature we can so we can tell the developers exactly like how it's broken and maybe what could be done to it and prove it. Our goal is to break it, yeah. Okay. This is a shiny new ship. This has just come in. How do you break it? How do we make it not work? How do we show the devs where kind of the the maybe some spit and polish needed here and there? Uh I mean, we're working on a new
- 00:16:49
ship at the minute. I can't say which, but um needless to say it started off quite um shonky is a word we use within QA, but within a week we see it go from shonky to slightly less shonky to shiny to beautifully shiny, ready to go. Let's go kill some fools. That is not the same as playing the game all day, no. After I break other people's games, I write it up basically step-by-step exactly how to do it, what's happening. Sometimes I know kind of the underlying why it's happening, but it's not necessarily goes into the bug as far as my opinion of why it's happening, just how to make it happen. QA is like where the rubber meets the road in terms of development. So, you have all your disciplines coming together and then QA is right there making sure that
- 00:17:37
everything's working properly. And so, they're making sure that that the magic happens, so to speak. When we find issues, we have to reproduce the issues. So, we will find the cause for the issue. We have to touch pretty much every discipline, whether it's working in the editor, whether it's working in Squadron 42, Star Marine, Arena Commander, the persistent universe. We need to be an authority on on pretty much anything because our local developers and designers cover most of those bases. What we do is pretty important because it will prevent something catastrophic happening to the build, which not only affects the test in, but affects the developers that could be working it as well. My job is really exciting cuz I get to do something different every day. I get to use the editor and Maya and Photoshop, as well as in-game stuff. I get to do a lot of Squadron 42 and
- 00:18:27
really learn a lot about the characters and the story. Good to have you back in the fight. Take on specific dev requests to test their new changes or features that come in, as well as fixes. Usually when we come in every day, there'll be a new build for us. And then, what we'll have to do is do something called a sanity check on them. And this will be just so that we can quickly run through each of the editor sections and quickly say, "This works. This works. This tool is okay." And we can send out a list of what's broken and what's not to the designers. With me, it's the controls, which is quite a broad area of specialty. As the control scheme is really, really large. It's There's probably about 120 plus different
- 00:19:15
mappings of keys across all the different areas. It's It's quite an arduous undertaking, but it's it's fun and it's really interesting. I take point on the spectator camera, patch notes, some technical writing, and some training. I get to fly spaceships. And I get to blow up spaceships. And whenever anybody needs somebody to fly a ship, they come to me. And that that kind of makes me feel good. Two particular tools that we do test would be the loadout editor or the planet editor. Those are great fun to test and work in. The planet editor, it's been fantastic seeing all the work that's gone into procedural planets. And being able to go into the editor, launch that tool, and just from nothing create our own QA planet, putting mountains, valleys, deserts, or anything. It's a lot of fun whilst you're testing
- 00:20:03
because who doesn't want to see Gary Oldman carrying a mop and a railgun all at the same time? When a release is a is approaching, we start out with a build that's fairly unstable and broken. And so we we will continue to test it iteratively and report to production and stakeholders the most major issues so we can start to stabilize the build and get it functioning on a basic level. Basically, when we get a new build, we do a flow checklist. Whoever is around that's working on specific things will do their section. We pull down shelves for fixes. We have to build our own code half the time. Yeah, we have a lot of things that fall outside of the realm of normal QA duties. So you grab their change list, and then you compile a new new build with just that code, and that way you can catch anything that's a
- 00:20:50
major issue before it gets submitted into a major branch, which will then possibly impact other people's ability to do their work. Then afterwards, usually we'll have a playtest. Welcome to the squad, marine. So that will involve most of QA in the UK. Sometimes we'll have to liaise with our US brethren. And we'll take part in large multiplayer tests and we'll be looking for very specific things that usually goes above the head of the average QA tester including myself. I believe today's test was on serialized variables. So, if anyone out there knows what they are, that'd be grand. The play test usually lasts for about an hour or two. And then towards the end of the day, that's where I'll I'll go to my specialist area and I'll look at any issues with controls. I'll collect feedback usually
- 00:21:38
from the play test for controls. Make sure that if there are any new designs in or if there's any other people that I need to speak to, I'll usually get that done. There are literally literally hundreds of bugs that are entered every day and there's there's always some gems in there, the stuff of nightmares to to just general fun all over the place. The funniest bug I found in Star Citizen still has to be when the ship spawns for an AI, the AI will fall out of the ship. So, the basically, you know, ship spawns in and all of a sudden the AI just goes right through the ship. And it's just the ship just starts flying without any any AI in it and it's looks like it's an auto piloted ship. I would probably say most recently that I found would be if you're in Star
- 00:22:26
Marine and you ATS, which is aim down iron sights, and then you try to pick up another weapon, the camera would quantum travel outside of the of everything. Basically, you'd be in out of body experience, which is really awesome. It's 100% repro, everybody got it. And nobody found it until I did. There was one where like if you died, your body would start swirling like this and then if you did it just right it would pan out and then you got to see like the whole planet on Broken Moon. And that way like you could see like everybody's fighting kind of like micro machines and you see like little specs going and you'd realize that the planet is made but it's not meant to be seen from that view. It was really weird but it was super cool looking. Like I loved that.
- 00:23:13
When tasks come through, often they will be divided into certain disciplines. So, is the task relevant to say Star Marine FPS combat? Is it relevant to ships? Is it relevant to the persistent universe? Is it relevant to weapons, shields, the hundreds of thousands of different little things that we've got obviously in Star Citizen. Thankfully, we've got a great devops department in Austin, Texas. So, with the difference in time time zones, they'll be covering most of the hours where we're signed off. And when we come in, they'll be signing off usually with some sleepy messages and updates of how everything's going, anything we need to follow up on. We do a handoff with the UK in the morning and the Germany teams. So, we work very closely with the QA department in Frankfurt. They almost
- 00:24:01
entirely specialized on testing the engine and the editor and we've got a good flow of communication and knowledge between them and us. The cool thing about working at least here with the engine team is when we find issues, we can actually send them to them on the fly. So, we will message them directly and be like, "Hey, I found this issue. I think it might be related. Do you want to take a look now?" And then if they take a look at it and they can come up with a fix, it's just like a rinse and repeat until we get a pair or set of binaries that's uh pretty meaning like no crashes, no weird issues that could be related to what their changes would bring into the build. Here in LA, we work with the devs. So, when they have very specific testing requests, we're here to fulfill those requests for them right away. That way they can they
- 00:24:49
can get their fixes in so things can keep progressing as fast as possible with good quality. Nice work. 24/7 days a week development is challenging for QA, obviously, because we get so many changes come through. Some of them may change within an hour, within half a day, within a full day, within a week. And they might happen in LA, they might happen here in the UK, might happen in Germany. We just don't know. We have developers all over the place changing all little bits and bobs. However, we're supported by three other awesome teams, one in Frankfurt, Germany, one in Austin, Texas, and one in LA. So, we on a day-to-day we will hand off to each other. And they did one last night, well, last night for us, afternoon for them. So, it doesn't have to just be locally siloed, and we can continue the testing
- 00:25:37
through other departments and other studios. The question I'm often asked is how how important is the issue council, how important is the forum. And I think everyone in QA would agree with me when I say massively important. Like, when we're testing the game, obviously, we create numerous test cases, but there's always the one or two little scenarios that you don't think about. And that's what the backers do for us, because they actually go out and play the game, not to break it, just to enjoy it, but they'll invariably break some things as they go along. So, having those guys there like actually willing to report it and and show us step-by-step how to reproduce, videos, screenshots, all these kind of things. They they they point us in the right direction, and
- 00:26:25
oftentimes it can lead to massive issues that we may have overlooked being brought to light, then fixed, then a better version of the game. There's always something new being added. Um, sometimes last minute that needs to be tested. If they add new features, it could break 30 other features that it just barely touches. So, that needs to be thoroughly tested, and that's why we have players and testers kind of working together to get everything worked out. In in I in my particular role I get to do so many things cuz of course there's the testing and there's of course the destructive testing and then there's even more testing but I also get to again help with patch notes and help with training the people who are not familiar with our current processes. So I get to educate a lot of people who sure they've been in
- 00:27:13
development a while but they haven't been in QA for quite some time and so there's a lot of new ways that we're tackling problems and kind of just bring everybody onto that same page. I really love that about QA and ensuring like hey we're getting to the finish line. Let's do it all together. We've got this. Let's make the best product that we possibly can. It plays out to ramping towards live by getting kind of the major issues uh found out before it goes to live. I want to make sure that I send out a game that people are having fun playing and don't experience crashes or lags or that kind of major buggy issues. It's it's a whole different world when
- 00:28:02
the live environment gets their hands on something you know that as many employees as we might be able to have working on something and being able to focus on something beforehand. Obviously it does not compare to when it hits live. I feel things are going to get pretty hectic with 3.0 coming up with so many changes coming to procedural planets and the ships, cameras, different key bindings that we're going to be doing. All these different changes that we want to make sure are just perfect for our players are coming up and are going to be where that we want them to be ultimately. I foresee some incredibly long incredibly long nights and nights to days and otherwise. I had it quite easy back in my old job. It was 10 minutes from where I lived. You you I could stroll up there. Here I travel an hour every day to get here. I would rather travel the hour every day
- 00:28:51
to come here than strolling up 10 minutes to the last job. Like when I first started the job in one of our first social kind of things, I was talking to Aaron Roberts and I uttered the sentence, "Well, I'm just QA." And he stopped me and said, "I'll never hear that. I will never hear the words just QA." You know, and he just reinforced how important our work is. You know, I come to work every day, you know, okay, maybe not every day with a spring in my step. We all have our off days, but I know that when I go home from that day, that I will have done something meaningful and helped, well, make the best damn space sim ever. The relationships that are formed in here are so different from from previous uh positions that I've worked in QA. As I say, the most contact I've I've had
- 00:29:40
with developers previously was just feedback on bugs. Anybody that comes into QA, if they're so inclined, they can dig into a different subject as as much as they want and uh as as they develop that knowledge, they can become a specialist and then a subject matter expert for the rest of QA and I think that's uh that can be incredibly valuable to the team. So, the skills a QA would probably need would be curiosity to start with because yeah, a lot of it will just be a case of, "Well, what happens if I do this? What happens if I do this or this?" And going against what the logic is put in place. Even though like you're not or I'm not actually the one fixing it or James is not that one actually fixing the issue, it just sort of feels like you were part of the fix in that sense because you found it, you brought it to
- 00:30:28
someone's attention, it was fixed, and now the next build won't have that issue anymore. I have heard many stories about QA, you know, being separate from the dev team and I've never actually had that experience of being separated from the dev team. So, for me this is this is pretty normal where is, you know, other people always tell me QA here is great, you're so lucky and I'm like not since yes, I have been lucky and it's it's everywhere I've been it's been it's been great. You know, I get to you know, get to work directly with devs and you know, give them direct input or feedback and you know, I get to see that feedback taken. So, here it's it's fantastic. You know, working with any dev team is fantastic, especially when you're a QA
- 00:31:17
We just work to make sure that the build is the best it can be before it goes out and everything's working like it should. So, when Aaron said to Michael Dalton there's no such thing as just QA, he was speaking for the both of us. The task of breaking the game sounds fun, but it would be hard to overstate how important their role is. Yes, and that's also why we appreciate the community submissions to the issue council and of course our dedicated Evocati team. Yeah, I mean it really isn't the funnest job to be on the front lines when the game doesn't work and you have to report the issues and actually figure out how to report them in a structured manner so a programmer can repeat the bug and then fix it. So, you know, our front line QA plus the community members that really go out there and try to like find the bugs and
- 00:32:04
write them up. You know, they're doing a massive service to everybody that will play the game down the line and even the people that play the game when we get to what we call our sort of live releases cuz their work sort of paves the way to make the game fun and you know, having that huge base of both pretty large internal QA but also the external group of you guys out there is actually you know, a massive a massive asset to our ability to build something on the fly as we're doing it having you guys play it as we develop it. So, it's cool. It's very cool. Community feedback is very important across the board for us at Star Citizen, and we've also heard your requests regarding new merchandise in the RSI store, which is why we're adding five new pieces tomorrow. And
- 00:32:52
also tomorrow, subscribers can get an exclusive Polaris t-shirt in the Star Citizen store, so check it out. Yeah, and we got a new ship of the month as well starting May 1st. All subscribers will be able to fly the Buccaneer all month long, and it's a pretty cool ship, so have fun with it. It is a cool ship, and if you want to know more about our subscriber program, click on the link in the description. Okay, so that's it for this episode of Around the Verse. Please join us tomorrow at noon Pacific for Happy Hour Museum. Ben Lesnick will reveal the history behind some of these smaller Wing Commander games like Wing Commander Academy and Armada. And I also want to thank all of our subscribers for supporting shows like Happy Hour and this one, ATV. Of course, and Star Citizen only exists because of our backers, so I just want to say thank you to everyone who has supported our game. Thanks for watching, and we'll see you
- 00:33:40
around the verse. Thank you for watching. So, if you want to keep up with the latest and greatest in Star Citizen and Squadron 42's development, please follow us on our social media channels. See you soon.
Transcript from YouTube’s automatic captions — punctuation and Star Citizen jargon are approximate. The video itself is hosted by CIG on the official channel.

