Marius Airinei

Okay, I'll start. I think some of the stuff that Dan just showed is part of that, right? Dan, you've been involved with a lot of those behaviors, not just the engineer; the deck crew is the same, where we have characters that will take care of your ship, help you to land or repair, try to refuel your ship and stuff like this. So all those behaviors are the basics: first you need to do those behaviors and then you're going to hire them to do the behavior, of course. One part is this assignment and the custom assignment work that we were discussing. That is the way in which, let's assume the player hired three guys, first of all, right? So it means that they are assigned to you, they're part of your crew. So when you take the ship, let's say they are there already, first of all, and then you can give them commands. And the way you can give them commands, in essence, despite how the UI, the player-facing feature, works, it will eventually turn into a request for an assignment to the AI. And the request for an assignment to the AI means that basically we have something that we call Master Graph, which is kind of a state machine on top of the regular activities and sub-activities that Subsumption describes. And this is where the API, the custom assignment, comes into play, right? Because we have a custom assignment activity that can take whatever task you want them to do, as custom as you want, and they will just do it. And then there are things that we want the activities to expose. It's like, I'm not an engineer, but if you hire me and ask me to repair something, and I'm a janitor, I can try. Now, I might not be that good. It might take three times longer than what an engineer would take. And possibly I would put in a fuse that is also broken because I cannot understand if the fuse is broken or working. But I think we want basically NPCs to be able to perform jobs very likely, maybe poorly. And that might affect their morale, right? Because maybe if you hire somebody as an engineer and you give them janitor tasks, then maybe their morale will go down in respect to the type of tasks that you give. So all those things are already supported by the systems, right? So some parts are just the way we expose them to the different behaviors. And then a lot of this is polishing, right? Because I think people want to have a good experience on the animation side, making sure, as Dan said, that the usables are set up correctly, props are set up correctly, that you have the different types of fuses and stuff like this. And then I think another part from my perspective that is important is how this crew is managed by you, right? And persistence, so the persistence work we are currently working on as a company, will be a fundamental part, because if I hire somebody, the server goes down, comes back, well, I should have the same crew that I just paid, and it should be more or less where I left it, right? And trying to do the same things that I left them to do. And then possibly the simulation plays a part, because if I leave, let's say, my engineer to do a repair, and I leave the hangar and they're repairing, or my deck crew, let's say, I say, can you repair this ship? And then I go with my second crew on a mission. When I come back, it's not that because they're not active, the ship should not be repaired already, right? The time has passed. I expect that to still happen. So those things are more or less the type of challenges and the core functionality that we need for the full-blown experience, of course. But a lot of the high-fidelity experience, I would say, in terms of the abilities of doing those behaviors, is quite there. Of course, if the gameplay loop, let's say repairing, is not there, then we don't want to fake it on the AI side, right? So we just prepare the stuff so that it will interact with the fuses. As Dan was saying, right now we could tag the fuse to be broken. But once there is the gameplay loop in which, for example, using a fuse a lot might cause it to break, and then the game code behind the scenes already tags it, or maybe there's a health component that we can use, using that data is trivial for us because all the rest is already there. I think this is basically our process right now. If anybody wants to add some more.

I guess one of the things that is a big challenge with all of that, and with all of the social AI behaviors that we do, is, because we've got these very complex systems, just being aware of all the different ways in which things can fail and then having some good behavior to fall back on. As you said, in that example, if the wall panel's already been left open, that you can cope with that. And that's something that other games don't necessarily have to deal with, because they very tightly control the situations in which the AI is working.

For example, sorry Jared, if I can add just this little thing: what Dan showed, I think, is really cool. If as a player he was going to remove one fuse, the AI interacts with the fuse, so it knows that there's no fuse there. You don't risk that the AI will choose to play an animation on the missing fuse, because there's just nothing to interact with, right? So I think it is more complex, but then eventually what you get as a repayment for your hard work is the fact that this really works systemically, right? And the way you configure that, as Dan said, the flashlight: you just don't use it. You're not playing the flashlight animation without the flashlight.

And it also leads to other behaviors, like I was thinking about in the chow line and the mess hall. If there's loads of people having to go off, or the player leaving loads of trays behind, then there's going to have to be a janitor character who comes in and picks up those trays and takes them back, so we don't get a mess hall that's just full of trays.

