Dan Baker

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.

I'm not aware of anything.

So I think in general, it's connected to the stuff that we want to do with ammo and resource management, as Jared was also mentioning, right? For example, we already have some work that we put in for investigating bodies, right? And in general, when you would have to search, these all connect, right? So when you need to find ammunition, for example, you've finished your ammunition, what you would do is exactly the same as a bartender would do, right? They would request a system to give them a usable that can provide them with a specific set of objects. In this case, ammunition for your pistol or your rifle, right? And that could be a body to loot. It could be a crate to loot, right? It means that you go to the object, you play the animation that Stuart and the animation team make, you look, and you know, of course, what you are after for looting, compared to what you really need to go and find. I mean, you could pretend that you don't know, and let the AI sometimes, maybe based on traits, find somebody that doesn't have anything as well. But in theory, the AI might know where to go and what to loot. So these types of things are an example where I think a lot of the work that we've done on the social side is not in isolation. It's exactly the same things that you need for combat. It's exactly the same thing that you need for pretty much anything. And then it uses the routing, as Dan has shown, that is, the ammunition would be some usable inside a usable that is the body that you need to loot, for example, or the crate. So when you say pick up, it routes through the right object, and then you play the right animation because you carry this extra information with the action. It's just a matter of setup, but the behavior is going to be the same. It's like, give me something where I can get these bullets. Oh, is this usable? Okay, cool. It can either be a physical bullet that you find on the ground. Maybe you find a magazine on the ground. But it could be just that you know that something belongs to the loadout or the inventory of something.

That actually starts to touch on one of the relatively new things that we're starting to look at, which is that currently NPCs are all-knowing, right? They know everything about everything. Like they know if the wall panel or the ship is in use or not. But what we want to start trying to introduce is the illusion of them not knowing where something is. So like Fran was just saying, with the ammo, the NPC knows straight away whether that guy's got the right ammo for them or not. But we want them to go and check anyway. And the same kind of thing with something like a vending machine. If an NPC is going to go to a vending machine for something, it might be nice if another one comes up and then they go, oh, it's already in use, I'll just sit back and wait for a minute. And maybe that could even introduce the chance for them to have some kind of a dynamic conversation as well. So it's just those small steps that we're making towards trying to create this larger, more complex AI behavior.

Absolutely. Because I think it's the best thing that will reduce the workload on the servers, right? And I think, as a lot of people report when we read all the posts on Reddit or everywhere, you can feel that there is a very good experience for people when the servers are fresh and there are not a lot of systems or a lot of locations enabled. So I think this is why we are really pushing through this technology that is server meshing, because we know that if you are on more servers with less workload, the experience is closer to what regular games do right now.

Just to talk briefly, sorry, about our kind of frustrations as well: we could make a thing and we'll test it in single player and it'll work great. We could test it again in a local server on our machine and it'll still work great. But then you send that out to the PU and a week or two later, you'll get a bug back saying it doesn't work in the PU. It's like, but it works.

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.

Yes. And the problem is often... I'm sure Dan or Hayden or Idris can say more. It's so easy to even get lost sometimes on why things don't work. And I think we are basically constantly trying to say, okay, this is the problem, so let's try to add some extra debug draw to try to track it easier next time. And we try to do that, or, oh, the message is not really clear. Right, Dan?

It could be the most simple thing ever. It could just be you're missing a left tag, you're missing a right tag, and then you'd spend half a day debugging it. And you're like, oh, it was just that. You missed this one little field. But yeah, there's a lot of information going into these usables.

You can spend quite a bit of time just breaking a single entity down to its core parts, just saying, okay, well, this is okay. So you take that out and then you put a different thing in. And it's a bit like if you're building a PC and you just swap out different components just to see which one's the broken bit.

Yes, absolutely. That is usually a very good, easy way for debugging stuff. You start to remove and say, is this the one that broke it? Or just do a little step at a time.

I think Fran's answered that a few times already, haven't you? It's one of those things. I mean, I've answered it when I've been doing Star Citizen streams as well. It's one of those kinds of bugs that has the exact same visual output, but it has lots of things that can cause it. So you fix it one way and then the next week you've got the exact same visual output, but it's a completely different bug. It's just one of those.

There's so many things going into the usable code. It's really a jungle sometimes to figure out what exactly is causing this bug.

Yeah, definitely. It could be a missing animation. It could be the animation names changed. It could be the setup changed slightly by accident in the parent above the variant. So it could be absolutely anything.

I remember one reason. It was caused by people leaving the area, then the NPCs that were still sitting in the seats basically got turned off. And then when a player came back, they were turned back on, but the game didn't put them sitting correctly in the seat anymore. So they were just standing on it instead.

There are tons of problems basically that are causing that, and they're mostly coming from the streaming right now. I'm the first one that hates that bug. The problem is that the AI is at the end of the chain. So every time something gets improved, we get these side effects that all look like the same bug. But for standing on the chair, this is what we are trying right now. We will dedicate some time to make a proper plan. I'm scheduling some time, because I'm a bit tired of seeing it. Of course, eventually, I really want to have a proper animation of a guy standing on the chair just on purpose, and it would be like, gotcha, a one in 1,000 NPC. One in 1,000, it will happen, and he does it on purpose. Yes, we need to do it. But it's basically a lot. Sometimes, for example, when something streams out, we don't know that it will eventually come back. We can't right now guarantee it, because we don't have the proper persistence of that stuff yet. So we either reserve that object for somebody that might never come back, or it might come back with a different ID. And sometimes it's like, this was yours, but now you can't use it because it's reserved for somebody that is never going to come back. So we are not doing it. And then, of course, sometimes what happens is another NPC actually sits there before. And this is why you sometimes see two NPCs, one next to each other. The streaming takes too long, and then the guy's already there. But there are also lots of fallbacks in place already, and whenever we find them, we basically add them and then we try to recover from some of the situations right now as well. So there are a lot of little pieces, because with the population manager, of course, this is meant to be different, right? When NPCs go away, those will be repopulated by the population manager. So this is why, in a way, this is not really a problem that will exist in the future, right? Because with our plan it's already a non-problem in a way, the fact that the guys just come back because the streaming kicks in, right? But then there's of course the stuff that there might be some bugs sometimes with the LOD update. We try to be efficient in updating stuff that is not visible, and maybe that one fails to attach, and we are searching for some of this stuff. So, as Dan said, it's the same visual problem with several bugs that we are constantly fixing, and some new optimizations and things might still bring it back.