A* PathFinding in a Console MUD Game
Does anyone know of an article or simple source code that explain how to implement A* in a console MUD game. I see articles on how to use it in 3D and 2D and me not knowing enough about them I have a extremly hard time of understanding how to use the A* pathfinding. And article about how to use it in some kind of console text RPG game would be extremly helpful in C++. Thanks in advance.
September 08, 2004 05:27 PM
a 2D one should help you on this. all you need to do is create a grid for your room and work it from there.
then search the each sector of the grid until you find something.
then search the each sector of the grid until you find something.
September 08, 2004 05:31 PM
http://www.gamedev.net/reference/articles/article2003.asp
continuing on the above this should help.
http://www.gamedev.net/reference/articles/article2003.asp
continuing on the above this should help.
http://www.gamedev.net/reference/articles/article2003.asp
Note that you're going to need to have some sort of x,y coordinates for your locations, or A* won't have a useful heuristic to work with. Similarly, if you have any odd wrap-around mazes or anything else that doesn't fit nicely into Euclidean space you might run into problems. I think a simpler breadth-first search would be slightly easier to implement and less likely to suffer from problems in the above cases. There's not really any difference in the algorithm for a MUD compared to the algorithm in a 2D tile-based game.
A* ONLY works if you have a distance function which fulfils the requirements.
If your nodes are connected by a graph where distance is not a relevant concept (i.e. in a non-eclidean space fashion), it doesn't work.
If there is no way of making a working distance function, then use Dijkstra's algorithm instead, which is basically the same, but doesn't even TRY to find the nearer paths first.
A* is just an optimisation of Dijkstra anyway.
Mark
If your nodes are connected by a graph where distance is not a relevant concept (i.e. in a non-eclidean space fashion), it doesn't work.
If there is no way of making a working distance function, then use Dijkstra's algorithm instead, which is basically the same, but doesn't even TRY to find the nearer paths first.
A* is just an optimisation of Dijkstra anyway.
Mark
It doesn't have to be spacial distance, but basically there has to be something letting A* know a rough estimate of the best direction to search in order to find the target, without that, you are basically going to be searching every room based on exits.
Basically the A* takes accumulates the cost of moving to a square with the cost of the heuristic for reaching the goal. So it can work for really any sort of search as long as you have a heuristic that under estimates the true path cost to the goal.
If the Heuristic were completely accurate then you would never have anything but the true path to goal in your search space.
I was wondering if anyone has tried anything other than distance for a heuristic. Like marching towards the goal directly and then when colliding updating the heuristic.
If the Heuristic were completely accurate then you would never have anything but the true path to goal in your search space.
I was wondering if anyone has tried anything other than distance for a heuristic. Like marching towards the goal directly and then when colliding updating the heuristic.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement