Depending on the type of puzzle, it might be possible to work backwards. For example here, if you can compute reverse-transitions you could run one or two steps of that, and put all states from which the goal can be reached in two moves into a HashMap. Then you run the forward search and stop as soon as you hit anything in that HashMap. In theory, you can reduce the runtime to find an n-move solution from O(bf^n) to O(bf^{n/2}), at the cost of more memory use. This can also be combined with A*.
Low-level optimization can be worth it:
* You can try to pack the game state into integers and use bitwise operations. An 8×8 board can be stored as a 64 bit vector, so a `u64`. If you know the edges of the board are never occupied, then moving around can be as simple as a bit shift (probably not for this game).
* A smaller state representation also means that HashMap lookups will be faster.
* Instead of using a pair of integers to represent a position, use a single integer and save a multiplication for every lookup into a grid.
* Add a ring of impassible cells around the board, instead of checking for the edges of the board each time.
Low-level optimization can be worth it:
* You can try to pack the game state into integers and use bitwise operations. An 8×8 board can be stored as a 64 bit vector, so a `u64`. If you know the edges of the board are never occupied, then moving around can be as simple as a bit shift (probably not for this game).
* A smaller state representation also means that HashMap lookups will be faster.
* Instead of using a pair of integers to represent a position, use a single integer and save a multiplication for every lookup into a grid.
* Add a ring of impassible cells around the board, instead of checking for the edges of the board each time.