And as Dan and Stuart showed, I imagine animation is going to be a major factor in this too. Because we have metrics, and many, many ships follow many of the metrics. But there are always going to be these outliers. We're nearing 200 ships at this point. So to have to go through and prove all these NPC crew out over every single ship with an interior is going to be a tremendous amount of work.

Yeah, I was going to just say as well, from my perspective, a lot of the challenges are just with dependencies. So if you had a task that the NPC needs to do which involves needing a multi-tool so that it can weld or repair or whatever it is, they need to be able to get a hold of that thing. So they need to have lots of ways of getting a hold of that thing as well, be it a locker or an equipment chest or whatever it ends up being, or even just a multi-tool lying on the ground. They need to be aware of, oh, that thing's over there, I'm going to use that instead. But like you just said about animations as well, we have that all over the place. One of the things I'm working on right now is the deck crew, and that's NPCs repairing ships like the Gladius. A lot of what we're doing right now is very Squadron-focused, so that the player can see these NPCs repairing the ship physically. If you went into a huge amount of fidelity on every single possible area of the ship, it would just be a colossal amount of animations. Say you have something on top of the Gladius; the NPC needs to be able to get up there, which means that they need to understand that in order to get up there, I need to grab the ladders, move them over to the Gladius and then go.

The ladders are trolleys. They need to be able to use the trolleys.

Yeah, exactly. They need to be able to push them, move them around. And then when they get up there, you need to make sure that they've got the animations to enter and it's all the correct metrics, which isn't always the case. So then you've got to go back to the artist and say, this isn't to metric. And usually you have to design a metric first and then get them to change their baby into something that you've written down months or sometimes years later.

I think the challenge is also to give them the tools to do this as efficiently as possible, right? Because I think you guys might also have a way to override all of this with custom animations, for example, for each ship. But I think the critical bit is how quickly you can do that, right? And how quickly Stuart can go through it in a test map. And this is why we have also done a lot of work on the custom animations, because we can use them in the feature tests and we can use them to try to speed up this process a bit, because Stuart needs to be able to go there and say, play the going-up-the-ladder animation, without spending hours trying to reproduce it. And the same for Dan.

I don't want to keep making AI crews sound like an absolute nightmare scenario, but we do want to effectively communicate what an initiative, what an endeavor it truly is. To what Dan and Andrew said as well, the fuses and everything, those are all part of the whole resource management system. And that system has to be developed and proven out and usable by players first, before you then figure out how to expose all that stuff for AI too. So this is my way of saying it. We're going to move on from this topic because there's a lot of topics we want to do. But I want folks to just be sure that they understand, to properly manage expectations. We are shooting for the moon with this thing. And when it is complete and when it is fully developed, it will be a thing unlike any other.

But it's also an iterative process, right? So we get the first step, then you can iterate, you can make it better, you can add more fidelity, the more you can, basically.

But NPC crew is not a soon thing. It is after many, many other things are done.

On this note, sorry, to also say one of my points. The idea is that we also try to reuse what we already have. So basically, for the social AI, we're already going to implement behaviors, activities for repairing, right? When you hire them, you just try to use the same, only with the input dynamically from the player, because you want to repair your ship, you want them to actually work for you. So basically you just give guidance on already existing behaviors that we are already trying to implement. So at least not to duplicate and not to put more work on this.

In theory, yes. So we already kind of showed a bit during CitizenCon, right? The outpost and the NPCs moving around trying to, I don't know, selling stuff, having combat with you. At that moment, actually, the planetary navigation was close to the end, but it wasn't finished, so we weren't able to use it. But now we should be able to use the planetary navigation in this kind of similar scenario. And I think the mission teams are trying to create some missions around this.

We can say, Marius, that we handed it over to design, that they already work with that, because I think that is a cool thing, that right now they already started using it and they can provide us feedback already, right? It's internal development right now. And as Jared said, it's something that people can experience this year, at the end of the year.

Yeah. And because you asked if we could actually move with NPCs everywhere, even to Lorville: in theory, yes. Because we generate the navigation mesh only around actors and vehicles, right? And actually, if we go farther away, we also destroy those areas, to not keep in memory blocks that are not needed. So yes, you could go around the planet with no problem. Theoretically. In general, theoretically, yes.

If you survive them shooting at you, yes.

Well, we'll see how it plays out in testing and everything. And there's a reason many games have leashes on stuff.

