Forums » Bugs
Bots are not affected by occlusion
They shouldn't have the ability to see things that we can't, so why do they magically see through objects?
They aren't affected by the shortened radar range in storms either.
Some of them at least are affected by occlusion. I've hid behind asteroids in the conquerable station sectors and the turrets stop shooting. The guards still sneak around the side of the asteroid to come kill you though.
Some of them at least are affected by occlusion. I've hid behind asteroids in the conquerable station sectors and the turrets stop shooting. The guards still sneak around the side of the asteroid to come kill you though.
They aren't affected by a whole shit ton of things -- these are only some of them.
Its not a bug, when occlusion was introduced the devs said bots would not be affected due to a design decision.
It is a non-trivial computational load to calculate occlusion. We're casting rays at targets frequently to determine visibility. On the client, we thread this and it's spread across the user's hardware. On the server, it's all.. on the server.. times a zillion bots. In a zillion sectors.
Open-world games don't lend themselves to some of the efficient occlusion-calculation shortcuts that are possible in closed-world FPS's. So, anyway, for the moment, no, bots are not impacted by occlusion.
I do want to make them impacted by fog/radar-range changes, that shouldn't be too much of a load increase. But occlusion per-bot-per-target times N bots times N sectors is.. uhh.. scary.
Open-world games don't lend themselves to some of the efficient occlusion-calculation shortcuts that are possible in closed-world FPS's. So, anyway, for the moment, no, bots are not impacted by occlusion.
I do want to make them impacted by fog/radar-range changes, that shouldn't be too much of a load increase. But occlusion per-bot-per-target times N bots times N sectors is.. uhh.. scary.
You could exclude NPCs from the occlusion check of other NPCs to cut down on calculations, since they're all too dumb to care if hiding behind an asteroid works or not.
I was already assuming that. Basically, every sector that's even online at all, has a person in it. And if it has a person in it, every bot within radar distance would need to do occlusion checks. That can be quite a few bots. If they're each updating occlusion often enough to be useful (every second?), that's a lot of raycasting. Even with just one person.
Now, we might be able to winnow things down via bot behaviour, basically saying that most of them "aren't paying attention" if they're otherwise engaged, like they have a target, or they're mining, or whatever, which then diminishes their awareness to a much shorter distance than radar-range. But still, it ends up being a big jump in load in the highest-load situations: Border Skirmish and Hive Skirmish. There you have large numbers of aggressive bots searching for targets. Now.. maybe we could exclude pure-combat scenarios, since I think people mostly want this in other situations, but still, it ends up being a lot of if/then specialty-case handling and workarounds to make something like this scale.
We have a lot of scalability concerns as it is. There may be some faster-path possible using our octree and sweep & prune systems, along with a really optimal check (although it's already pretty optimal), but all of that is a lot of time and engineering. So, don't expect to see bot-awareness take occlusion into account in the immediate future. Not unless we suddenly have unlimited CPU availability on the server.
Now, more basic checks, like fog-distance limiting radar range? That's a lot simpler. That I would like to see added in the near future.
Now, we might be able to winnow things down via bot behaviour, basically saying that most of them "aren't paying attention" if they're otherwise engaged, like they have a target, or they're mining, or whatever, which then diminishes their awareness to a much shorter distance than radar-range. But still, it ends up being a big jump in load in the highest-load situations: Border Skirmish and Hive Skirmish. There you have large numbers of aggressive bots searching for targets. Now.. maybe we could exclude pure-combat scenarios, since I think people mostly want this in other situations, but still, it ends up being a lot of if/then specialty-case handling and workarounds to make something like this scale.
We have a lot of scalability concerns as it is. There may be some faster-path possible using our octree and sweep & prune systems, along with a really optimal check (although it's already pretty optimal), but all of that is a lot of time and engineering. So, don't expect to see bot-awareness take occlusion into account in the immediate future. Not unless we suddenly have unlimited CPU availability on the server.
Now, more basic checks, like fog-distance limiting radar range? That's a lot simpler. That I would like to see added in the near future.
I guess really you'd only have to have the NPC check against their current target, not even every other player.
You guys should do a smaller-scale crowdfunding drive to buy a faster game server so that we can have nice things. 2004 wants it's first generation AMD Opterons back. :P
You guys should do a smaller-scale crowdfunding drive to buy a faster game server so that we can have nice things. 2004 wants it's first generation AMD Opterons back. :P
I guess really you'd only have to have the NPC check against their current target, not even every other player.
Then you're only allowing occlusion to block the vision of bots who already have you as a target. But how does the bot get you as a target in the first place? Their visibility to you had to be checked at some point. Ultimately, people want to be able to cautiously fly through an asteroid field and be able to avoid and escape the NPCs who see them. But that is only possible if every NPC is checking their visibility against you frequently, to see whether they should be "noticing" your existence and targeting you.
You guys should do a smaller-scale crowdfunding drive to buy a faster game server so that we can have nice things. 2004 wants it's first generation AMD Opterons back. :P
Heh, no, actually we're trying to own as little hardware as possible. Hardware is fixed (there's never enough of it for an Apple promo, or you overspend/overbuild and basically waste most of it), and you have to maintain it when it breaks. Elastic solutions (AWS being the most famous) are far better long-term options. And if you are using an elastic solution, it is of great value to minimize your server-side overhead. Which is the point I've been making.
In any case, in answer to the OP: No, bots are not affected by occlusion. This is not likely to change in the immediate future.
Then you're only allowing occlusion to block the vision of bots who already have you as a target. But how does the bot get you as a target in the first place? Their visibility to you had to be checked at some point. Ultimately, people want to be able to cautiously fly through an asteroid field and be able to avoid and escape the NPCs who see them. But that is only possible if every NPC is checking their visibility against you frequently, to see whether they should be "noticing" your existence and targeting you.
You guys should do a smaller-scale crowdfunding drive to buy a faster game server so that we can have nice things. 2004 wants it's first generation AMD Opterons back. :P
Heh, no, actually we're trying to own as little hardware as possible. Hardware is fixed (there's never enough of it for an Apple promo, or you overspend/overbuild and basically waste most of it), and you have to maintain it when it breaks. Elastic solutions (AWS being the most famous) are far better long-term options. And if you are using an elastic solution, it is of great value to minimize your server-side overhead. Which is the point I've been making.
In any case, in answer to the OP: No, bots are not affected by occlusion. This is not likely to change in the immediate future.
While as you said it's unlikely to change in the immediate future, the technical details have me intrigued about the current occlusion implementation.
With the current occlusion mechanic are you checking for complete occlusion behind another object before removing the occluded object from the radar (ie if even a small point is visible it shows on radar). Assuming this is the case, I can see how that could get to be a bit hairy on the computation side of things. It certainly makes sense from a PvP perspective that we'd want to have occlusion as accurate as possible.
I imagine certain compromises could be made with regards to NPCs (eg. only ray cast to the center of a player object). This is something I've often noticed in other games. When hiding behind a wall (sometimes only partially) an NPC would ignore you, but depending on how fast you were able to move and your timing based on the server clock, it could be possible to completely run past an NPC without triggering aggro (aggression). This is something that I noticed you touched on, Incarnate, in your second post.
Even were occlusion to be added in it's most basic form, I can see there being a number of elements of the aggression mechanics which would also need to be changed.
PassiveVigilanceRate - rate at which an NPC checks Line of Sight (LoS) to potential targets when they are passive, based on NPC role/activity/intelligence (eg. collectors 5 seconds, assaults 1 seconds, guardians 2 seconds)
AggroVigilanceRate - rate at which an NPC rechecks LoS when they have a target, only check on current target or progressively work down from the top of the hate list (if one exists) (eg. 1 second)
LostTargetTimeout - how long the current target should be occluded before a target is lost
With the current occlusion mechanic are you checking for complete occlusion behind another object before removing the occluded object from the radar (ie if even a small point is visible it shows on radar). Assuming this is the case, I can see how that could get to be a bit hairy on the computation side of things. It certainly makes sense from a PvP perspective that we'd want to have occlusion as accurate as possible.
I imagine certain compromises could be made with regards to NPCs (eg. only ray cast to the center of a player object). This is something I've often noticed in other games. When hiding behind a wall (sometimes only partially) an NPC would ignore you, but depending on how fast you were able to move and your timing based on the server clock, it could be possible to completely run past an NPC without triggering aggro (aggression). This is something that I noticed you touched on, Incarnate, in your second post.
Even were occlusion to be added in it's most basic form, I can see there being a number of elements of the aggression mechanics which would also need to be changed.
PassiveVigilanceRate - rate at which an NPC checks Line of Sight (LoS) to potential targets when they are passive, based on NPC role/activity/intelligence (eg. collectors 5 seconds, assaults 1 seconds, guardians 2 seconds)
AggroVigilanceRate - rate at which an NPC rechecks LoS when they have a target, only check on current target or progressively work down from the top of the hate list (if one exists) (eg. 1 second)
LostTargetTimeout - how long the current target should be occluded before a target is lost
And if you are using an elastic solution, it is of great value to minimize your server-side overhead.
So basically, no computationally-intensive anything server-side unless something drastic happens. That makes a lot of sense... except from a "I want fun and interesting gameplay" perspective. Please keep it in mind if things change.
So basically, no computationally-intensive anything server-side unless something drastic happens. That makes a lot of sense... except from a "I want fun and interesting gameplay" perspective. Please keep it in mind if things change.