Andrew Davies

Maybe I can start there. I think obviously, as we said several times, yes, it is very correlated to the server FPS, server performance, with our AI functions right now, just because basically imagine you are playing a game at that FPS; it's the type of refresh rate of the knowledge of the AI or the decision making that they do, right? So if we play at three frames per second, then obviously for the AI it's kind of a slideshow, right? And in addition to that, what I think sometimes we don't always make clear is that we don't want to bog down. When the server is low in performance, we obviously don't want to do more calculations trying to catch up, because that would make it even more slow, right? So a lot of our systems are spread over a certain amount of frame calculation, for example, the pathfinder. It's a very expensive calculation that usually AI does. And obviously we don't want to do one full path calculation for every single AI every frame. That would just be too much. So usually pathfinding in games is made as time-sliced, what we say. So it goes through a request and goes through multiple frames to return you something. So the less the frames, the longer it also takes to do some of this stuff, right? And just also to be clear, not all the issues that you guys see in live are always related to FPS performance. Some are, some are not. Sometimes we have just bugs as well on our side and we work hard to fix those. So obviously, right now, usually the engine works pretty bad under five frames per second. We have other issues with the mission system and stuff like this when it goes under five frames per second. I think obviously more than 10 would be the ideal, let's say, to have something decent. Over 8, 9 frames per second, usually the AI can function decently. Between 5 and 8, it starts to struggle a bit, because again, all those requests just pile up a bit more. So it's not just about the frame rate, but it's also because this creates this kind of slow response to other systems, for example, raycasts for perception or environmental analysis, again, pathfinding once again. So basically, we are working towards changing a little bit some of these patterns so that we can support better FPS in the new year. Especially, we're going to focus on some of those improvements so that we are going to be less reliant on extremely good server performance. But obviously, there are two parallel initiatives in the engine, or in the company. One is trying to figure out how to make this faster overall, right, because it's not just an issue if the server goes at 5 frames per second. This is going to cause multiple issues across lots of systems, right? You guys see problems with the elevators, problems with spawning that takes much longer, because obviously even spawning takes longer if the frame rate is very low and there is too much work happening in the background. So basically we have these two initiatives, right? One that is making sure the server goes as fast as possible, and the other one is making sure that our systems can cope as best as possible with low frame rate. There are different ideas; it's not necessarily important to share them all right now. But on an additional note, some stuff that me and Andrew especially have been working on in the last weeks was also to fix some of those bugs that are basically giving you this impression of not responding, but it doesn't mean necessarily they're really not responding, right? So myself, I was looking at one bug with Andrew; we fixed two, three situations like this, where maybe the behavior gets into this kind of strange loop. One was, and I think most of you guys that are fighting in FPS have seen those, that you're fighting with some, and then some of them might just look at you and not shoot at you, but they would aim at you in some situations, right? One that I was looking at was this situation where we were not updating correctly our attention targets. So they were searching for somebody, they killed somebody. They thought that their attention target in that moment was dead, but then they were targeting you. So they thought that you were dead and they were starting to investigate. And those are the type of things that we fix all the time, right? And we want to make it better overall. So Andrew...

Yeah, one of the ones I was looking at recently was that we have certain reaction animations that play before they attack you. And we had this in the scripting language. It was receiving a value and waiting for that value to go up. But because of the specific requirements of the multiplayer system, when you're online, there could be a number of frames before it next checks this value, this alertness level value, and it was going up and not then recognizing it had gone up. So it was forever waiting for this value to go up. And that was causing sometimes these characters to just get stuck in a state where they were like, oh, I'm going to respond. No, nothing's changed. So that took a while to track down, because I think we're narrowing down more and more cases, smaller and smaller issues that we don't see regularly, and that's a really good thing, that we're able to focus more in on those little bugs that happen, like, oh, sometimes it was 1 in 10, now it's 1 in 100. Well, it's smaller and smaller, but we're improving the gameplay each time.

And bringing all the improvements we've done for Squadron as well into the PU also allows us to stress test those behaviors a bit in slightly different environments, right, with more targets, more scenarios where you have, I don't know, the mission with friendly characters that you need to save while there are enemies around and so on. So obviously we also find sometimes some of those different scenarios that we can stress test more.

You said you were excited for blades. My team are very excited for working on creatures. We've already started quite a lot. We've got some work that we've already developed for Squadron 42 that we're bringing forward, and we're expanding on a different range of creatures with lots of different attributes that I can't really talk about too much. Not yet. We're definitely starting with the Quasigrazer, so that's been a fun one, seeing that move. At the moment we've got it jiggling up and down, so we've got to solve that issue. But yeah, it's definitely something that we're working on right now and we're excited to be working on.