I think it's very likely that designers usually want them to stay more contained, and not the actual technology preventing you from doing it, of course, because it's the experience you want to give to the player.

A realistic character probably won't chase you for 80 miles.

No, because I think usually they will be told to not do it. And then I think eventually what we want to have is the ground vehicles, right? And then they might chase you with vehicles as well.

But that's a wonderful illustration of the difference between a design decision and a tech capability. The feature, the tech that the team is building, yes, it's technically possible.

Sometimes it's the other way around. It's like, no, you're going to do this by tech. And he's like, but I want that.

In theory, yes. At this moment, we are testing only with the actors, with NPCs. Also, in general, yes, those are big cargo ships that are part of the reinforcement behaviors, right, to be able to carry, I don't know, 20 NPCs, right? I'm not even sure if capital ships could land on the planet.

Anything could land on the planet right now with the tech that we made. I think the real problem is only that, as you said, we're working on navigation links, right? So some ships have different methods to enter and exit. So it depends on the ships; the methods that we currently support are the ones with the back door right now. And the ones, for example, that have internal elevators, we don't support yet. Or something with ladders, we don't support yet. But the ones with the back door, if it's a carrier ship, it's fine if it's set up correctly, but that is just a bare minimum, right?

I think if the player or the hostile is not actually in the pilot seat, they're not going to attack that ship.

For now. Yeah, I think right now there is one thing to say. We don't have a good tactic for them to decide how to destroy a ship. So, of course, they could shoot a rifle, but it doesn't really damage a ship much. And then yes, we also want to understand how to expose it based on the mission requirements, right? So for example, the guys could be called in not to destroy your ship; they will destroy you or capture you, right, in theory, eventually. So it depends on the type of information designers want to be seen, and they would probably search for somebody. It depends also what reinforcement means, because I think you brought up a good point. It could be that you arrive at a place where nobody is, and you trigger an alarm, right, that attracts some people that need to go there and check what's going on. But it could also be that there are already people that you engage, and some of them manage to request assistance. So they come, and the people who come already have an understanding that something is happening because it's been communicated to them, right? So you want to bring them in with a different kind of alertness that is shown to the players, so that they arrive already knowing that something went wrong with their friends and stuff like this. So we can support those types of things.

And then, of course, we've talked about AI with differing levels of intelligence and personality and stuff. You want AI who recognize, I don't have weapons to take out a ship, so I'm not going to bother shooting at a ship. And then there's always got to be that one person who's new and not really experienced, and he'll take his little pistol and try to shoot down a Cutlass. That's part of building a dynamic and diverse universe. You don't want every bot to be perfect.

No, and I think it's also a matter that if it feels real, then it's fine, right? You would expect if you shoot at a guy that is on the ground and he has a pistol, he might shoot some rounds, because that's what a normal reaction would be. And then he tries to find cover. Or while he looks around and doesn't know where to find it, he still tries to shoot at you, and then he goes and tries to find some defensive area.

That's where our trait system will come in. We're going to have different traits that will be integrated with the combat behaviors and everything. So if you've got a gung-ho character or a cowardly character, then there will be different traits, and they will affect different roles on targets, how they select them and other things like that.

One other thing about the animations for people with guns is what we get reviewed on a lot is trigger discipline. And that's about how you actually hold the weapon. And Steve Bender will chop you down if you don't understand proper good trigger discipline.

So I could start a bit on some ideas on what we are doing. We have a lot of performance tasks that we try to tackle to improve the frame rate on the dedicated server. Because on the client it's not a big problem. Usually you stream only what is around the player and you render only that, so it's not that costly. On the dedicated server, because we don't have server meshing yet, if you have 50 players and each of those 50 players is in heavy areas like Lorville, Area18, New Babbage, with a lot of NPCs, right, it happens that the dedicated server is going to have 7 or 5 frames per second. And this is going to impact how fast you are going to see the decisions from the NPCs. So yeah, this is one of the biggest problems that we have. And what we do is work on performance tasks where we can, plus we try to discuss with directors and designers to try to limit the number of entities that we put in the game. So yeah, these are the two things that I could think of at this moment.

One thing, and definitely correct me if I'm wrong, Fran, but when it comes to the performance of the characters that are inside the usables, we do have this sort of thing that we can fall back on, and I believe it's called usable idle, that's the technical term anyway. But basically, if the animation is having trouble loading, or there's too many NPCs and there's one that's just asking the server, hey, what's my next animation, and it's just taking a bit of time to get there, there is an idle animation, which I will put together, which is in context to that particular usable. And then even if it's not loaded the animation, at least it's doing some sort of performance that's in context.

