I saw your question for feedback so here is some.

First of all clippy is your friend:

warning: this `.fold` can be written more succinctly using another method
  --> src\ai.rs:31:10
   |
31 |         .fold(0, |a, b| a + b); //.expect("If no distance was here, we couldn't have won or lost.");
   |          ^^^^^^^^^^^^^^^^^^^^^ help: try: `sum()`
   |
   = note: `#[warn(clippy::unnecessary_fold)]` on by default
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_fold

You can find clippy here: https://github.com/rust-lang/rust-clippy. On the same note rustfmt is very nice as well.

Otherwise I have tried to leave feedback inline. If you have any more questions feel free to reach out. And a very very nice first project for a new Rust user, a lot of moving parts and a lot of logic that is tricky to get right. So very good job!

Stalemate can occur when pieces are cornered, namely when get_next_moves is empty. As opposed to chess, the dominating player wins the game in this situation.

The maximum branching factor in the search tree is around 32 (8 pieces, each with 4 possible moves). Currently the default search does therefore worst-case 32^3 (with extremely unlucky alpha-beta pruning) evaluations, which is quite a lot.

• Sorting next move candidates by some "move evaluation" (e.g. prefer capping pieces or entering dens) should help the alpha-beta pruning to take action earlier.
• Caching the search tree might help.
• Having something like an "opening database" similar to how they do it in chess should also help good enough. we can always trade time for memory, and here i think time is more important than memory.