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!
working side-by-side with engineers to flesh out tools/tech for procedural planets
made progress on manual setups required to spawn effects in engine
new designer has joined the team
churning through performance capture scenes across numerous S42 chapters
pushing on all story scenes taking place in the Schubin facility so it can be finalised
doing edits for big sequences for the opening and middle of the game
fleshing out different procedural terrain elements of Delamar and resolving various challenges
made a few changes to Levski exterior: integrated garages for ground vehicles
made the mining structures in and around the borehole more functional and did a polish pass
did some finishing touches to the moons to make the feel more distinct from each other
finished the design pass on the surface outposts and handed them off to the Art team
started work integrating Levski into the procedural version of Delamar: lobby, airlocks, garages, roads and parking areas
planned out the elevator network and workers area, and added administrative offices
performed some R&D work on foot constrained locomotion to give characters a true sense of weight at all speeds and angles
worked on some skinning tasks to widen the range of character customisation
worked with Weapons team on tools to spot errors in the pipeline and rigging new/updated weapons
progressing with Actor Status system: incorporates breathing, stamina, G-forces, injuries, etc.
added subsystems for suits getting punctured and patched, and recharging oxygen tanks
started mass production on Usesables
finalising the design of the Spectrum-Game integration to enable access to core Spectrum functionality in-game
began testing the new Stanton system PU level
tweaks and testing to in-house server launcher tool "Catapult"
performed initial round of testing on the Subsumption Editor's new conversation system
worked with system designers to create the AI basic feature test level and add behaviours for all NPCs
added new VFX test cases and editor checklist for the Particle Editor
focused on supporting 3.0 release of Cellin, Yela and Daymar
defining the visual quality required for surface outposts in 3.0 and beyond
implementing the new Light Groups system: surface outposts lighting reacts to low power, emergencies, hazards, etc.
new developer joined the team
refactoring the ship movement system to unify the movement pipeline between NPCs and ships
general improvements to the AI pathfinding and navigation: fixed issues with certain configurations of corners
focused on missions from two S42 chapters: expanding existing functionality and adding new ones
Subsumption Visualiser now allows the starting mission for a level to be overwritten for testing
added “platforms" (a template Object Container with a list of items) for the Missions system
blocking out new weapons: 2 Vanduul, 4 Kastak Arms, 3 Gemini, 1 K-Hex
completed first pass on Knightbridge Arms ballistic cannon (size 2 and 3) through the new modular pipeline
assisted the UK team with props in spare time
continued work on Object Container streaming and SolEd
performed housekeeping on existing code base to reduce compile time by several minutes
Sandi Gardiner (SG): Hello and welcome to Around the Verse, our weekly look at the development of Star Citizen. I’m Sandi Gardiner.
Chris Roberts (CR): And I’m Chris Roberts. So in last week’s ATV we shared a look at the Banu Defender and some of the lore behind the Banu species. On Tuesday we followed that up with a Subscribers Town Hall that went into more depth on the Banu culture and the design of the Defender.
SG: 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.
CR: Yeah 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 because it was a really interesting deep dive into the Banu culture and sort of design thoughts behind creating the Defender. Also this weekend a number of CIG team members attended BritizenCon. 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.
SG: Yes thank you and the photos that Brian Chambers shared about the panel were pretty fantastic, it seemed like a really great turn and we can’t wait for the next one.
CR: Indeed and speaking of Brian, let's go to Frankfurt for their Studio Update.
Brian Chambers (BC): 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 VFXs team. Work is steadily moving forward as they 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 manual setups required to spawn the effects in engine and we’re starting to see the moons starting to 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: Phillip. He’s working closely with Hannes and the team to get up to speed on the script and the remaining work for everyone. 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 Arshen facility. So they’re doing a push on all the story scenes for that location so the level designers and artists can finalise the Shubin environments. In addition they are 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 fleshing 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 borehole 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?”
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 borehole to give them a more functional feeling and a polish pass. They also did some final touches to the moons to help give them more unique flavour from one another.
The Level Design team finished their design pass on the surface outpost and it now gets handed over to the Art team. They’ll continue to work on it’s modular system for a bit longer. They also started work on integrating Levski into the procedural version of Delamar. They created an upper lobby that will that will connect the Levski interior to the planetary surface via airlocks, as well as serve as a place for future possible air rail to outlying 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 site itself with roads and parking zones with cool vistas. They also did some custom work 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 regarding foot constrain 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. They also worked on some skinning tasks to widen the range of character customisation. And they also continued 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. 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 Useables 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 and restarting the power supply, etc. The system allows us to have either the player or AI perform those actions or have both players and AI working on the same usable together.
On the social side of things we’re finalising the design for the Spectrum-Game integration which will allow players to access core Spectrum functionality inside the game, like party creation and management, chat, friends lists, 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 lead to additional tweaks and testing done to our in-house server launcher tool called Catapult. With Port Olisar now in the Stanton system level we’re currently able to test travelling 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 an 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 behaviours for all NPCs so their designated tests could be run. The feature tester is kicked off whenever new code changes are submitted to the GameDev stream. With the AI basic feature test level we are able to capture any AI related issues that could potentially be caused by code submission.
They also spent time to further expand QA’s depth of testing with 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 in 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 outposts 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 assets and layouts come closer to their final state. We’re also implementing the first stage of our new Light Groups system which gives us the ability to alter the lighting and mood of surface outposts based on various states such as low power, emergency or hazardous conditions.
The AI team in Frankfurt grew by one member this month so they spent time getting him 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 contextualise their actions.
For NPCs they did some general improvements to the AI pathfinding and and Navigation; AI were at times getting blocked on 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 Missions 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 initialise, through DataForge, which default missions play when entering specific game modes. Through the Subsumption Visualiser they’re now allowed to overwrite 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 think of it as a list of items that live within an Object Container with their own known world coordinates as runtime. A platform can be accessed by the mission logic and customised 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 customisation layer 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-Hex. For ship weapons they completed a first past on the Knightsbridge 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 are also assisting the UK team with props in their spare time.
The Engine team continued work on Object Container Streaming to help with our huge seamless world as well as SolEd 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 large projects like 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 2000) and in the end we improved the compile time 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 Yela moon ground surface out to space is showing up 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.
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.
SG: The Crusader moon environments and the Levski level design are going to be pretty fun to explore it looks like.
CR: Definitely, so the moons are… well they get cooler every week and they’re actually a really great test example where we’re sort of pushing our tech for the planets which will also pay off on the more involved planets like Hurston or ArcCorp or Microtech and beyond. So, it’s a great test bed and it’s kinda fun for me and we share it with you guys, I sort of see the progress weekly in it, gets cooler and better. So, this universe is going to be awesome.
SG: With all this new content coming to Star Citizen, it’s important to constantly play test for any bugs. This job falls on a very important department, the QA team, for more on that take a look.
Justin Binford(JB): I’m Justin Binford the QA Director.
Chris Eckersley(CE): I’m Senior Technical tester at Foundry 42, UK.
Michael Dalston(MD): I’m the Lead Live QA tester here at Wilmslow, Foundry 42.
Michael Blackard(MB): I’m a Specialist Quality Assurance tester.
Don Allen(DA): I’m a QA Specialist and my speciality is the Planetside.
Wayne Owen(WO): I’m the QA Control Specialist at Foundry 42.
James Stevens(JS): I’m a Senior Tester.
Andrew Hernando(AH): I’m a QA Tester in the LA studio.
Mici Oliver(MO): I’m a QA Character Art Specialist.
Glen Kneale(GK): I’m a QA Lead originally from the UK office, now residing here in sunny Frankfurt.
Colby Schneider(CS): QA Specialist.
Brandon Crocker(BC): I’m the QA Ship Specialist.
Vincent Sinatra(VS): I’m the QA Manager here in Los Angeles.
Melissa Estrada(ME): QA Technical Lead here at the Frankfurt office.
Scott McCrea(SM): QA Specialist for FPS Star Marine, destroyer of worlds.
MD: Often times 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.
SM: My day is awesome, I come into work and play Star Marine all day long. I can’t complain at all. Basically I come into work, start up Star Marine and try to break it all day long, it’s fun.
GK: I test the technology that’s going to go into our build to make sure it doesn’t break anything existing within the game.
AH: My favourite part of the job is basically get to break stuff and people get mad at me for it but it’s pretty funny cause then they think, ‘I didn’t think about breaking it that way’ and you’re like, ‘well, I broke it that way’.
JB: In QA we definitely work to try and break any kind of feature we can so we can tell the developers exactly how it’s broken and maybe what could be done to improve it.
GK: Our goal is to break it, yeah.
MD: Ok, this is a shiny new ship, this has just come in. How do we break it? How do we make it not work? How do we show the devs kind of where maybe some spit and polish needed here. I mean we’re working on a new ship at the minute, I can’t say which but needless to say it started off quite 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.
VS: It’s not the same as playing the game all day, no.
SM: After I break other people’s games I write it up basically step by step on 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 on why it’s happening. Just how to make it happen.
JB: QA is like where the rubber meets the road in terms of development so you have all your disciplines coming together, then QAs right there making sure that everything’s working properly and so then making sure that the magic happens so to speak.
WO: When we find issues we have to reproduce the issues so we will find the cause for the issue.
VS: 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 pretty much anything because our local developer and designers cover most of those bases.
GK: What we do is pretty important because it’ll prevent something catastrophic happening to the build which not only affects the testing but also affects the developers that could be working it as well.
MO: My job’s really exciting because I get to do something different everyday. I get to use the editor and my own photoshop as well as ingame stuff. I get to do a lot of Squadron 42 and really learn a lot about the characters and story.
AH: Take on specific dev requests to test their new changes or features that come in as well as fixes.
JS: Usually when we come in everyday there will be a new build for us and then what we’ll have to do is do something called a sanity check on them. This’ll be so that we can quickly run through each of the editor sections and quickly say, this works, this works, this tool is ok. Then we can send out a list of what’s broke and what’s not to the designers.
WO: With me it’s the controls which is quite a broad area of speciality as the control scheme is really, really large. There’s probably about 120+ different mappings of keys across all the different areas, it’s quite an arduous undertaking but it’s fun and it’s really interesting.
MB: I take point on the spectator camera, patch notes, some technical writing and training.
VS: I get to fly spaceships and I get to blow up spaceships. Whenever anyone needs anyone to fly a ship they come to me and that kind of makes me feel good.
CE: 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 from nothing create our own QA planet, put in mountains, valleys, deserts or anything. It’s a lot of fun whilst you’re testing because who doesn’t want to see Gary Oldman carrying a mop and a railgun all at the same time.
JB: When a release is approaching we start out with a build that’s fairly unstable and broken. So, we will continue to test it iteratively and report to production and stakeholders the most major issues so we can start stabilize the build and get it functioning on a basic level.
CS: Basically when we get a new build we do a flow check list, whoever is around, it’s working on specific things, we’ll do their section.
VS: 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 compile a new build with just that code, that way you can catch anything that’s a major issue before it gets submitted into a major branch which will possibly impact other people’s abilities to do their work.
WO: Then afterwards we’ll usually have a play test. So that all involved, most of QA in the UK, sometimes we’ll have to liaise with our US brethren and we’ll take part in large multiplayer test 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 would be grand. The playtest usually lasts an hour or two and towards the end of the day that’s where I’ll go to my specialist area and I’ll look up any new issues with controls. I’ll collate feedback usually from the playtest for controls, make sure that if there are any new designs in or if there’s any other people I need to speak to I’ll usually get that done. There are literally, literally hundreds of bugs that are rendered every day and there’s always some gems in there, the stuff of nightmares too. It’s just general fun all over the place.
AH: The funniest bug I’ve found in Star Citizen still has to be when the ship spawns for an AI, the AI will fall out of the ship. So basically the ship spawns in and all of a sudden the AI just goes bew…. Right through the ship and the ship just starts flying without any AI in it and it looks like it’s an auto piloted ship.
SM: I would probably say more recently that I found would be if you’re in Star Marine and you ADS which is aim down the ironsights and then you try to pick up another weapon, the camera would quantum travel outside of everything, basically it would be an out of body experience which is really awesome, it’s 100% repro, everybody got it and nobody found it until I did.
MB: 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 the whole planet on Broken Moon and that way you could see everybody’s fighting kinda like micromachines and you see little specs going and then you’d realize the planet is made, but it’s not meant to be seen from that view, it was really weird, but super cool looking. Like I loved that.
MD: When tasks come through they’ll often 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.
CE: Thankfully we’ve got a great devops department in Austin, Texas. So with the difference in time zones they’ll be covering most of the hours 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 and anything we need to follow up on.
VS: We do a hand off with the U.K. in the morning and the Germany teams.
CE: So we work very closely with the QA department in Frankfurt. They are almost entirely specialized on testing the engine and the editor and we’ve got a good flow of communication and knowledge between them and us.
ME: The cool thing about working at least 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 al ook at it, they can come up with a fix. It’s just like a rinse and repeat until we get our set of binaries that’s pretty clean meaning: no crashes, no weird issues that could be related to what their changes would bring into the build.
CS: Here in L.A. we work with the dev’s so when they have very specific testing requests we’re here to fulfil those requests for them right away and that way they can get their fixes in so things can keep progressing as fast as possible with good quality.
MD: 24 hour, seven days a week development is challenging for QA obviously because we get so many changes come through. Something may change within an hour, within half a day, within a full day, within a week and they might happen in L.A., they might happen here in the U.K., 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 L.A. We on a day to day we would hand off to each other.
ME: And they did one last night, well last night for us, afternoon for them.
JB: So it doesn’t just have to be locally siloed and we can continue the testing through other departments and other studios.
MD: The question I’m often asked is how important is the Issue Council, how important in the forum and I think everyone in QA would agree with me when I say: Massively important. Like when we’re testing the game we create numerous test cases, but there’s always the one or two scenarios that you don’t think about and that’s what the backers do for us because they actually go out and play and the game not to break, but to enjoy it, but will inevitably break somethings as they go along. So having those guys that like, actually willing to report it and show us step by step how to reproduce videos, screenshots of these kinds of things. They point us in the right direction and often times it can lead to massive issues that we may have overlooked being brought to light, then fixed, then better version of the game.
SM: There’s always something new being added. Sometimes last minute that needs to be tested. If they add new features it could break thirty other features that had it just barely touches so that needs to be thoroughly tested, that’s why we have players and testers kind of working together to get everything worked out.
MB: In my particular role I get to do so many things because of course there’s testing and of course destructive testing and then there’s even more testing, but I also get to again help with the 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 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 bringing everyone onto that same page. I really love that about QA and ensuring, 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 can.
SM: It plays out to ramping towards live by getting kind of the major issues 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.
BC: It’s a whole different world when the live environment gets their hands on something. As many employees that we 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.
MB: I think things start to get hectic with 3.0 coming up with so many changes coming to procedural planets and the ships, the cameras, different keybinds 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 gonna be where we want them to be ultimately.
BC: I foresee some incredibly long, incredibly long nights. Nights to days and otherwise.
MD: I had it quite easy back in my old job. It was 10 minutes from where I lived. You know I could stroll up there, here I travel an hour each day to get here. I would rather travel the hour everyday to come here than strolling up 10 minutes to the last job. When I first started, during one of our first social kind of things, I was talking to Erin Roberts and I uttered the sentence, we’ll I’m just QA and he stopped me and said, “I’ll never hear that, I will never hear the words ‘Just QA’” and he just reinforced how important our work is. I come to work everyday, you know well okay maybe not everyday with a spring in my step, we all have our rough 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,
WO: The relationships that are formed in here are so different from previous positions that I’ve worked in QA. As I say the most contact I’ve had with developers previously was just feedback on bugs.
JB: Anybody that comes into QA, if they’re so inclined they can dig into a different subject as much as they want and as they develop that knowledge, they can become a specialist and then a subject matter expert for the rest of QA and that can be incredibly valuable to the team.
JS: So skills in QA you would probably be would be curiosity to start with because yeah lots of it would be a case of, what happens if I do this? What happens if I do this or this? Going against what the logic is put in place.
ME: Even though you’re not or I’m not actually the one fixing it or James is not that one fixing the issue it just sort of feels like you were a part of the fix in that sense because you found it, you brought it to someone's attention, it was fixed and now the next build won’t have that issue anymore.
AH: 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 pretty normal whereas 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... Everywhere I’ve been it’s been great. I get to work directly with devs and give them direct input or feedback and you know I get to see that feedback taken so here it’s fantastic. You know working with any dev team is fantastic, especially when you’re a QA tester.
JB: We just work to make sure that the build is the best it can be before it goes out and that everything’s working as it should.
CR: So when Erin said to Michael Dalston, ‘there’s no such thing as 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.
SG: Yes and that’s also why we appreciate the community submissions to the Issue Council and of course our dedicated Evocati team.
CR: Yeah, 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, our front line QA plus the community members who really go out there and try to like find the bugs and write them up. They’re doing a massive service to everybody that will play the game down the line and even the people who will play the game when we get to what we call our live release cause there work sort of paves the way to make the game fun. Having that huge base of both pretty large internal QA but also the external group of you guys out there is actually 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. It’s cool.
SG: 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. Also tomorrow subscribers can get an exclusive Polaris t-shirt in the Star Citizen store, so check it out.
CR: Yeah and we got a new ship of the month as well starting May 1, all subscribers will be able to fly the Buccaneer all month long. It’s a pretty cool ship so have fun with it.
SG: It is a cool ship and if you want to know more about our subscriber program, click on the link in the description.
CR: Ok, 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 the smaller Wing Commander games like Wing Commander Academy and Armada.
SG: And I also want to thank all of our subscribers for supporting show like Happy Hour and this one, AtV.
CR: 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.
SG: Thanks for watching and we’ll see you…
CR/SG: Around the Verse.