I cannot, but I can suggest an extra way to break the problem into smaller pieces to increase your understanding of the next tutorial you tackle.
When you implement A*Star in a game engine you’re actually doing TWO things, and I think this is where a lot of people get tangled up.
Part 1:
The actual AStar algorithm is just a graph traversal searcher with heuristic. It’s super-dry super-abstract, almost impossible to really do anything useful with in its own regard. This is the part that is largely described in the Wiki page and other tutorial pages about AStar. It is literally “how do I get from this data structure to that data structure.”
Part 2:
This is how your game, basically all the GameObjects, components, linkages to get from one place to another, area connections, etc., how that maps to the graph. Remember, A*Star only operates on a graph, and a graph is just a collection of nodes and some lines linking them together.
Obviously it’s not practical to link every millimeter of your game world together because the graph would be massive, so there is a mandatory simplification of the game world that must happen.
With a grid it is slightly more straightforward, but then you also must map how to incur costs such as “infinitely high cost” (a wall you cannot walk through) or “kinda high cost” such as mud or mountain or sticky ground. These types of world nuances must be encoded into the graph as the costs for each part of it.
So keep these two things in mind on your next tutorial. The first AStar routine really can just be done once. It’s just super-dry math. The second part is the hard part, the part that you must make decisions about as a game engineer. That’s basically why you can’t just “drop in” an AStar package because all it would get you is Part 1 above.