Star Citizen Live: A. I. and U

So yeah, funny enough, this type of bug visually always looks similar. I think it's one of the oldest bugs we have. I think maybe four years ago we started to have people standing on the chair. And the bug at that time was completely different from the bugs that we have right now. I think one of the first ones I remember had something to do with animation: when the look pose was actually kicking in and causing the body to turn, the full body animation would kick in and it would just detach the thing from the chair or the couch. So there was one a long time ago. And then I think for a while we were in quite good shape. And then we started with object container streaming. And this is where I think we started to find more sync issues, in a sense. So basically, for people who don't know, the chairs in Star Citizen are pretty much what we call usables. Usables are pretty much just the representation that the AI has of how to interact with the world. So a chair is pretty much just an object where you can sit. And to achieve that, there is one part on the AI code that basically says, oh, there's something where I can sit. So how do I need to arrive to start to play the animation to enter into the chair? And then I play my idle on top of the chair. Then there is this coupling of these two objects, the character and the chair. And then there's the streaming code that can happen at different times. So when you are part of the chair right now, you're also part of the aggregate of the environment. So when the environment streams out, what should happen is that the attached objects should first stream out, that is usually the character, then the environment streams out. And then when we stream in, the environment streams in, and then the character streams in as well, and it knows that it should be attached to the chair. And then the request gets propagated to the different components of the character, and then the component decides to reattach it and put it in the right state. Right now we are fixing some of these components, of course one at a time. When we find a bug, we fix it. So far we've found that there were some issues with the fact that initially the usable was detaching the character before streaming out. So at that point we had lost the information; you restart, you don't know anymore. That was one. Then we had the sync of the events that were coming from the networking, and we fixed that. Then we fixed another bug that was related to the order of synchronization. So basically what would happen was that some characters could take a longer time to stream in. And in the meantime, some other character that streamed in earlier and was not attached to a usable might steal the usable from the character still streaming in. So in a sense, some of those bugs won't really be so important in the future once we have the simulation and once we have server meshing, because it won't matter that the AI is actually sitting there. The simulation will take care of saying, you know what, they should not be sitting there on the chair, or actually the chair should be reserved for this guy, and if the guy is removed, then it will just be cleared. Because the other issue that we had is, if we reserve that spot, we can't guarantee that that character actually streams back in, because there are characters that might be dynamic. So it may be that the chair remains forever reserved and the character never comes into play. So we already added some code that handles that. And now we found another bug that is under investigation. We are trying to solve it. Sometimes the character streams in before the object it's attached to. So we are handling this code a bit better, and we are trying to handle the fact that some of this order might be slightly different, even if right now that should not really happen, but we will also keep the state. And the problem is this ownership within this code. What we want to achieve as developers is to have code that is owning that state, so that you can tell, okay, I should be sitting there. Now, if the chair is not coming, I know it's going to come. So it doesn't matter if it comes this frame, next frame, in 10 frames or one second, but I know that this is my state and I should not run other logic to do other things, and complete the sync. This is basically where we are at. And of course, it's quite fun to see that it's always the guy standing on the chair. It looks like, oh, that's hard to fix? And it's like, yeah, no, but it's just a lot of things happening at the same time that give the same visual result.

It's actually an example of something that happens quite often in a lot of systems in the PU, where the same outward symptom can be caused by a number of underlying causes, and it can often look like no progress is being made in resolving the issue, but actually there's a crazy game of whack-a-mole going on underneath that you don't see. I see the change logs, I see the reports: resolved, resolved, and it still happens.

And I think the good thing is the progress is still happening. What I mean is these systems are getting much more stable. It's just that you as a player sometimes might perceive there is no change, but actually there have been a lot of changes.

And that's one of those things: it used to happen an awful lot, and now we're spending more and more time on the very small occasions when it happens, but because they're so visible and so recognizable, over time those things just show up.

That is generally a good thing. The fact that it's so visible and noticeable makes us find it easier. Because otherwise, if it was a hidden thing that only happened in a corner, that you only notice once in a blue moon, then you would run with a big system that might cause way more problems later.

Yeah. And I think this is also why we are not putting any kind of patch yet. The good thing for us is that this helps us stabilize the underlying system. Some of those bugs are not even necessarily AI-related per se. It's just that we are at the bottom of the chain. So if something goes wrong on the way, then yeah, the AI looks bad.

