Talk to us a little bit about the scale of Star Citizen. We can start with itemization.

A game like World of Warcraft, for example, you can have hundreds of items on the character. And that seems like a lot of items to keep track of and store in your inventory or in your bank and so on. Where in Star Citizen, just with your ships, the things that you buy on the website right now, you are already in the thousands, and we're going to have north of 50,000 items associated with one player. That's a scale that I've never had to deal with before, but it's something that we've been able to put a lot of thought into and figure out the best way to deal with, and it's still going to evolve, because at some point if we have a million online at one time, that's 50,000 per player, that's a lot of data to move around.

So before persistence, our architecture was very first-person shooter-like. Coming from Sony, the initial server cluster kind of looked like some of the models that we had over at Sony, where we had 250,000 concurrent with the simulators with that type of framework. We know where to scale horizontally. If we break from 250 to a million, we know what we need to federate next. Taking those principles from Sony and applying them to CIG, we can most likely hit those same numbers, but once you add persistence, then we have to go back to the drawing board and figure out where the bottlenecks are going to be, what services are going to get federated horizontally and things like that.

Yeah, we're writing all of our services in C++ just for the performance. And any given service can handle a large number of players and a large amount of data passing through it. So one of the ways we're going to scale, like Tom was saying, horizontally, there's two things to consider: load balancing and availability. So we have to make sure that if any service goes down, there's another one there to pick it up. The service is always available no matter what. So we'll have multiple instances of a particular service up at any given time, and if one goes down, there's another one available and so on. And the load balancing aspect would be just to distribute processing across multiple instances of a particular service.

We definitely want to apply the mega server methodologies, where you have a single login and a single universe that you are in where you can play with anybody around the world, rather than fragmenting up the player base on a server-by-server basis where once you lock into a server, that's it, you can only interact with those people. So we're trying to design that upfront with the mega server architecture in mind for both persistence and the regular matchmaking and persistent universe concepts.

And in the services themselves right now, players and objects have a location. So we already view them as a location in one universe. And there's other technical issues that have to be addressed with the game servers and interaction in the instances and stuff like that to really make the players feel like they are in that one large universe. But we've already been fighting that battle on the back end.