What we saw in the demo there is an actual Quasigrazer moving around the planet. It's really the work that we've started, and what you guys have seen live in the video from CitizenCon is an actual creature that we're working on.

Yeah, I think it's safe to say, without me getting in trouble, there are multiple creatures currently in development. We showed the Star Whale and we've shown the Quasigrazer. We've shown those, but there's actually a host of different creatures, both aggressive and not, that are currently in development. When I talked yesterday about things that we would let you guys discover on your own, that's probably one of those. I think unless something changes, we probably won't do a big feature on it. I would rather leave that for people to discover when it goes in. We can cover it, we can look back at it later. People often ask why we cover certain things in ISC and why we don't. We didn't cover the F8 thing; we wanted to let you guys discover that when it happened. We didn't cover Pyro Playground before because, again, we wanted to let you guys discover that as it was happening. I feel like creatures would probably be one of those. I like the idea of people just logging in one day and, what the hell, there's a space cow there or something like that. So we'll see. There's no promise, but I think I'd rather wait on that than cover it in ISC immediately.

So maybe I can start, and then you guys just interrupt me anytime. So I think basically, yes, it does impact us, as everything that we do. Basically, every AI character, especially humans, right, is very much similar; we do share a lot of stuff with the player. So we have a lot of things in common. The difference with AI is that obviously, right now especially, you have AI authoritative on a server, right? So what it means is that server meshing will come in different stages. First of all, we still have the split between the replication layer and the DGS. And then you have clients, right? So what it means is that usually the first step that you will get is basically that every change that the entities that the AI controls will apply is similar to other players. So they will write their own data to the replication layer; clients will read from the replication layer directly. So that is the biggest change that we will get. And in general, all the improvements that you get from the actor code and the actor team, we get it also in a way for free, because anything that the player can do, pretty much we want the AI to do it. So every change that they make from the player perspective also automatically applies to the AI. What I think will be more interesting in the new year with the replication layer is when we will have multiple servers and the way this can be expanded. Let's start just with the basics of multiple servers, similar to what we saw at CitizenCon with the demo from Paul. You will have characters that move across different servers, and this is the big difference between AI characters and player characters, right? Player characters are authoritative when you're a client. You guys play; your brain is the context that always keeps consistency between what you want to do and what you see the player doing, right? But on the AI side, when we move one character from one server to another and its authority changes, the big difference is that you don't only want to replicate the effects of what the guys are doing, but you also want to replicate the context of their decision making. Because if I'm fighting with you, yes, I could restart the behavior, but that means, as a first step, you might just select another character; you might see a bit of discrepancy from what they're trying to do when they switch server. And the main issue is that you as a player should not understand when you switch server. It should be irrelevant, right? So we want to have that type of experience as seamless as possible, like everything in Star Citizen. So this would be the biggest impact that we have, right? So we'll have a lot of servers, AI that might cross servers at any given moment, whatever they're doing, and that needs to keep the consistency between what they decide to do and what they're actually doing on the multiple servers, right? Server to server, obviously, it's a big change that we want to do. I don't know, Diego or Andrew, if you want to add anything there.

One thing I would say is we've been working on this recently. One of the challenges we've got is that, as things are now not all on the same server, they've got to be replicated. And not only that, well, that's server meshing, but also when you're coming back from the replication layer, say if that server's gone down or it's gone out of scope and you're coming back from it, you've got to restore them to the correct state, so that any AI that go up and see a character on that server and then interact with that are still getting the correct information to make decisions about what behavior they want to do. And so we've just been working on that very particular thing for a thing called the observable state, which allows us to say whether a character is dead or unconscious. And we found that because we've now split it up and it's coming back from the replication layer, it's not always getting this information updated, so you have an object that's basically in an unknown state, and then we get bugs because that information is wrong. So that's something we've been working on fixing, to make sure that that process is all done correctly and the information is there, whether it's for server meshing or for the replication layer.

Yeah, I'm imagining, hearing you guys talk about this, the idea you kill somebody and their state becomes dead, you pick up their body and you carry them over, and as you cross to another section, the replication layer brings them over, but now they're back alive.

Or they might perceive them alive, because another thing is that you need to make the state consistent, right? So for example, it could even be that you die, you get revived, but then the AI might think that you're actually still dead, or something like this. And then what will happen is, again, there are some situations where you might perceive it as they are not responding, but maybe it's just caused by the fact that maybe the state is correct in one side of the game, the components, but maybe it didn't get propagated correctly from the initialization order, or, for example, in this case, the knowledge of that state, right? So we are trying to split it so that we get better at the events, and we can read the states better, and we can propagate the events of the states much better, so that things are always consistent.

