New AI for Mobs

[NiLSPACE]

I had this idea for the cWorld::SpawnMob function where you could give other mobs a different AI. For example I could use: cWorld::SpawnMob(X, Y, Z, mtCreeper, AI.Zombie) and then you would have a creeper with a zombie AI. That way you could maybe also create your own AI in an plugin. Ofcourse this idea IF it could be done would be in the far future since the AI isn't properly implented.

[xoft]

If we interface the current AI ideas properly to the plugins, this could be done, although with a bit more work.

[SamJBarney]

Hey, I've just been looking over this thread, and it has got quite a few good ideas.

First, I believe that having two levels of AI adds a great deal of flexibility. The higher level handles the selecting of which behavior/task to execute, and the lower level is the actual running of that behavior.

I personally think that we should only run one behavior at a time, but if a behavior is put back into the priority queue it should hold its state. So if, for example, a villager is busy building a house and is attacked by a player, the upper level AI generates a new RunAway behavior and puts it in the priority queue.
On the next tick, it checks to see if the next behavior in the queue has a higher priority than the current task does. Since running away from being hurt has a higher priority than building the house, the BuildHouse gets put back into the queue and the RunAway gets set as the current behavior.
Once the villager escapes the player, we delete the RunAway behavior and pull the next behavior out of the queue, which just happens to be the BuildHouse task. The villager then returns to where he was building the house, and continues from where he left off.

Does that make sense? Did I explain it alright? I've been thinking about the AI for quite a while, and really want to implement it/see it implemented

[xoft]

Yes, that makes sense. However, implementing those will only be possible if you have the basic building blocks already in place. We need pathfinding first. Since the last update to this thread, we have already implemented line-tracing (for sight).

[SamJBarney]

Actually, we don't have to have pathfinding implemented. Since each behavior is its own class, we can have movement be simple and then come back later when we have pathfinding figured out and redo that one feature. Any of the behaviors that depend on movement might be a bit derpy till we fix it, but we can still move forward with it.

[xoft]

There are very few behaviors that don't include movement, so you won't have much to test the code.

[SamJBarney]

True. Thanks for pointing that out. I think I will work on an A8 movement algorithm first, and then once that is done, I'll start working on the other ones.

I've pretty much got it laid out out in my head how its all going to fit together. But I will get back to you about it.

[SamJBarney]

For my A* pathfinding algorithm, I am trying to find an efficient way to handle unreachable locations. Anyone got any ideas? I'm thinking about using a flood fill algorithm to handle determining reachability.

[xoft]

I don't think that handling unreachable locations would give you any speedup, since finding them will be generally as slow as the actual pathfinding. So just try to find the path and make sure to handle situations when such a path doesn't exist.

[SamJBarney]

I'm having a minor issue with basic mob movement, which I am using as a stepping stone to my A* algorithm. Every once in a while, when a mob encounters a wall that is two blocks high, it will continue to try to walk through it. This also seems to happen every once in a while with single high block walls.

The code that handles this is here: https://github.com/SamJBarney/MCServer/b...sition.cpp

Anyone see anything wrong? Oh, and this is not the final code. I've been toying with it, and so things are not as efficient as I originally had it.