The state right now, we're seeing a lot of difference technically when you look at the state of it when you play it in single player versus when you play it in multiplayer. We're definitely seeing a lot of issues that come from desyncs and sometimes from server performance or stability. But besides that, there's a lot of things that we still have in our plans from a design/behavior perspective that we want to do with the AI. The AI right now are fairly simplistic. They run a few behaviors that they run in an okay way. They either push if they have a shotgun, or they stay in their area and fight you from that area. We are now working on them going and replenishing ammo, and surrendering if they run out of ammo completely and they can't find a place to replenish their ammo. So we're adding this stuff, but there's so many other things that we need to look into. We need to look into how we flank, how we try to intercept and head off the player, how we're going to throw grenades to make sure the player doesn't hunker down in a single area and try to snipe everyone from there, how they're going to react to grenades getting thrown their way. There's so many things left to do here. We're just beginning, let's put it this way, from a design perspective.

I think definitely that one is going to be a critical part to have encounters on the surfaces. Right now I started some work on verifying how much the navigation mesh can generate on the planetary surface, [whether] we can properly handle the planet mesh. On that side, what is the plan? The plan is to use the navigation mesh, the features that we have, but expand it in a way which can work more efficiently on the planet. Planets are, in essence, created by those patches that live around the players. And basically, we would probably use a very similar approach for navmesh. So there would be this kind of dynamic navmesh, what I call virtual navmesh, that is going to be applied to planets. And the patches of this navmesh will only exist where we want to have AI. So it's going to be much more efficient than having the full generation everywhere. And then of course the AI will function in essence in the same way as it works somewhere else. The critical bit is how we connect those navmeshes. And this is part of the work we already started, I think last year, which was the ability of connecting multiple navmeshes. So we have what we call navigation links. Navigation links are basically a way to define some objects that can connect areas. So if you imagine the underground facilities on some planets, those will have some parts that have the entrance of the ground base, and that one might just have a navigation link to the planet navigation. And those can also link multiple zones, multiple physics grids, and allow the AI to automatically transition. I think in last year's demo, when there were NPCs entering a spaceship and flying off, that was basically the first iteration that we worked on for that. The spaceship lands, opens the door, and the door dynamically links to the navigation area that is physically placed on the object container that is placed on the planet. These two things dynamically link when the door is open in that environment. So the AI can find the proper path, can enter, can transition between different grids, and then it's going to disconnect and go away. So all these little pieces are just going to go together to create this experience on the planet as well. Plus, I think this is also going to be beneficial for having creatures on the planet and all the different types of life that we want to have there.

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.

Yeah, so currently I'm working on this mess hall behavior. It's for Squadron 42, this very specific chow line, mess hall behavior, but all of this tech is very much geared towards eventually providing systemic stuff for the PU as well. So if you're eating and drinking, that's your activity. Yeah, eat and drink is your activity, and you want to satisfy your hunger, hooking all of the bits together, because we've had little bits and pieces here and there. We've got people looking like they're eating and drinking, but are they actually consuming the things? And are those things being done based on their current requirements, whether they're hungry or thirsty? So I'm bringing that behavior in for Squadron 42, but that will then key in, and some of our other designers are already working on, say, vending machines [...] and making pizza vendors, and turning the very core features and adding content to expand those to lots of different situations that can be used in the PU. So there's lots of little things that we're working out now that are going to then allow our animators and artists and everyone else to generate lots of really great content for the PU. So that's currently what we're working on with Social AI.

