quetoo
quetoo copied to clipboard
jdolan
Bot Improvements
If we can fit these in by 1.0, that'd be cool, but some of it obviously will take much longer than others. This is basically a list of issues with our current bot code and tasks that need to be done on them. If you notice any bugs whilst playing with bots, please comment on this issue so we can verify & add to task list.
- [x] Requires AAS compilation, A*-like pathing procedures, etc.
- [x] Move vision to eyes instead of origin - should fix several issues where bots will try to fire through small windows that they can't even see through
- [ ] API cleanup; better way of fetching entities, etc
- [x] Item reachability check should see if they can walk between themselves and the item. Maybe mark items that we can't reach for a short time as unreachable so they don't continuously try to go back and get it if it's across a drop - similarly, if we're hunting an item for too long (like more than 1 second) mark it as unreachable for a while and move on. This issue is easily visible on the two tiny windows in aerowalk, they continuously try to get items behind them, as well as trying to cross chasms to get items.
- [x] Add back "don't fall off edges" pmove prediction mechanic for wander
- [ ] Enemy weighting: currently they fire with no preference as to who to attack.
- [ ] Combat movement mechanics: they currently just move towards you. Need something better (backing up, strafing, etc).
I think combat movement could be lumped into 3 relatively straightforward buckets:
- For most weapons, except those that can hurt the attacker, just do what they do now.
- For RL, GL, and BFG, try to maintain a distance of, say 256 units?
- When outgunned or at severe health advantage, actually run away.
Thoughts?
Projectile-based weapons also need to lead the target (that's why the weapon has "speed" variable, so it knows how fast the projectile will travel), and rockets should sometimes be aimed at the feet if the player is on the ground. There's a few different interesting things we can do with this.
It already only wants to use RL at med/long range and will prefer lightning gun or shotguns if you get too close, so that's kinda handled.
Ideally, when we have actual navigation files, bots should still wander around the map even when they have a target - they should choose whether or not they should just stay in the same vicinity (pick a different visible area that they can reach without leaving the area basically) and just walk around there, or if it suits their state (eg if they have an SSG & can reach the player easily) they should then just rush the player.
When low health though, yes, they should pick a health spot close to them and head for it whether they're hunting or not. All of these things can work easily with our current funcgoal system, it's just that we don't have navigation so I can't do much without that. An example of this working currently though is that bots will keep walking towards an item they have decided to grab even if they spot an enemy whilst moving towards that target - if they lose the target, they'll even keep staring at the spot the enemy was last seen while wandering around, hoping to catch a glimpse of them again.
For navigation, could we just parse the BSP planes and get a list of "walkable" faces, ones that have enough room above them, face upwards, don't damage, etc.
That's one part of it, yes. I actually started to create a .aas compiler a couple years ago. You can find it in src/tools/quemap/qaas.c. The idea is to find walkable leafs, and mark the portals between those leafs with the kind of player navigation required (walk, jump, fall, etc). Then resolve the leafs in which certain items live, and A* those fuckers. It's a great little computer science assignment for anyone who is interested wink wink.
@Paril Do you want to reference this issue in your AI improvements going forward?
If you want to lead the auto-gen of base nodes from leaves that would be helpful. This is all mostly done, I can update it though.
I'd be happy to take a look at doing that, but I honestly have to wonder if this can be done by either automatically recording nodes if none exist, or by a relatively simple iteration in your code when the nodes are loaded:
const cm_bsp_leaf_t *leaf = bsp_file.leafs;
for (int32_t i = 0; i < bsp_file.num_leafs; i++, leaf++) {
// solid or clip leafs can not be occupied
if (leaf->contents & MASK_BOT_CLIP) {
continue;
}
// all other leafs are, in theory, able to be occupied
vec3_t center = Vec3_Multiply(Vec3_Add(leaf->mins, leaf->maxs), .5f));
if (leaf->contents & CONTENS_MASK_LIQUID) {
// for liquids, drop a node in the center of the leaf
Ai_AddNode(center);
} else {
// for empty or mist leafs, look for a floor to get the Z coordinate
const vec3_t down = Vec3(center.x, center.y, leaf->mins.z - PM_GROUND_DIST);
const cm_trace_t trace = Cm_Trace(center, down, Vec3_Zero(), Vec3_Zero(), MASK_BOT_CLIP);
if (trace.fraction == 1.f || trace.plane.normal.z < PM_GROUND_NORMAL) {
// this leaf does not have a floor, skip it
continue;
}
Ai_AddNode(Vec3_Add(trace.end, Vec3(0.f, 0.f, 32.f));
}
}
This would give you nodes. Establishing paths between them could be done by sorting all other nodes by distance, and then taking the first neighbor to pass a trace. What do you think?
By either automatically recording nodes, or generating some plausible default ones, we keep all of this logic right in the AI lib.
Btw, you could use a loop like above to either create the nodes, or to simply count the number of inhabitable leafs to use as your heuristic for auto-recording saturation. In other words, if creating the nodes as above is too difficult, maybe such a loop is still useful for determining how many nodes should be auto-recorded.
We don't have access to the BSP nodes in game or AI, so we'd have to figure out what to do here. I don't really want to expose the AI all the way back to the server.
In that case we should just add a line to Quemap to include the node files in the pk3 archive.