Yeah, we've been making quite a lot of strides recently, joining up with lots of teams, the audio and dialogue teams, to get more consistent usage of the wildlines across both Squadron 42 and Star Citizen. And very specifically on the point to do with radios, we have quite a few of those scenarios within some of the levels in Squadron 42, but they're mainly scripted, where there's stealth levels where if you get detected by them, or if you kill someone silently, do a stealth takedown, and then they discover the body and you haven't hidden it somewhere, then they'll radio on to their leader, and that changes the flow of the level from stealth to a much more combat-based level. So they've been very scripted so far. We have had quite a few discussions about making that much more systemic and generic, but we haven't got too far on that, but there are definitely some great benefits to doing that, because one thing, for example, is that if you know who your squad mates are, you know who to call out for when, for example, somebody's gone down. You'll notice if they're missing, if they're walking around a level and the response doesn't come back, that kind of stuff, and get that more systemic behavior from some of the stealth sections as well. And I'd like to see that more in Star Citizen as well.

It also becomes important with the organization system. As the organization reputation system gets further developed in Star Citizen, we talked about that a lot with Pyro, there are going to be NPC people at Rough and Ready and stuff like this. As you kill them or attack them, your reputation with them starts to go down. They become more aggressive and stuff. There should, of course, be opportunities where you can assault one in private and nobody finds out. But there should also be situations where they get off a radio message before you kill them and you take the necessary rep hit and stuff like that. So there's all kinds of implementations for that radio transmission ability as far as the PU goes that wouldn't necessarily be necessary in Squadron.

But also, in general, the communication, we do have the communication in terms of feature, right? Because right now, if they find that body, right, they will go investigate, they will call out; even if it's not by radio, they will still call out the other ones. And that calling out is what basically allows the other guys to be attracted by the fact that something happened. Or, for example, we do have hearing friendly fire and stuff like this. And these things also propagate correctly through the audio propagation, which I think we maybe spoke about at a certain point, but basically the audio perception on the AI side now does respect the audio propagation. I don't know, Jared, if you remember if it's already in Star Citizen right now or not, but it's definitely one of the things that we'll carry on or bring in the next releases. And we can really say, these are the rooms, you close the door, the audio doesn't propagate there, so you can kill one enemy in a room that is closed, and maybe even if he screams or something like this, if the environment doesn't allow audio to propagate, then the other ones won't be alerted. And if the door is open, they might hear it, and so on. So I think this is actually really interesting in terms of the type of mechanics and opportunities that this opens up for the players.

Yeah, this is something that we've already worked on for Squadron, definitely surrendering. We definitely need a bit more polish on all of the states that it's got for them. So civilians, people without weapons, should immediately run away and cower and hide. And then if they're a combatant and they run out of ammo, then they will first look for more ammo if there's any available. And after that, they should run away and hide until there's basically no combatants left in the current fight situation. And when that happens, then they can go into this surrender behavior, where you will either be able to do another stealth takedown or restrain them. One of the things is that we haven't actually got some of that flow in Star Citizen, because with the AI at the moment, you have infinite ammo. And the reason for that is because we've got the option to not have infinite ammo, but it does require rebalancing quite a lot of the missions to put in ammo crates so that they've got the right amount of ammo to be able to do that. But it's definitely something that's there.

The loadouts as well for the existing ones, so that's the process that we will go through, right? I think there's also the effect that obviously they will drop the weapons if they surrender, as, I'm not sure who asked the question, but what was mentioned. And basically, what they will also do is, if you let them stay there in surrender and you go far away enough, then they might also try to find back some guns and start fighting. So if there are enemies and you leave them just in the surrender state... You can restrain them, as you said. And then the other NPCs can also unrestrain them if they find them restrained, again, try to revive them. So this is all the flow that we do have, but you don't yet see all of that in Star Citizen per se. It's quite interesting to see when it's going to be there. You guys will enjoy it and will give us feedback.

I think you definitely are right, and I think there's a lot of things there. One is that we are bringing together lots of different game systems, so we're working with all of those things. We're working with the graphics, we're working with animation, we're working with the effects, we're working with the sound design and all of those things. So it's a nexus point for a lot of other people's tech to all make it work. But also you're right that you notice things in gameplay a lot; you don't forgive somebody not doing the right thing a lot more than in a lot of systems. And I think a big part of that is telegraphing what the AI is doing in the right way, making understandable choices. And that's one of the things we've seen with the issues with AI not reacting, in the bugs that we've been fixing recently: not necessarily that they thought they were doing the right behavior, but because it wasn't understandable and readable to the player, it looks wrong, and immediately looks wrong, no matter how clever that behavior might be. And so that's definitely something that we've been working on a lot. And one of the areas we're focusing on is you code your AI for a very known situation, and then designers and level artists and all of these people come up with wonderful ways to test these things, and situations you hadn't imagined when you'd first started writing the code. And so one of the things we've been working on a lot is adding in lots of fallback cases. So, oh, what if I don't have a nav mesh in this particular situation? What should I do instead? What if I have no target, but there's this person who's shooting at me in front of me? And they can react to maybe not necessarily bugs, but other little mishaps in a much more sensible, readable way that's understandable to the player. You're not going to notice so much. And sometimes we go the opposite way, and then they seem to be too efficient, and they can be attacking the player too often, and oh no, they know too much, so you've got to dial it back again. So, yeah, it's a delicate balancing act.