Yeah. Basically, it's not actually about loading, but it's deciding what to do next, I think, right? I think this is what you probably meant. And I think, yes, absolutely. A lot of the stuff is being smart, especially in the social environment, where you know that the player is not going around killing everybody, right? Because they need to react very fast and so on. But in the social environment, yes, we absolutely need to be smart about the way we cover up the time it takes to find something when there are like 1,500 characters active at the same time. That's just a lot for one server, right? This is where I think it's even pretty good for what we have right now. And of course, it's still not the experience that we would like the player to have. There's a bit more stuff that we are discussing. I mean, first, Marius is absolutely right when he says, we do a lot of performance captures right now, every time, and we see where the biggest bang for the buck is as well. Because AI itself is definitely not that expensive, but it's everything that comes with the character, right? That is animation, updating animation, the rendering, all the calculations for, I don't know, if they're planning a ship with all the items and stuff like this. So AI, at the end of the day, is at the end of all the chains of all the features. So to have good AI, you need to have everything else working. I think one thing is definitely the synchronization as well, that we are looking at, so that we try to fix bugs. Sometimes I know people feel like, oh, this is what happens in the game. But I think it might be different. Some of these bugs are related to the fact that you see on the client something different than what happens on the server. And recently, we have fixed a lot of those bugs where, for example, there was a problem with the lower body turning. Because the lower body was not turning on the server, you would see a character fighting that was not looking at you. On the server, he was trying, but he was not turning, and that information was not right on the client. So you feel like, oh, the guy is not responding to me because he's not shooting. But he's not shooting because he's not pointing the gun at you, because he can't. And on the client, it doesn't even look like he's trying, right? So I think you have some types of discrepancy in experience; these are the bugs that we are absolutely looking at right now. We don't really need any change from server meshing or persistence or any other type of dependency. I mean, it's time; as you said, sometimes you need to just speak with the balance. But there are other things that I think we want to do. For example, at the end of last year, one of the things that we changed is the way we give priority to some of the calculations. So we give priority to the combat more than the social, and to some things in the social a bit above the combat. And I was finishing experimenting with some other ways of keeping priority with different LODs, and these are things that we have. We already have two versions of LODs for behaviors and movement and stuff like this, but we don't have yet, for example, what we want to do: a nice way of balancing the importance of the requests based on the LOD you are at. And if you switch LOD, right, if the player moves around and fights with, let's say, Andrew, right? And Dan is super far. Maybe he was close to me, but I left him, right? So if now it takes a little bit more time for him to find a new cover spot, I prefer that Andrew's cover spot is given to him more quickly. And we try to be very careful as well. We have a really limited set of raycasts we do every frame, right? A very limited amount of queries that we do. And some of the low-level systems that this query system uses, we are trying to optimize as well. The usable queries, we are right now working on making them faster. If that becomes faster, you can run quicker queries, right?

Setup and consistency. Setup is quite challenging, especially with a big, big studio like us, making sure everybody's doing things the same kind of way. Because when you go back to debug something and it's set up entirely differently to how it should be, yeah, well, it's another frustration.

Getting mocap time, but that's going to be fixed.

For me, it's the intertwined systems, right? For example, something I was looking at with Marius, right, was this transit system. You need to have a full understanding of how a system works so that I can also use it in the most consistent way, right? So sometimes you need to have either dedicated time from another team, making sure those things are synced, or make the best of your guesses on how something works so you can collect the right questions to use the other team's time in the most efficient way possible. And then the fact that sometimes some of the new features usually have an impact, right? So you need to do stuff in a way which encapsulates the risky part that might be affected to the minimum, right? So that as soon as something happens, it's all on that side. For example, the loadouts and the inventory: we have been talking a lot about the lockers, right? We did an implementation that way, which is that I can go to the locker and change. Now, as soon as the inventory is there, and the functionality for the locker, we can just replace the little part.

I was going to say lots of planning meetings, but I think, what I said before, the complexity of systems, just having to think through everything so you can get stuff as right as possible the first time out. That's probably a big challenge for me.

Challenging, but in a good way, is working on and trying to find solutions for performance. It's something that gives you the best for that situation, especially with limited resources.