Yeah, we mentioned some other stuff as well, even in my monthly report. For example, we have some dancing behavior connected to what Andrew is working on. As he said, the activity eat and drink is basically what allows any character to replenish its sustenance. For example, if you want to use an arcade machine, sorry, an arcade machine is more for leisure. It's food for your entertainment, so it's still food. But for the vending machine, let's say you want to search for food. It's the same as when the bartender searches for who can provide the beer you ordered. This is why the bartender was so critical, because he offered so much functionality we use everywhere else. The bartender has the same things; for example, when the patron drinks, he can check how much the drink is going down. And Andrew will use the same for when you're eating the food: how much food do I still have to finish? And it's the same with the vending machine. It's like, oh, I want to buy some food. Where is it? Oh, it's in the mess hall, or it's in the vending machine, or it's in the shop. And then, based on where that is, we can execute different types of sub-activities that are, in essence, part of our behavior tree, behavior flow. It's really more like a behavior graph there. But then we can understand how to use that concept, that it's food inside of any machine, and now we want to interact with that and how we want to consume it. And then how you want to dispose of what remains. Like what you're working on, Andrew, even bringing back your tray. And it's the same as we have some trash can where, if you're eating a candy bar, then you want to throw away your wrapper. And I think this is all stuff that right now is possible also because of the bartender. The bartender takes the glass and places it back into the dishwasher. The dishwasher is just something that accepts objects and takes care of cleaning them up. So I think it is really opening up a lot of doors. Actually, what Dan mentioned as well, the refilling of the ammo clips, is the same. The ammo boxes are just usables that can provide you either bullets or magazines. That's just it. And then you as an AI can say, I need bullets, where do I find them? It might be another AI, it might be the ammo box, and then you execute the behavior to get what you're trying to get. I think this is going to be really interesting, because it really opens up this realism a bit more. And our game is very physical. So if the guy needs to get the ammo clip, there's really a magazine there inside the box, and if the player arrives first, he takes it. I think this is going to be really, really cool to see happen.

It's great to see these little building blocks of different behaviors, because we're putting them together now in a lot more complicated ways, so we can build on those successes and build that level up, and have someone who just says, I'm hungry, go through all of these sub-bits of logic, and it all suddenly produces lots of variety of behavior. I was even thinking, oh, if he's hungry, but he's not 100% hungry, he might not finish all of his food and might have to then dispose of that, or things like that. It's really interesting.

And the more time passes, the more you add. The idea at the end is about complexity. For us, it's building something that allows us to add as much complexity as we can over time. So if at the beginning you just go there and you finish all your food, that's fine. And then in the next iteration you say, oh, now we actually add all this kind of taste on top of the behavior. And then we add more complexity, and it just looks more and more real.

And with the systemic stuff as well, the food that you're eating isn't just making you hungry. It also might, for example, if you're drinking beer, make you drunk. And if you're eating it, it might be poisoned.

So I think right now the bartender only complains. It's just like, hey, you should go out. I think it is part of the gameplay and priorities on that one, and we're working a bit on melee. As soon as we work on the melee behaviors as well, we can use that one to start a fist fight.

I think it's also a matter of: you don't expect every bartender to do this. A bartender in microTech is just going to call security. A bartender in, I don't know, a shady place might pick up a bat and whack you, or just punch you in the face, whatever. We also have to balance what happens with the other players, because there might be another player waiting to get their drink, and do we interrupt that? Maybe it's just smarter to call security, so he can continue serving drinks at that point, and security will come and deal with the intruder. It's probably less disruptive for the player wanting the drink, because otherwise you'll have a player that jumps behind the bar, the bartender takes care of him, the next guy jumps behind the bar, and they just block that bartender forever.

So I think we basically started to discuss some of the creatures we want to tackle first. I have some of the basic ideas on how we want to structure the code kind of clear, especially in my head. I possibly need to talk a bit more with Andrea as well about this. But the idea is that we are already splitting creatures into different groups. There are smart creatures and less smart creatures. Of course, if you want to simulate something like frogs or fish, they don't require crazy behaviors running on them. They might require a little bit of behavior, but not much. Mostly communication, audio, something like this, and some animation playing. The way I want to progress on this one is that there would be a basic flocking kind of state in which they can decide to be part of a flock. And when they're part of the flock, the flock kind of simulates them. And this can also become part of the more intelligent animals. You have sheep, you have kind of lions, and sometimes they move as a flock. And then when they want to do something specific, or when you as a player interact with them, they can go into this extra mode where it's like, I'm running a full-blown behavior, possibly to defend myself, attack, something like this. So the basic structure that we work on is pretty much following this line. Subsumption behavior can be run on any entity for us. So it's not really anything related to human NPCs or alien NPCs; really any object can be an AI agent, as we call it. They can move around. We can define how they move. We can have different following styles for animals, of course, and different types of actions. For example, the stuff we talked about before, the navigation links, can define how you jump over objects or how you use some objects to perform special actions. Jump against a tree and then jump on top of a guy. These are special actions that you can dynamically inject, similar to how a ship would do a special action when it wants to show off. And yeah, not sure if that answers all the questions there. Dan, if you want to add anything on that.

