One of the hardest elements of balancing combat AI is how much it's linked to server performance. I've seen early tests of Siege of Orison where the AI is like T-1000 Terminators, and then the exact same AI gets put on servers with 50 or 70 players, the server tick rate comes down, and it's like a Three Stooges routine. Can you talk about that disparity between the work you do to refine the AI and having it all go to hell with bad server performance?

Yeah, I think our game is particularly unique on some of these things, for different reasons. One is, I think in the last weeks there's been a lot of discussion in the industry about games in development and how things actually look behind the scenes of a game. I think we have this special position where we actually show a lot of the game that is still in development, because we are still in an alpha stage. What that means is that usually in development, you pick your battles based on where you want to be, not just where you are. So right now, for example, the things you're going to juggle are the time that you have and the resources that you have, and you need to try to balance which type of task you want to take. So let's say we want to have combat AI. You need to have a specific set of features there and a specific set of functionalities for designers, for example, to balance the game. Balancing means how accurate they are, how often they should shoot, which type of tactics they should play, where they should be, and so on. Now that one, as you say, needs to use a specific set of CPU cycles to do some of this calculation. And you need to distribute this calculation, because the more you're doing in one frame, the more the frame costs. You have a much quicker response time from the AI because everything is done in that server frame. But if the frame rate goes down, then it means you have more latency on how the player can react to that, and so on.

Now, in our multiplayer world, of course, we have two parts: you want to have a very high frame rate on the clients, and you want to have a high frame rate on the server as well, because the player might see the world at 60 frames per second, and then the server might run at 3 frames per second for different reasons, or 10 frames per second, or 15 frames per second. You have a really wide range of CPU usage on the server. So, for example, for Siege of Orison, I think one big focus for us was trying to optimize that usage overall, not just on the AI, because using a lot of CPU cycles for anything would impact the AI, but not only. It might impact the elevator that comes, it might impact physics calculation, anything pretty much.

On the AI side, in previous companies I worked at, the games I worked on were very much single-player games. Usually you have a very strong control on how many characters you want to enable. So maybe you have 16, 20 enemies active at the same time, and those use certain things. In Siege of Orison, we had peaks of 2,000. And 2,000 NPCs are not that simple, 2,000 NPCs that might fight the player, not just background NPCs or stuff like this. Now, can you be smarter on that side? Absolutely. Is it something we want to support long run? That's sometimes the question we need to answer. Are we expecting to have one server with 5,000 NPCs active at the same time? As you mentioned, we are working towards Server Meshing. So then the decision comes: do we want to invest time right now to make sure that we can run 5,000 NPCs on a server? Or are we expecting that we have 1,000 NPCs on each server at maximum, eventually with a lot of servers? 500 NPCs? You need to decide those types of budgets. Are we expecting to have a population manager that is smart and decides there should be 20 NPCs here and only one there because nobody's around there? Should they come out of a spawn closet? These are all pieces that are coming together right now. But when you don't have them, sometimes you either need to say, well, I accept that unfortunately we are not there yet with the level of experience, or no, I want to invest two months trying to be smart.

One good thing that we discovered was the vision calculation. Because on a really high-performance server, you can distribute vision calculation in different ways. You can consider either a frequency of update, meaning you want to update somebody every second, or half a second if it's close, and a different frequency if they are far. Or in the amount of ticks, you can decide. So we had something exposed from our core systems that could say, I want to update every 30 updates. But 30 updates at three frames per second is different than 30 updates at 30 frames per second. So we switched a lot to frequency. But even in that case, frequency means that if you want to do two updates every second for 100 NPCs that are around you, it's a lot of updates in that frame. That means that if you already have a low frame rate, it would be just lower and slower. So I think it's a lot of balancing there.

You said 2,000 NPCs that spawned throughout the entire server. In the first versions of Siege of Orison that I saw, the event alone was spawning 700 to 800 NPCs. And that was one of the great things about that event. It wasn't just designed to create new content for the players. It was designed to push on all the seams of Star Citizen and to see where we can get it. And we got the 100-player servers because of the research that was necessary from pushing on that stuff. We got all these other improvements. But I think in the end, the version that went live still spawns 400 or so NPCs during the course of the entire event.

But in the meantime, people can also be somewhere else, where they activate other locations, and there are other NPCs or other missions that can still run on the same server.