Developers show AI debug views of perception and awareness, TPS environment queries, and nav mesh link and tag costs. They also cover hazard avoidance by archetype, trolley and box-stacking slots, ammo handling, and CrimeStats. The Apollo editor tool and buddy AI medics also come up.
TL;DRFrancesco Roccucci says the different colours carry information such as friendliness and whether the last known position came from sight or audio, while the centre shows the last vision update, tied to a scheduler that spreads updates out.
So there are different ones. So there's some information related, for example, to whether they're friendly, whether they're not, whether they're enemies, that different type of information, like the last position. Some colors come if the last position comes from visual information or from audio information, radar and stuff like this. But the other thing that you see here is that there is this information at the center that also tells you when the last update from vision was, for example, because we try to be distributed. In this case there are four guys, so it's not a big deal, but when we have 2,000 characters in PU, we also try to distribute the updates a bit better, while still getting them. Because, for example, one thing we changed some time ago was about when we would get perception updates based on the frame rate of the server. This one now is more with the entity system component. We could expose how many updates we could get between the different updates. But now with this, what we call the AI Scheduler, we can specify better the time frame in which we try to get this update, and we still try to distribute. So, of course, if the frame rate is too low, it still takes a little bit of time for them to all get updated, but not as much as it was before. So there are lots of different priorities based on the guys that are close to you and the ones that are in a fight and something like this.
TL;DRFrancesco Roccucci cannot say for certain why one character stayed put, suspecting a bug, a failed behaviour or the timing of distributed environment queries, and notes perception builds up before enemies react.
Yes, so there is. I see three are going, doing different things. Why is that one staying? That one specifically, I cannot tell you right now, but I suspect that this is about the timing that we use for the TPS query. So what is a TPS query? A TPS query is a query in the environment. Just to give you some context, I don't remember if in this video they were running the exact combat behavior or if they were just running a test behavior that Andrea made for this specific video. I also don't remember exactly when this video is from, because this is quite an old one.
It could also have been just a bug there for that guy. But basically, in theory, what we do is distribute the query requests for what they should do. And also not everybody can actually try to move, based on different traits. One thing that you see here is, first of all, the one that you were describing: when they perceive it, they have a bar on top, right? So the perception still goes through the new changes we're doing for Squadron where, based on the intensity of the stimulus, the bar goes up and they only recognize the target when the bar is full, through the different states. So they have different reactions, right? They can have, 'Hmm, what was that?' Or, 'Oh, let me go investigate,' or 'Let's go full in combat,' when it's ready to go full in combat. And then, of course, it scales down, but that's less important once they are already in combat.
That guy, I suspect that there was some failure in his behavior. That's my suspicion. And then he ends up going into the tactics where he's actually trying to move and position himself where he can see it. This is probably why he's not moving. It's just my suspicion.
The funny part is we could actually do it, because of traits, and those navigation links have actual information about which type of variations they are. We can even add different costs. So maybe if somebody is afraid of using the elevator and there is a stair or a ramp, they might prefer the ramp to using the elevator. So we can actually set up those things.
TL;DRFrancesco Roccucci confirms navigation cost is distance weighted by extra values such as hazards, which designers can mark up manually for static features, with the aim of extracting this automatically from the environment.
Exactly, exactly. The cost in pathfinding is usually a combination of the actual distance they need to pass through, but then the distance gets weighted based on additional values. In this case, you can see some more of the debug examples, where the AI can pass through corridors with simulated hazards. But we have use cases for this for multiple things. One can be, for example, imagine you want to have a pedestrian that goes on the sidewalk, and they try not to be on the road unless they really have to, and they might cross only at the crossroads. So you can actually mark up this environment. We also want to make it completely automatic, so that we can really do that extraction of features and information from the environment in an automatic way. This is the static one. This always allows designers to manually place this information and mark it up. For example, there is a bonfire on PU, whatever, and it will never turn off, right? It's always there. We can just mark it up and say it is a bit more costly, for example.
TL;DRFrancesco Roccucci confirms AI can still enter dangerous areas if their goal requires it, and says the next sprint should add cost modifiers, including ones so high the pathfinder treats an area as a no-go.
Exactly. So this is an example, right? If, for example, you tell the AI to go inside an environment that is dangerous, they can still go. You can see it here: he's still entering the environment because that's his goal, but he will try to avoid it as long as he can, and then he goes in. Basically, what we want to add here in the next sprint is the same kind of tag cost modifiers that we use for navigation links. So we can tag them with the intention you are describing, but also say that it's not just the cost that gets influenced: some costs are so high that they basically cause a blockage. Because the problem with making the cost too high is that we eventually saturate the cost, right? So then it has less impact. So in some situations it's like, I really don't want to go through at all. I'm a civilian, I don't have anything that can protect me, I should never go inside the fire. And then we can make that happen, right? So the pathfinding understands that that is really a no-go and it needs to find another path if it can. Or it completely fails, and then the behavior can handle it.
Because it's dynamic, if the player sets fires, it creates new areas that cost more, which the AI will avoid. And if the player extinguishes the fire, puts the fire out, the cost of the area goes back down.
For example, imagine a mission where you need to save somebody from a building on fire. You have the guy that tries to pass through, but the pathfinder says that he can't. So he will always know that he's trying to escape or follow you, right? But he can't. And then we can react, saying, 'Hey, you need to save me. You need to put out the fire before I can come with you.' And then you can put it out, and he will dynamically find the path and follow you, basically. This is all stuff that we will be able to do with this tech.
TL;DRFrancesco Roccucci explains the taller cylinders are alignment slots where an NPC stands to operate on the object, the smaller is the animation start position, and red means reserved while grey means disabled.
So there are two things. The taller one is what we call alignment slots. That's where the NPC needs to be to perform a specific operation on the object in that location. And the small one is the enter position. That is where the actual animation starts, to arrive at the location of the alignment slot. And when it becomes red, it's because it's reserved and in use at that moment, basically.
Right now you can stack three boxes one on top of the other, basically, with animations that look very, very nice, right? You can already see the weight of the box and how they do it. They're also very careful with their back, trying to stack it in the proper way so they don't get hurt. I think there is a lot of tech in this one, also enabling and disabling usable slots automatically. For example, in this case, when he's pushing the trolley, you automatically disable the ability of somebody else to go and pick up a box, right? So that somebody can't take a box from the trolley that you are moving around. And you can also have multiple people loading at the same time and only one pushing the trolley. So pushing the trolley disables the ability to load boxes into it. That is why they're gray, for example. These are gray because they are disabled at that moment. And in this case he's taking it, right? So it will be disabled while he's taking it, so somebody cannot move the trolley while you are already taking a box.
I think there will also be a bit of support that we need to do for the tractor beam eventually there. Because I think there will be a lot of bigger crates that they will not really be able to grab, at least in the early iterations. But these are very physical interactions with the world that our system allows. And it's really interesting from my perspective, at least.
TL;DRFrancesco Roccucci says live differs because new work reaches the live stream in stages, depends on other departments, is tuned badly for low-frame-rate servers, and is prioritised against unblocking development, but they want everyone to experience the behaviours.
It's a combination of things. First of all, I think we have a lot of streams right now, right? Maybe not a lot, but we have a few streams. And whenever we stabilize something, not all the new changes go into that stream immediately. So, for example, in 3.18 you have some of this stuff, and this is where, for example, people see very high accuracy, because not all the accuracy work is in there yet. For example, we don't have the mercy time. We don't yet have the buildup of accuracy over time in 3.18. Some of the balancing needs to... One thing I'm always saying is that it's very hard to balance the AI for a server that runs at 30 frames per second and one at a really low frame rate. So sometimes some of those values try to compensate for the low frame rate, but then they don't work very well at 30 or 25 frames per second. That is where people also see that the accuracy is very high. It's to try to help in some situations, but of course, in the long run, that's not what we want. Some of these behaviors also come with integrations, because we have many integrations from the streams we work on into what we call Game Dev, and then from Game Dev it goes into the live stream. Whenever we can, we try, of course, to integrate as quickly as possible, but some of those behaviors might depend on other departments' work as well. For example, changes to the actor state machine or how a specific state works, or animations that, as I've shown you, might still be white box, right? And those are not yet ready to be in the live release. So we cannot enable all those behaviors. I think there have been some videos I've seen from PU, for example, of reacting to dead bodies, where we were using some of the white box animations in PU. This is one case where we usually disable these behaviors, especially if they were wrongly enabled by our integration and so on. But the idea is that we want to enable them only once all the directors involved in the feature are happy with it. I think this is also a nice preview, but everybody involved wants to have their work shown as well as possible. And then, of course, sometimes there are also bugs that we need to fix. One of the things I want to see is how we can speed up the reaction time a bit, also on low frame rate servers, so that we can give our players a better experience. Because we see this large difference in experience between people who play on a high frame rate server and on a low frame rate server.
You see a dramatic difference in the capabilities of the AI, especially during Siege of Orison and when you jump into a fresh server. You jump into a fresh server in Siege of Orison and it's devastating. Super deadly.
We really want to have a more balanced experience. It's not that we don't want to, but it's a little bit about priority. Sometimes some of those features need to happen first in regular development, because you unblock other people to prototype their missions, prototype their levels, right? And it's not that the other part isn't important; the live experience is important. But sometimes you need to make a harsh decision. Do you want to unblock those guys? Do you want to block these other guys? With the resources you have, you need to decide how to allocate them, right, for the greater good. But we are working hard to make sure that everybody can experience those behaviors, because this is what we want you guys to play with and give us feedback about.
TL;DRFrancesco Roccucci says behaviours check for required items and can restock them, for example through other NPCs or usables, and state is kept consistent across interruptions and server transitions by building behaviours with proper state transitions.
So we have different ways of doing that, of course. Let's say you have the routine behavior of a janitor. A lot of our behaviors, of course, make sure that you need to have specific things to perform the operation, so you can check what you have. Let's say combat starts, right? Then the janitor needs to react, so he drops his mop, his broomstick or his bucket, whatever. Then we always need to make sure that, the same way as if the janitor started from scratch, he needs to be able to pick up those things, or he cannot perform specific operations. So of course, if the player steals all the broomsticks in the environment, well, he won't be able to get one, but we can also always allow some other specific AI to come from a spawn closet and bring back those things, or have specific usables that can still provide the NPCs with the objects they need, or let them perform specific behaviors where they restock the objects they require before they can do the other behaviors. And then the other part is, of course, making sure of their state. For us, there are different parts. It's not just the player influencing the behavior. Eventually it could be, for example, an NPC transitioning from one server to another, because maybe it's performing its duty on your ship, and in that case your ship can change server. And we also need to make sure that that consistency is propagated for its behavior. So a lot of it is building those behaviors in the right way and allowing the transition between the different states, from what you need to what you can perform, basically.
They could, and they could also give CrimeStats. This is one thing that we want to do as well, right? So if you bother civilians too much, they could call the police, and that might trigger CrimeStats for you. Or maybe the guards or policemen can actually have specific... We already have that with spaceship control. I think we have the checks that some spaceships sometimes do on the cargo you carry around, and they can give you CrimeStats. And then we have, for example, the thief behavior in the plan. So maybe you can actually make sure that it gets triggered, it's their crime, and then the police react to them committing the crime.
TL;DRFrancesco Roccucci says an AI out of ammo first switches to a sidearm, then tries to survive by running or staying in cover while searching for ammo or weapons to pick up from racks, bodies or the ground.
So we have different things. When you run out of ammunition, you first try to switch to your sidearm, because you might have a sidearm or a secondary weapon that you can use. And then, if you cannot do anything, basically, they try to survive, right? So they can try to run, stay in cover, and continuously search for a location where they can loot ammo. This always goes through the slotting functionality that we have. So weapons can be found on the ground, and you can pick them up. We now have this functionality where you can pick up objects that are on the ground, as you've seen with the healer. The animation was blocked out, of course, so it's not correctly positioned, but basically they can go next to a usable and pick up something that is not perfectly aligned. They can take it from different locations. Maybe it's a weapon rack: they can go to the weapon rack and grab a weapon. And they can loot bodies, so they can grab weapons or ammo from bodies, or magazines that might be in a crate or on the ground. So basically they have a flow where they search for something that is in a good position, not too close to targets and stuff like this. And then they can grab it, reload, use the new weapon and switch to it. I hope that answers the question.
TL;DRFrancesco Roccucci says Apollo is still Subsumption, an internal editor-embedded tool that references level data directly, streamlines creating missions and platforms, and adds features like a combined mission graph.
Yeah, so basically it's always Subsumption, but we have two different tools. One is an internal tool, embedded in our editor; maybe we can show it in one session. What that means is we want to be able to reference things directly in the levels, and with the external tool we couldn't do it. So we always had a bit of additional information, the platforms, that were supposed to expose information to the external tool. This one is basically meant to streamline the creation of Subsumption data a little bit. So you can create activities and missions in the internal tool. You can create platforms. And the idea is that all the internal data gets automatically propagated to the tool, without us necessarily having to expose it to the external tool and then use the external tool to do these operations. Apollo also includes some other features that the external tool didn't have, for example the editing of the master graph that Fadi and Michael have been working on. Michael and Fadi are our programmers who focus a lot on tools and systems. We also have, for example, a different view of our missions: in the external tool you have one graph for each logic, and now we have a large graph for the missions where you can see the different blocks. You can collapse them, and it automatically understands what you're linking to. So you can still create different files that people work on at the same time, but it's a little bit more streamlined. You have the full picture of your mission in there. But basically, it's our internal Subsumption tool, and it's meant to grow into giving us more power for editing missions, for example. One thing that we want to do in the future is object containers that can automatically include missions, so we can actually reference data directly from the level.
So yes. If you have friendly NPCs that are meant to support you, what we call buddy AI, that's one of the things we're working on. And it's exactly that: if he knows that you are his friend and you are dead, then he might either use his own MedPen or find a MedPen in the environment, which might actually be attached to you. So he will loot you, take your MedPen and use it on you to revive you. That's already technically possible. It's the behavior that we now want to work on.