Navigation using AABB

[Neoptolemus]

Ok :-) I'll post some decent footage tonight of them in action. I was quite pleased when a marine missed his jump and fell down behind some railings. He crouched and made his way through some vents, jumped over another set of railings to get back on the path and quickly reached his destination

[Neoptolemus]

https://youtu.be/bl4BsC7cvhM

A new update. I have been working hard on perfecting the steering behaviours and I think I've got it pretty solid. Bots now rarely get stuck, and if they do they can usually get out of it pretty quickly. Here you can see the skulk handling more complex paths without a hitch. The way it handles vents in particular is really slick.

The movement is still a little wobbly in places, this is partly because the bot tries to stick more closely to the precise route. It does this by checking its distance from the path and if it's too high, it corrects and moves closer to it. I am being quite strict right now to avoid the bot getting caught on obstacles when navigating narrow passages, but some more tweaking will find the right balance

Next up, I want to handle button-operated doors. This will require adding a "detour" feature, so you can calculate a path and then, if it crosses a button-operated door, add a detour to where the button is. This hopefully will not be too difficult!

[The Storm]

Little "wobbly" is really mildly said at least from what I saw on the video. The bot is moving like a cyborg with a stick.

No offense, but I think you should perfect the movement before starting to play with buttons.

[Neoptolemus]

Bah you're right. I think I've spent too much time tweaking it so I stopped noticing how bad it looked. I'll get there

[Neoptolemus]

A progress update. I have made some tweaks to the movement code so the bot is better at determining if it is straying from the path and how strictly it needs to do so. This has fixed a lot of the jittery movement seen in the previous video.

I have also done some work on auxiliary functions which will be important later, such as being able to trace a line through navigation sectors for things like reachability. This will be needed for important additions like anti-aliasing on paths to further smooth them and have the bot move in a more human-like manner with fewer 90-degree "kinks" in the route taken.

Off the back of this, I have added new jump connections to allow the bot to determine if it can reach a distant position more directly by jumping. This ultimately allows it to jump over gaps and take shortcuts it would otherwise have to walk the long way to reach. Here is an example of it in action:




And here is another example in cs_italy:




It is not quite fit for purpose yet as the bots are not smart enough to figure out that they need to have the correct forward momentum before attempting a jump. If they are approaching a jump from the wrong angle they'll just leap off in that direction, usually missing the jump miserably. This wasn't a problem when the only jumping was up onto a crate or step, but when leaping across a gap of course it matters.

[The Storm]

Nice work. About the jumping all the Podbot derivatives including the original Podbot do have hardcoded the best jump technique that is possible to have and this way they always get to the right spot. If you want you can checkout some of their code about that.

[Neoptolemus]

Yes I remember the Podbots were really accurate with their jumps. I'll take a look for certain

I seem to remember in earlier version of Podbots (circa 2004 when I used to play them all the time) that they could do inhuman acrobatics by running in one direction and immediately leaping at full speed in a different direction without having to stop and take a run-up. Did this get sorted or was it left as it was? Apologies if this was never the case, my memory is a little hazy given it was 13 years ago (ouch!).

[The Storm]

Well, I also don't remember.

[SamPlay]

hi!
I am working on navigation system too, though with a different approach, so I am following this thread with interest.

I coded a bot from Podbot in the past;
As regards Podbot, as far as I remember, bot jumps were recorded from actual player jumps; the velocity at jump start is stored with the jump start navigation point; when the bot triggers the jump, the bot code forces its velocity to the stored one, which
- generates irrealistic ( violent ) direction changes if the bot direction does not match the player one at the time of recording.
- provides the right vertical and horizontal velocity components for a successful jump, though the bot velocity just before the forced setting might not have been appropriate ( this showed as irrealistic 'kicks' sometimes).
Hope this helps.

[Neoptolemus]

Originally Posted by SamPlay

hi!
I am working on navigation system too, though with a different approach, so I am following this thread with interest.

I coded a bot from Podbot in the past;
As regards Podbot, as far as I remember, bot jumps were recorded from actual player jumps; the velocity at jump start is stored with the jump start navigation point; when the bot triggers the jump, the bot code forces its velocity to the stored one, which
- generates irrealistic ( violent ) direction changes if the bot direction does not match the player one at the time of recording.
- provides the right vertical and horizontal velocity components for a successful jump, though the bot velocity just before the forced setting might not have been appropriate ( this showed as irrealistic 'kicks' sometimes).
Hope this helps.

Hi SamPlay, thanks for the clarification. Now you mention the recorded jumps I do remember reading about those in some patch notes years ago, and it sounds like my memory of unrealistic velocity changes during jumps was correct.

I would be interested to hear about your navigation system if you're ready to share any details. Mine seems to work well in practice but it needs a lot of optimisation as it is quite inefficient in terms of the number of sectors generated and so on right now. Then again this machine is so old that even Half-Life struggles to run sometimes (seriously, switching on the flashlight sometimes drops the frame rate below 20!). I think it's starting to fail since it's a 2009 i3 (2nd generation) and should have no problem with HL at all.

In the meantime, I am experimenting with a different navigation approach whereby instead of generating a fixed set of waypoints from the sector system, it instead returns the sectors themselves and the bot navigates through them dynamically.

This has some advantages because the bot maintains spatial awareness, so dynamic obstacles such as moving platforms or other players can be taken into account on-the-fly without having to regenerate sections of the path. It also means its easier for the bot to determine if and how it can get back on the path if it falls, misses a jump or gets knocked around.

Will hopefully have some good results soon