Andrea Carbone

There is quite a bit. Maybe Andrea or Will can also talk about some examples with the spaceships. But for example, if you look at the bartender right now, let's take one social example. What sometimes happens is that he's reacting to you a bit slowly. And that happens because when the performance of the server goes down too much, it takes a bit of time for him to find, for example, where you are sitting and how to navigate to you, especially if there are lots of characters. I think the worst case scenario is something like 2,000 characters or 1,500 characters active at the same time on one server. And that is quite a lot. Basically, to not go too heavy on the server, we of course distribute calculations over time, but that means that if you have so many requests at the same time, it just takes more time to receive the results. So of course server meshing is going to be beneficial for that. Some other stuff we see is the reaction time. In the FPS combat that Dan just mentioned, let's mention how we handle vision. Vision is physical vision. So you can really tell if a character there is seeing in that type of environment, like the player. But even that one is a distributed calculation. So you have a sort of cached information that you persist inside your perception system, and it updates every time it can. And if the player just pops out and it's not updating in that case, of course it's not that fast. We introduced some stuff like, for example, having priorities for people next to the player and stuff like this. But when the server is really heavy, with too much usage, then of course it's not that easy to make it as snappy as it would be in a single player experience.

Yeah, this is the same for ship AI. Imagine combat, a dogfight, when the AI and the player are very close to each other. The AI needs to continuously update its aiming position and its trajectory, because it changes continuously. And it wants to maybe orbit around the target, which can be the player or another AI. If the update is slow, then with every new update the relative position of the ships will be really different. So you will notice maybe the look direction or the gun direction is really off where it should not be. For example, William did some work on the accuracy for ship AI, for pilots. The accuracy basically simulates the aiming skill of the pilot or the gunner, and it updates over time. So the longer you are aiming at your target, the better you are; you have a higher chance to hit. And if the frame rate is too slow, this will never happen, basically. So the aiming will always be off, a bit behind, a bit higher, maybe depending on the strategy. Convergence will take a lot more.

If the frame rate is low... it's not based on the frame rate, obviously. It's not like per tick you add this much, but it's...

It's not based on the tick, it's really based on the time, but still, if you have one update per second, the player does so much, because the player is not updating one time per second. The player on his client is super snappy, and it's like, oh, I see it there. Now it's over there. Now it's over there. It's just really hard for the AI to find a great solution when the performance is very low, of course. When the performance is medium, then it's a different thing. We also have these updates on the behaviors: when things are a bit far, we update less; when things are closer, we update more often. Of course not everything is implemented yet, but we want to have better weighting of what is the action, what is the important thing that we need to update as well.

I think it's a bit of both. There are things that you need to do for the ideal case. Combat needs to be the ideal thing, in the sense that you want to have snappy decisions. Even in combat you have different approaches. For example, if you're going to cover, cover is a state where you can survive. It's like, I'm just in cover, I can make my calculations a bit slower while I'm doing some short-term decision that maybe doesn't require high performance. And it's the same with social. If I have a guy sitting on the chair, you can assume that there is a state that can persist and make sense. So if that one makes sense, then you can take the time that you have. Imagine that you have a guy reading a book. If he stands up in five seconds or in 10 seconds, it's not really important. The state can communicate what he's trying to do no matter what. And the idea of writing behaviors is a lot about this. You might stream in at any usable; you might start at any usable as a starting point. And then you might need to decide what is the best thing you can do. And deciding the best thing to do can take enough time. And also you might never find the optimal thing you want to do. You need to do those reactively. Maybe you are a janitor, you want to take the broomstick, and then the player arrives, and they say, okay, what do you do? So you always need to build your behavior in a way to handle the situation, of course. But sometimes it's also just bugs that we have due to the server performance that we see, and...

I would say as well, sorry, that the question is how much of the performance of the AI is based around the server performance, but also the server performance is based around the AI. The code of the AI can determine the server performance. We want things which are not going to slow down the whole server because lots of AI are processing the same thing. For example, with the usable calculations, trying to cache as much information as possible, so that if you have thousands and thousands of characters, they're not going to be slowing down the rest of the server performance and everyone else's experience just because they're calculating something which might be very cosmetic, for example.

It's about not what the server can do for you, but what you can do for the server.

Yeah, I think this is distributed across all the departments. It's not just the AI.

It affects everything. Even the IFCS... Every time, because we do predictions in a few places: based on the current position and velocity of the target, in the next frame it will maybe be here. One millisecond, two milliseconds is okay. Your prediction is fair. But if it's two seconds, it can be anywhere.

I think we could probably do a whole hour just on how important prediction is to AI.

Yeah, collision avoidance, for example.

