What is training for QA involved? Can you take us through some of the training and resources at a high level?

Yeah, absolutely. And like I say, we've been taking on a few people that are coming from the community who don't have any experience or education in games. It can help, obviously, if you have that kind of background. But even I, coming from a place where I had QA experience, learning Star Citizen was its own mountain to climb. So it is something that we thought about in the QA department, and we wanted to prioritize making sure that the people coming through knew the game, knew what they were doing and were able to get into work and test the project quickly, I guess. So yeah, when it comes to a project like ours, with the longevity of the project, it is super worth it to invest a good amount of time into fully training our people from scratch. And just from our guys, Jack, you had a bit of a university games and indie background before coming into QA, didn't you?

Yeah, so I did some game stuff at university, and I was in a much smaller company, four people, before I got to Star Citizen. And I think that does help, but I would say it's in no way required. I don't think during training there was any point where I was like, oh, I did it at university, so I'm so much better than everybody else who hasn't done it. Everybody was kind of just there like, oh wow, there's a lot of stuff to learn here.

Thrown in the deep end. And yeah, George H coming from retail, George S was literally in the Navy before you came to CIG. So you can come to this career from pretty much anywhere, as long as you've got the passion for it and you show us that you are willing to learn. I love to take new people who are just passionate about Star Citizen and want to test it and make sure it's good. So when it comes to the actuality of what we do with the training, we take all of our new starters here on an 18-day crash course through everything Star Citizen. For starters, that first week is just game familiarization. Obviously, we do need to be able to play the game. So for those of us who maybe haven't played Star Citizen before, but even those who have, it's good to get some time to sit down dedicatedly with each area and go through bit by bit. We start off with some game basics: being able to get your ship, fly around, go from place to place. Then we go through missions, so all of the contracts that we have in game through Contract Manager; mining, which now is quite an in-depth thing in terms of, we have the ship mining, ground vehicle mining, FPS mining, all that different stuff. So we have a full day dedicated to just getting those down. Then we touch on our other areas as well, like Arena Commander and Star Marine and Theaters of War. So, you know, that thing that we are working on. So yes, we do touch on the minigame areas as well, to make sure that everybody's up to date with all of those. If you were at the CitizenCon that I was on stage for, you might have got the chance to play Theaters of War there, actually. They had a really cool setup room for that. It's really good stuff, and I'm hoping that you guys can play it soon. But yes, after we've done all of the gameplay stuff, we move on to the technical aspects of things. So that is all of our test commands and what we call CVars, allowing us to get all of that debug information and go from place to place much faster. Say, for example, we have goto commands that allow us to zip from planet to planet in an instant, which saves us a lot of time while testing. As I'm sure you guys are aware, it takes a while to get from planet to planet naturally. How to run our internal builds: like Jack was talking about before, we do spin up our own separate servers and run what we call development builds, which allow us to get a lot more debug information, development information that you can't get on the live servers. Our internal editor as well; we do go over some basics for that, even though most of our testers don't usually dabble too much in editor. We do give them a little bit of basics around how to actually set that up. And then we start to move on to things like QA basics: writing bugs, what kind of evidence you need to provide for certain bugs and what kind of rules you need to follow while writing bugs, searching for bugs, testing existing bugs, that kind of thing. And then lastly, we do crashes, which does take a little while to go through. While you guys are well acquainted with the 30K, they do come in many different flavors internally, and because of that, we have to know how to deal with each one. Which can take a little while, but once you've wrapped your head around the basics... I would say that's probably one of the most technical and difficult things that we have to do in QA. So once you've got that down, you're pretty much on your way.