so i have just added movement to my game and im about to implement turns which will need at least one enemy to work and i want it to be that on the enemy’s turn they find the quickest way to the player (while moving a set amount of tiles per their turn)
for the way my game works this probably wont work since the obstacle layout is more or less randomized and there can be more than one enemy in the room which would count as a obstacle
Maybe you store the random info in a table as it generates and then run Jumper
that could work, i mean each obstacle layout is “random” but the postions of the obstacles are prebuilt then randomly picked so i guess i could make it read the layout and then set the obstacle positions but that still leaves other enemies and the player as outliers(think thats the right term)
Layout will work fine based on what you’ve said. Also, you have the source so you can tweak it as needed.
If you are working with the same type of grid based layout as when you shared your project here on the forums, then you should be able to be use Jumper with relative ease. You would simply need to update the map for jumper if and when obstacles (such as enemies) move around on the map.
I built A* path finding into my engine, and it works incredibly well.
The exact concept is documented loads, so definitely Google it, but in a nutshell you work outwards from the origin tile creating a score for each adjacent that’s based on its grid distance from the destination and the number of ‘turns’ it took to get to that tile from the origin. Save the score, the turns, and the tile you were using when creating its score.
Once you’ve scored the adjacents, move on to whichever tile in the list of scored has the currently lowest score and then do the adjacents for that one. If one of the adjacents is already scored but the new score would be lower, replace the old score with the new, including the number of turns to get there and the tile you got to it from.
Eventually you’ll get to the destination and can work backwards through the list of tiles that came to it, and there’s your shortest route.
At this point you can build a list of tiles that can’t be traversed to, or that can only be traversed to from a certain direction, and refer to those during the adjacent tile scoring. Thus avoiding obstacles on the map.
It’s also worth increasing the score differently if the movement is diagonal otherwise the shortest path ends up a zigzag.
Hope this all makes sense. Definitely look up a proper guide though - It was a while ago now when I built mine and I’ve probably missed something in the explanation.
Amit Patels website is pure gold for these kinds of things
Some links as a starter … but the whole site is just full of great information
https://www.redblobgames.com/pathfinding/grids/graphs.html
https://www.redblobgames.com/pathfinding/a-star/introduction.html
so sort of like a fitness system that is used for AI’s? the closer they get the higher the score and the further the lower, where the enemy is wanting to have the score increase therefore being closer to the destination?
Not quite. What you’re aiming for is the lowest score, because that means the fewest number of tile iterations to get there, which in turn means the shortest path.
I read through a bunch of articles before building my own implementation, but I THINK this was the one that made everything ‘click’ for me: https://old-homepages.abdn.ac.uk/f.guerin/pages/teaching/CS1013/practicals/aStarTutorial.htm
Your exact implementation might differ slightly to other peoples when you come to building, because optimisation is subject to usage. I think that’s what I liked about this one - it explains the fundamentals but leaves you to decide how best to code those fundementals in, how to tweak for your own needs (again you might for example want to score diagonals differently, or not allow diagonal movement at all, etc), and how to keep it running efficiently.
What’s actually really interesting is that once you’ve built A* in to a conventional grid based game and understand it from a conceptual level, you actually realise how it can be used for more complicated systems, which don’t follow a traditional grid. Road networks for example, to plan routes from a GPS co-ordinate to a destination. The roads might not be a conventional grid but they connect up in just the same way - look at all of the junctions as your grid and factor road length/speed between each junction into your scoring and the same path-finding code could be used for a real-world route planner. Read this paragraph again once you’ve built your first path finder and you’ll see what I mean 
just a caveat to the OP that A* is only as good as its hueristic (ie, how well it can estimate remaining distance to goal), otherwise a simpler algorithm (fe Djikstra or BFS) might perform just as well (or even better).
some problems are hard, not because of having to find an A* implementation (because there are many out there), but because of having to then define its hueristic for your particular use case (which might be trivially simple, like simple movement on a regular grid, or incredibly difficult like ‘what’s the best next chess move’)
for the way my game works this probably wont work since the obstacle layout is more or less randomized and there can be more than one enemy in the room which would count as a obstacle
Maybe you store the random info in a table as it generates and then run Jumper
that could work, i mean each obstacle layout is “random” but the postions of the obstacles are prebuilt then randomly picked so i guess i could make it read the layout and then set the obstacle positions but that still leaves other enemies and the player as outliers(think thats the right term)
Layout will work fine based on what you’ve said. Also, you have the source so you can tweak it as needed.
If you are working with the same type of grid based layout as when you shared your project here on the forums, then you should be able to be use Jumper with relative ease. You would simply need to update the map for jumper if and when obstacles (such as enemies) move around on the map.
I built A* path finding into my engine, and it works incredibly well.
The exact concept is documented loads, so definitely Google it, but in a nutshell you work outwards from the origin tile creating a score for each adjacent that’s based on its grid distance from the destination and the number of ‘turns’ it took to get to that tile from the origin. Save the score, the turns, and the tile you were using when creating its score.
Once you’ve scored the adjacents, move on to whichever tile in the list of scored has the currently lowest score and then do the adjacents for that one. If one of the adjacents is already scored but the new score would be lower, replace the old score with the new, including the number of turns to get there and the tile you got to it from.
Eventually you’ll get to the destination and can work backwards through the list of tiles that came to it, and there’s your shortest route.
At this point you can build a list of tiles that can’t be traversed to, or that can only be traversed to from a certain direction, and refer to those during the adjacent tile scoring. Thus avoiding obstacles on the map.
It’s also worth increasing the score differently if the movement is diagonal otherwise the shortest path ends up a zigzag.
Hope this all makes sense. Definitely look up a proper guide though - It was a while ago now when I built mine and I’ve probably missed something in the explanation.
Amit Patels website is pure gold for these kinds of things
Some links as a starter … but the whole site is just full of great information
https://www.redblobgames.com/pathfinding/grids/graphs.html
https://www.redblobgames.com/pathfinding/a-star/introduction.html