Better hearing / path finding experiment

Discuss coding questions, pull requests, and implementation details.
Post Reply
User avatar
pango
Posts: 3431
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

Better hearing / path finding experiment

Post by pango »

Hi all,

I toyed with the idea of improving enemies hearing, since it's currently very limited (enemies can hear thru doors, but only in straight line). I implemented some path finding algorithm (weighted A*), probably in a very naive way, but it's enough to give enemies better hearing, and indirectly help them with path finding too, since when they can't see their target they rely on hearing, that will direct them thru openings.
Don't expect huge improvements, but still enough for some surprises.

Main issue is performance, it can do a little too many raycasts and slow down the framerate at times.
If you have ideas how to do it better (caching, lessen memory allocations, or totally different approaches...) please share :)
improved-hearing branch
Mastodon: @pango@fosstodon.org
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart

User avatar
King of Worms
Posts: 4762
Joined: Mon Oct 17, 2016 11:18 pm
Location: Scourg Barrow (CZ)
Contact:

Re: Better hearing / path finding experiment

Post by King of Worms »

Hey, this looks interesting :) Glad to see you at it. Will it be possible to download it as a mod laters?

User avatar
pango
Posts: 3431
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

Re: Better hearing / path finding experiment

Post by pango »

Hi King of Worms,

Well, with this experiment I'm also trying to add some space-handling tools, because the way DFU spawns enemies is not as good as classic Daggerfall, and that will probably be useful to fix that.
In short, if it works, it'll be useful inside DFU instead of as a mod.

If it had to become a mod as-is, it'd still require some modification to DFU (I needed to adjust the signature of the CanHearTarget delegate so it can return in what direction the target was heard). I don't know if anybody modded that delegate yet, hopefully that's still okay to change that.

In the meantime, I can probably build executables with that experimental change for people to try it...
Mastodon: @pango@fosstodon.org
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart

User avatar
DunnyOfPenwick
Posts: 285
Joined: Wed Apr 14, 2021 1:58 am
Location: Southeast US

Re: Better hearing / path finding experiment

Post by DunnyOfPenwick »

I'm thinking maybe just keep track of where the doors are. If a nearby action door is in line-of-sight of both the entity and its target, then they can move to the door first. If not, they can just stand there to avoid walking into walls.

I added a hook in EnemyMotor to replace the TakeAction() logic; this is used by Monster-University to handle advanced enemy spellcasting. I was planning on adding 'fidget' movement at some point. An enemy with no target might wander around. That might require additional modifications to EnemyMotor.

User avatar
pango
Posts: 3431
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

Re: Better hearing / path finding experiment

Post by pango »

DunnyOfPenwick wrote: Sun Sep 01, 2024 2:49 pm If a nearby action door is in line-of-sight of both the entity and its target, then they can move to the door first.
Interesting inexpensive approach, however it fixes a specific problem in dungeons context, I'm trying something more generic...


Here's development build with latest modifications (Windows, Linux):
https://mega.nz/folder/6rhmUQoC#6YIItZBohcalTgN4iiXMuw

Sadly, it can crawl even more than the first version. I tried to put the results of raycast analysis into a cache and be liberal with reading of of cache content, but it turns out Dictionary<Vector3Int, Object> is not so fast that it does not eventually appear.
I'll probably try another datastructure (Dictionary<Vector3Int,struct> is significantly faster already), or as a last resort try to be smarter ;)

Be sure to download 282c339 builds that are significantly faster
Mastodon: @pango@fosstodon.org
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart

User avatar
pango
Posts: 3431
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

Re: Better hearing / path finding experiment

Post by pango »

I pushed a new build 48a3205 with lots of improvements (most importantly, I made the A* algorithm incremental, so it can take more than one frame to complete, and not redo work either).
I still have some ideas to make the space cache more compact and faster to access than a Dictionary<Vector3Int,struct containing two ints>, maybe later.
Sources: https://github.com/Interkarma/daggerfal ... earing-dev

Please give it a try!

PS I'm seeing some amount of raycasts tunneling thru walls, reminds me of the problems of clicking on dungeon entrance that would just get thru when attempted from specific positions. Something's fishy.
Mastodon: @pango@fosstodon.org
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart

User avatar
pango
Posts: 3431
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

Re: Better hearing / path finding experiment

Post by pango »

New build 2057ed8, with a focus on improving space information caching performance; I'm storing data about a cell on 32bits instead of 2x64bits, in a 2-levels 3D arrays (smaller one being currently 16x16x16 cells, largest one being resized as needed).
Mastodon: @pango@fosstodon.org
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart

User avatar
pango
Posts: 3431
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

Re: Better hearing / path finding experiment

Post by pango »

Mmmh, arrays may have excellent average performance, but resizing generates a lot of micro-stuttering.
Either I'll be back to a Dictionary for the root datastructure (with a extra one-element cache I can lower Dictionary lookups by > 75% with 16x16x16 lower cubes), or I'll have to know space bounds in advance to never reallocate arrays...)
Worse case performance optimization is tough!

Update: new build 85b2cfe with the first approach mentioned above, that stutters a lot less!
Mastodon: @pango@fosstodon.org
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart

User avatar
pango
Posts: 3431
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

Re: Better hearing / path finding experiment

Post by pango »

Still working on this, just released 7938c21, that runs smoothly on my gear.
I'm using one limit for the number of raycast that can be sent by frame, and the number of cycles that can be computed by frame (because to get a consistent framerate there has to be a limit).
If it does not run smoothly on your computer, the limits are exposed in the settings.ini:

Code: Select all

[Experimental]
HearingMaxCyclesPerFrame = 2000
HearingMaxRaycastsPerFrame = 25
Setting either to 0 disables the feature.
Anyway, that makes the game more tactical. And if you always thought it'd be cool if you could be attacked by groups of monsters in dungeons, well, try this build!
Mastodon: @pango@fosstodon.org
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart

Post Reply