This is my first question here, if I did something wrong, tell me…
I’m currently making a draughts game in Java. In fact everything works except the AI.
The AI is at the moment single threaded, using minimax and alpha-beta pruning. This code works, I think, it’s just very slow, I can only go 5 deep into my game tree.
- I have a function that recieves my mainboard, a depth (starts at 0) and a maxdepth. At this maxdepth it stops, returns the player’s value (-1,1 or 0) with the most pieces on the board and ends the recursive call.
- If maxdepth isn’t reached yet, I calculate all the possible moves, I execute them one by one, storing my changes to the mainboard in someway.
- I also use alpha-beta pruning, e.g. when I found a move that can make the player win I don’t bother about the next possible moves.
- I calculate the next set of moves from that mainboard state recursively. I undo those changes (from point 2) when coming out of the recursive call. I store the values returned by those recursive calls and use minimax on those.
That’s the situation, now I have some questions.
I’d like to go deeper into my game tree, thus I have to diminish the time it takes to calculate moves.
- Is it normal that the values of the possible moves of the AI (e.g. the moves that the AI can choose between) are always 0? Or will this change if I can go deeper into the recursion? Since at this moment I can only go 5 deep (maxdepth) into my recursion because otherwise it takes way too long.
- I don’t know if it’s usefull, but how I can convert this recursion into a multithreaded recursion. I think this can divide the working time by some value…
Can someone help me with this please?
Sounds strange to me. If the number of possible moves is 0, then that player can’t play his turn. This shouldn’t be very common, or have I misunderstood something?
If the value you’re referring to represents the “score” of that move, then obviously “always 0” would indicate that all move are equally good, which obviously doesn’t make a very good AI algorithm.
I’m sure it would be very useful, especially considering that most machines have several cores these days.
What makes it complicated is your “try a move, record it, undo it, try next move” approach. This indicates that you’re working with a mutable data structure, which makes it extremely complicated to paralellize the algorithm.
If I were you, I would let the bord / game state be represented by an immutable data structure. You could then let each recursive call be treated as a separate task, and use a pool of threads to process them. You would get close to maximum utilization of the CPU(s) and at the same time simplify the code considerably (by removing the whole restore-to-previous-state code).
Assuming you do indeed have several cores on your machine, this could potentially allow you to go deeper in the tree.