Return to Answer

The easiest solution is to use any flood-type algorithm, for example as you mentioned Dijkstra's algorithm. The only difference is the stopping condition:

if(Resources.Any(r => r == node)) { ...}

instead of

if(resource == node) { ...}

you can improve its performance by excluding resources that cannot be possibly reached yet from the check (=found distance is smaller than direct distance) and of course by simplifying the underlying data to graph of nodes and weighted edges.
Personally, I would not suggest A* as it is harder to implement and there can be many special cases in labyrinth leading to flood-type complexity anyway but if you need the little extra performance and/or if you expect the path to be often straightforward I dont see any problem with it.
However, for the fastest solution you can pre-compute all vs all distances in graph using Floyd–Warshall algorithm in n^3 and resolve nearest resource in linear time, more precisely O(1) for each resource. This solution has also the upside of not-having to implement anything as you can use any existing implementation without any modifications.
For finding optimal (or near optimal) solution to find shortest path between many(not just single closest) resources you can also check this question.

The easiest solution is to use any flood-type algorithm, for example as you mentioned Dijkstra's algorithm. The only difference is the stopping condition:

if(Resources.Any(r => r == node)) { ...}

instead of

if(resource == node) { ...}

you can improve its performance by excluding resources that cannot be possibly reached yet from the check (=found distance is smaller than direct distance) and of course by simplifying the underlying data to graph of nodes and weighted edges.
Personally, I would not suggest A* as it is harder to implement and there can be many special cases in labyrinth leading to flood-type complexity anyway but if you need the little extra performance and/or if you expect the path to be often straightforward I dont see any problem with it.
However, for the fastest solution you can pre-compute all vs all distances in graph using Floyd–Warshall algorithm in n^3 and resolve nearest resource in linear time, more precisely O(1) for each resource. This solution has also the upside of not-having to implement anything as you can use any existing implementation without any modifications.
For finding optimal (or near optimal) solution to find shortest path between many(not just single closest) resources you can also check this question.

The easiest solution is to use any flood-type algorithm, for example as you mentioned Dijkstra's algorithm. The only difference is the stopping condition:

if(Resources.Any(r => r == node)) { ...}

instead of

if(resource == node) { ...}

you can improve its performance by excluding resources that cannot be possibly reached yet from the check (=found distance is smaller than direct distance) and of course by simplifying the underlying data to graph of nodes and weighted edges.
Personally, I would not suggest A* as it is harder to implement and there can be many special cases in labyrinth leading to flood-type complexity anyway but if you need the little extra performance and/or if you expect the path to be often straightforward I dont see any problem with it.
However, for the fastest solution you can pre-compute all vs all distances in graph using Floyd–Warshall algorithm in n^3 and resolve nearest resource in linear time, more precisely O(1) for each resource. This solution has also the upside of not-having to implement anything as you can use any existing implementation without any modifications.

The easiest solution is to use any flood-type algorithm, for example as you mentioned Dijkstra's algorithm. The only difference is the stopping condition:

if(Resources.Any(r => r == node)) { ...}

instead of

if(resource == node) { ...}

you can improve its performance by excluding resources that cannot be possibly reached yet from the check (=found distance is smaller than direct distance) and of course by simplifying the underlying data to graph of nodes and weighted edges.
Personally, I would not suggest A* as it is harder to implement and there can be many special cases in labyrinth leading to flood-type complexity anyway but if you need the little extra performance and/or if you expect the path to be often straightforward I dont see any problem with it.
However, for the fastest solution you can pre-compute all vs all distances in graph using Floyd–Warshall algorithm in n^3 and resolve nearest resource in linear time, more precisely O(1) for each resource. This solution has also the upside of not-having to implement anything as you can use any existing implementation without any modifications.
For finding optimal (or near optimal) solution to find shortest path between many(not just single closest) resources you can also check this question.

The easiest solution is to use any flood-type algorithm, for example as you mentioned Dijkstra's algorithm. The only difference is the stopping condition:

if(Resources.Any(r => r == node)) { ...}

instead of

if(resource == node) { ...}

you can improve its performance by excluding resources that cannot be possibly reached yet from the check (=found distance is smaller than direct distance) and of course by simplifying the underlying data to graph of nodes and weighted edges.
Personally, I would not suggest A* as it is harder to implement and there can be many special cases in labyrinth leading to flood-type complexity anyway but if you need the little extra performance and/or if you expect the path to be often straightforward I dont see any problem with it.
However, the absolutely fastest solution you can pre-compute all vs all distances in graph using Floyd–Warshall algorithm in n^3 and resolve nearest resource in linear time, more precisely O(1) for each resource. This solution has also the upside of not-having to implement anything as you can use any existing implementation without any modifications.

The easiest solution is to use any flood-type algorithm, for example as you mentioned Dijkstra's algorithm. The only difference is the stopping condition:

if(Resources.Any(r => r == node)) { ...}

instead of

if(resource == node) { ...}

you can improve its performance by excluding resources that cannot be possibly reached yet from the check (=found distance is smaller than direct distance) and of course by simplifying the underlying data to graph of nodes and weighted edges.
Personally, I would not suggest A* as it is harder to implement and there can be many special cases in labyrinth leading to flood-type complexity anyway but if you need the little extra performance and/or if you expect the path to be often straightforward I dont see any problem with it.
However, for the fastest solution you can pre-compute all vs all distances in graph using Floyd–Warshall algorithm in n^3 and resolve nearest resource in linear time, more precisely O(1) for each resource. This solution has also the upside of not-having to implement anything as you can use any existing implementation without any modifications.