What Andrew is saying there about them being too efficient, that's something that, when we were making the flight AI, I was playing with Yogi from the player experience team, and we were learning how we were playing against each other. And I came up with the prototype, right? And the first prototype that I made, I think my AI just destroyed them all. It was too good. And it's those things that are sometimes hidden, and we keep playing to make sure that it actually feels good, not as good as being a killing machine, but good enough that it's a good challenge.

But I think in addition to that, basically one important thing is that we do feel the pressure of trying to give this experience to the players, right? And I think what's hard in development, this is where reality sometimes comes into place, is that you need to choose sometimes between focusing on the long-term goal or the short-term goal, right? So you know that some bugs might also be things that you might fix later because you have it planned. And obviously, from the way we develop the game and the way we share the game, you often can see much more than what players would usually see in a normal development flow, right? That is, you do it behind closed doors for so long that you only see things when they are working well. So for us as devs, also sometimes there's the frustration of saying, I could have just cleaned this up a bit better, or been focusing more on this other bug or this other experience that Andrew was saying, or the balancing that Diego is also talking about, right? And obviously we do have the great advantage on the other side, that you guys can experience stuff that is not finished and we can get some of the feedback much earlier. And yes, some stuff might already be... but some other stuff it might actually be really good to get that feedback on, right? And the type of changes that we can push based on stuff that we might have not considered. So I think there are advantages and disadvantages as well. But it's definitely good to have this opportunity from our perspective as well.

So in terms of radar, I can speak for the ships, but yes, the AI just uses the same radar component as the one that the player uses in the ship. So depending on the ship that the AI is flying, it has those radar capabilities based on the balance of that ship.

We want to use the same on FPS as well. With characters, obviously the balance is through the traits that we've spoken about and the fact that they do have their loadouts, these items, first of all. So for example, if we give FPS characters the radar, you can also decide from a design perspective if you want them to use it or not. First of all, obviously the ship is a bit special, because ship versus ship, you have to use the radar, but basically the perception system for the AI can be extended with different senses, as we call it. The radar is one sense. And the behavior already has specific nodes that allow them, for example, to ping through the radar. And the other thing that we want to do is to react to being pinged. And also in that case, basically, it depends. First, you will react if you are pinged if you do have a radar that notifies you of being pinged. And we can also say maybe there are some easier missions, or, with the balance of the gameplay flow that we want, we can say, OK, those guys should not react to being pinged, but they should be able to ping, so that we can also use the AI to train, because this is the other part of game mechanics that is important, right? You want to use the AI to also teach mechanics to the player. So you can say, okay, now we make you a mission where the AI can ping you, but you are safe to ping yourself. So they can still kind of learn that mechanic. And there, as with the player, we use the exact same item. So the AI can say, I want to ping very quick, I want to ping very long so that it can be detected. And we can absolutely control this. And what this does is it just updates your perception. So the AI can basically know the snapshot of your position from that. And we don't really cheat on the AI perception, right? Vision, audio, radar sense, and pinging updates, basically.

I think there are several levels of that as well with the AI. One of the levels is, oh, well, they'll just know that they've been pinged, and so suddenly they'll change alertness status and maybe go hunt for you. And another one, the higher-up level, is that they will be able to pinpoint where you are and immediately go to you, like, oh, I've been detected.

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 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.

That's actually the thing. I believe that we had one of the actors who was actually learning about using the weapons. And because they were learning, the performance actually came across as somebody who was learning. So they weren't perfect. And it was, I believe, exactly what we needed.

The more real it is, the more real it feels.

We've definitely got some factions that have combat styles which are different. Some are highly trained with their weapons and some are kind of like amateurs just grabbing their first weapons. So that's definitely something that should come across with our animation style as well.

Without jumping into spoilers, there are multiple factions in Squadron 42 that you'll be squaring up against, and they don't all have the same modus operandi, let's put it that way.

But even in the Star Citizen universe, I think that the world is so large and vast, right, that you would expect that there might be some settlements of people that are less trained than others.

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.

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.