A* Native Extension

This is a path finder and A* solver (astar or a-star) native extension for Defold Engine build with good old MicroPather. I did try to make it simple as possible. This is why I embed some logic into the C++.

selimanac/defold-astar - GitHub

Simple Examples: https://github.com/selimanac/defold-astar-examples


Just tried this A* extension, works fine! Thanks!

demo: https://dragosha.com/defold/3d/


Some issues found.

In some cases solve_near() doesn’t return nears array after create a new map (switch between levels). But solve() still works correct. Sometimes solve_near() returns nears after second call only. First function call returns NO_SOLUTION and nil, second call after first one with the same map state returns SOLVED and nears table.

Also reset() or reset_cache() before map initialization will crash engine.


I’ll try to figure it out, but I’ll be glad if you can share a simple test case.
I guess it is because the cache. I have doubts that cache might not working as expected.

This is because I’m lazy and since I’m not expecting someone to reset things when it is empty :slight_smile: I’ll take a look, It should be easy to fix.


I’m a bit confused, when I’ve tried to remove game assets and prepare vanilla tests - they works. So, I will investigate it more.

1 Like

Perhaps, here is something wrong:

This code seems directly copied from Solve function and checking ‘pathTo’, but which value ‘pathTo’ has within SolveNear function? Suppose this variable contains a value from previous calculation and in some case condition return NO_SOLUTION.

Highly possible. Honestly, I don’t remember why I did it this way. It seems very inappropriate right now.
I’m trying to complete one of my freelance work . It has a very tight deadline. I’ll check out those issues as soon as I can, sorry.


@Dragosha I fixed the issues, but as I suspected there is another issue about the cache. I’m going to push the changes when I find a way to fix this one(I hope before Monday).


I think all fixed now. You can test it from dev branch:


I was using astar.reset() just for development purpose only and this is why I wasn’t exposed it to the documentation. It is different then astar.reset_cache(). It removes all the data and the Map class internally. I fix it is bugs. It should be safe to use if you want to free some memory. But I believe it is not necessary. Also astar.reset() delete the Costs array. It must be set. Otherwise proper error occur which describes the situation.

astar.reset_cache() will not crash the engine anymore. Actually you don’t need to call it before changing map state using astar.set_map(). astar.set_map() calls reset cache internally.

You were right, It was about the world bound check for early exit. It is fixed now. (At least as far as I can test)

This is not related to your issue but It was returning nil caused by other issue. It was returning SOLVED and nil before when there is only tile itself as a solution. It will return NO_SOLUTION now.

There isn’t any breaking changes but I made a few more fix.

I try to test every circumstances which I can think of.
Here are the test files on dev branch:


I merged those fixes to “master” as v1.0.1.
If you are having an issue about those latest changes, please let me know.


astar.solve(start_x, start_y, end_x, end_y)
Worth noting that, start offset is 0 as oppose to Lua tables which starts from 1.


That is correct. It would be a good practice to change it to start with 1, but unfortunately I don’t have much spare time these days.

PS: There is also an issue and pull request about this. But this pull request isn’t backward compatible so I don’t want to merge it.:

1 Like

I also forked this awesome extension and add two methods: astar.get_at(x, y) to read value by coordinates and astar.set_at(x, y, value) to change map data without updating the whole map


@Dragosha This is great.
I can give you access to this repo if you want. We can merge this improvement.