No, the question is basically whether we have started development, and I think we're very early. The guys that are working on the actual creature lore and the creature art, the concept art, are ahead of us, but that is generally a good place to be. I think the main reason we are where we are now is because we're still focusing on the human part, which is definitely a higher priority. If this was a game about hunting animals, then animals would have been our priority. But for now, we need to get humans, and maybe also some of the aliens needed for Squadron, in a decent state before we move to this. Otherwise, we would have to create an extra team, which means we pull resources from the existing teams, and it would be a risk right now. We'd rather do one thing, do it properly, then move to the next.

Priority is always at the heart of every game development decision. Even with what is now five studios, six studios around the world, somewhere around almost 600 people around the world, there's still a finite number of resources and only so many things that can be worked on.

The only thing we can do, and this is what we usually really do, is try to be smart. So if we make a system that we know might eventually be used by the creatures as well, we do it in the proper way, so that even if you are not officially starting the work on that, when you start, you start a little bit ahead. Like all this usable code, for example. And again, creatures are not necessarily always on the ground. There might be flying ones, and some of these use the same code that we use for ships: find a 3D path on a planet's surface. It's pretty much the same thing. We implement it in a way in which it can be used in a generic way.

And things like flocking behavior, for example, can feed back into the crowd behaviors that we've got with the humans. And I was actually thinking, if they're cosmetic creatures, that's one example of where you could have the AI actually being on the clients or on the servers. Because with flocking, if you've got flocks of butterflies or something like that, if you can't catch them or interact with them, then you can have those simulated to really high fidelity on your clients rather than the server and get something really reactive that can be very effective. Seeing lots of flocks of small creatures can be really cool.

Yes, it would be possible, because it's very similar to friendly NPCs. When we talk about crew management, you hire a person. Well, you buy a pet. And of course, their behavior is going to be different. Maybe the commands you can give them might be different. You might interact in a different way. But under the hood, it's really the same system. And this is what I was saying, it is cool, because the same way we opened up the door with the bartender to do a lot of behaviors, that opens up a lot of other stuff for the animals, for the pet. The pet might want to just find food, and you might put food into a little bowl, and when it searches for food, it finds the bowl that you placed there. So I think that is all cool stuff.

And of course, pets were one of the later, maybe even the last, of the original stretch goals, back during the original campaign.

Absolutely. This is basically exactly the stuff Andrew is working on. And this way creatures will also be the same. Creatures will use this stat system; they will get hungry. Humans will get hungry. They will have to find some food. Of course, we are not doing the same simulation where you have the bar and stuff like this. Based on your flow, if you are working, imagine you're really an airplane pilot for real. Then you get hungry. It's not that you say, oh, bye guys, and you just leave the cockpit and go eat something. So you can sustain these values and you can do it at the right moment. But we will basically have these needs that need to be fulfilled to perform better. If you are super hungry and super thirsty and you're fighting, you're not going to be as efficient as if you are fed and at full energy. Do you want to add some more stuff on the design side?

No, I think that pretty much covers it. It's just a simplified simulation; we definitely don't want to use as many resources on the server side as the player does. The effect is going to be the same. The guys are going to have needs, basically. They're going to have hygiene needs, food needs, drink needs. So they're going to try to cover this. They're going to try to find a place in their environment to [cover them]. If not, they'll try to find a place outside of that: can I travel a bit and then find what I need?

And I think sometimes we tend to think backwards, in a sense. Those systems also help us drive the behavior. It's not just that we want to support it because it's cool for everybody. It's cool to have that one because, first, everything works consistently. The same things that happen for the player happen for the AI. The AI is actually running the same code as the player. It is a sort of player on the server, in a sense. Of course, there are some adjustments on the state machine based on the needs that we have, but the state machine is the same. The systems are the same. They're just the actor in terms of the game. But really, that one also helps us drive realistic behavior. Otherwise what you do is just run randomly, you go eat something and stuff like this, but then it's very hard. You lose the context, and that context you need to put somewhere, and at that point you put it in the same place where the player has it, and then it works the same, and it looks much cooler.

I think what you said about... the reason why the player doing the same thing is so useful is because we've got this third-person player, and therefore things are driven through animations in the exact same way that they will be driven for the AI. So that behavior just falls out of the same systems, which is really useful. Although there are always tweaks; there are some slight differences, but a lot of it is so similar that you get that benefit.

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.