четверг, 24 декабря 2009 г.

First horde tests

Spent day for implementing steering behaviors for horde.


Recast navigation + avoid nearest neighbor (with prediction, OpenSteer style) + avoid near walls



Recast navigation + avoid nearest neighbor (with prediction, OpenSteer style) + avoid walls only after collision + avoid dynamic obstacles


It needs time to update nav mesh (usually nav mesh updated with 0.5 sec intervals), so sometimes bots can go throw obstacle. Maybe for moving obstacles I need to use same steering behavior as for another bots.

Does it look natural? Or need some enhancements?

2 комментария:

  1. Hi,

    I've just implemented the same tile method (inspired by you) - building in seperate thread. I chuck requests on a queue process them without delay. Why have a delay when it's in a different thread?

    I invalidate all pathed routes if the mesh changes.

    If you implement too many combined behaviours ie avoid nav edges and other NPC's and obstacles you'll find you might get a dithering effect.

    Chris

    ОтветитьУдалить
  2. Hi, we are doing same things same time, lets share results ))

    I made it with delay to save resources. Also, in last tests, I removed avoiding of nearest walls, apply the repulse force only if raycast() returns collision. Still have problems with corners sometimes...

    Intersting idea about invalidation... maybe we need to check correctness of the path after nav mesh updating - check changed tiles etc.

    I update paths frequently and calculate right after updating of the nav mesh, so it's always correct.

    it is a lot of work to have bots with natural motion

    ОтветитьУдалить