I'll take that one. No, they're both AI. They are definitely both AI, especially from our perspective; they are going to be running the same behavior. An AI needs to aim a gun to shoot down a ship exactly the same way a human is going to aim that same gun to shoot a ship. The same behavior is going to run through all of this. Now, gameplay-wise, there are differences. A blade is a subcomponent on a ship. You will plug it in and assign a turret to use that blade, and the turret knows how to do it. There are disadvantages here. First of all, blades are going to be worse than NPCs. We have this grading: if you take an average player, they're going to be better than an average NPC, and that's going to be better than an average blade. So pretty much, automatically, it's not that good at the job. The turret blades are also going to occupy a blade slot, which means you can't equip another blade for other functionality you might want on the ship. So that is a valuable slot that you're losing just to have one turret start shooting without an NPC there. Basically, you're a cheap bastard; you don't want to pay someone to take that slot, whether it's a player or an NPC. Just pay the money and hire someone and get them to shoot. You can pay for a blade as a cheap alternative. Don't do that. I mean, do it if you can't afford anything else. And then the ship is only going to have enough blade slots to run a part of the turrets. Let's say you have a ship like the Hammerhead. You won't be able to have enough blade slots to make all the turrets functional. So there's that downside. So this is mainly where the difference lies. AI-wise, if some of the programmers want to chip in with how the behavior for this works, maybe they can clear some stuff up.

Yeah, the behaviors are just the same behaviors that NPCs run. Most importantly, the behavior will be the same, the activity will be the same, and how you characterize the blade will go through skills. So sort of editing the skills, the capacities, in this case.

I think, as Dan said, not all the seats can be replaced. So there would be crew members that would be purely NPCs. And I think the critical part here is that, the same way we let designers in a specific environment ask NPCs to do things, under the hood it's the same way as when the player gives them commands. If you ask an NPC to go and be the turret guy, what will happen is the same as when a designer sets up a mission and has an NPC sitting on a turret seat. If you ask a guy, you know what, I want you to fix that panel, you can do it. And it's the same way as when a designer asks an NPC to go exactly to that panel. The way we build the behaviors, and especially all this crew management, the guys in the crew, it's made in a way in which they can perform their jobs by themselves as best as they can, based on their skills and their traits. So imagine you have somebody who likes to procrastinate: you will have your engineer that goes around and sometimes finds a smoking spot, or some resting area, and just hides there and doesn't do his job. But you might have a supervisor that goes around, sends tasks to people and tries to supervise them. We have the same on the bridge crew. The captain can go around and supervise the NPCs and see if they're doing a good job or not, and maybe just tell them something. And it will basically be the same for the player. And then they can assign them. And also, I think there is more gameplay. You can find who's best at doing a specific job based on the ones you hire. You may hire somebody really good at shield management, but who kind of sucks at shooting from a turret. Maybe you need both, but you don't have enough money. You have one guy, and then you live with whatever covers most of your needs. But the good thing is that these skills and levels just carry through the game. So it's kind of cool that you see the guy maybe getting better at some of those. Some of those will allow you to train. Some others would just be your character traits. Somebody's a coward, and you put him on trying to defend you, he's just going to be a coward pilot. So he might just give up defending you if things are bad, something like this. But maybe somebody super skilled costs much more money. So it is going to create this extra layer of gameplay as well.

What I would like to mention is that we're already building all of our behaviors to take skills and traits into consideration. So basically, even the guys you are fighting in Kareah have skills and traits that are going to be driving some of the decisions. The behavior tree is exactly the same, but there are branches where it goes, well, do I have the skill to do this thing? Or how good am I at doing this specific thing? It's exactly the same stuff we will be using for NPC crews, because we built the system in such a way where we thought a bit ahead, and we're like, well, we want crews. Let's start building the skill and trait system that's going to dictate how the behavior runs or how efficient someone is at the job.

And you as a player discover that; you don't know. Some traits might enable a tactic, some traits might just make a tactic different. It's like, oh, maybe you do that and you're really not that good at it. Or the NPC thinks he's good at doing it, but he's not really.

If you have a very confident but stupid NPC, you will have some problems.

That's actually what I've been working on this sprint. We've been defining some stuff like cowardly and show-off for pilots. A show-off pilot would be more likely to do tricks, but his piloting skill would determine how actually useful those tricks are. So you might get a ship pilot who just really sluggishly rolls for no good reason and actually makes himself a better target.

I think it would be cool to have readability there with the messages. It's like, ah, look at me, you're never going to catch me. And then you destroy me.

So it sounds like Blades are a personality-less, skill-less, bottom-tier automation for turrets only. And then above that, there are AI NPCs who will have personalities and characteristics and aptitudes, things they're good at, things they're bad at, and they can operate not only turrets but other crew stations within ships.

Yes, exactly. And you mentioned something very important. There is the state of your NPC crew, which is going to be important. It's not just their skills. Are they well-fed? Are they happy? If they're almost about to leave your ship, then they're not going to do a great job shooting someone or manning the station. They're going to be upset. They're going to become careless. So you will need to maintain your crew. You'll need to make sure they're happy. You will need to make sure that you provide food. That's why our ships have a kitchen, have a food dispenser. So you really need to take care of them as your family. There are so many sci-fi shows that do this, that small unit on a ship where there's interpersonal relationships. You have to occasionally talk to them and see what's going on. You have to watch their stats, make sure they're in peak working condition, while a blade is just a blade.