I commented out the transposition table code. It is not always playing better. In some games, the AI has a clear win on the next move, however it stays moving other unnecessary pieces. Looks like this happens more often in the endgame.
I use 2 depths because (as you can see from the code above), I do:
1. check if the current depth is the maximum depth (maximum being that of the current iterative of the ID) and if it is, I exit the function, and
2. if current depth == 0, then the search is at the root and I need to save the the move too.
I don't know how I can eliminate one depth variable.
My move ordering sorts by: transposition move, capture move, primary killer, secondary killer in descending order. It also adds the history heuristic to each move before sorting. I currently don't implement move reduction. Maybe I should consider this too.
my game consists of a 6x4 board and 8 pieces per player. All pieces are of the same value (ie. no king, queen, etc). And the game is just moving pieces from one square to another. Something similar to checkers.
I've finally managed to implement ID into the search and it's working. I have a couple of questions:
1. Killer moves are local to the current search. Should the TT also be local to the current search or should it be for the whole game?
The TT should be for the whole game, or you'll forget what you learned in the previous search, which is not a good idea.
>2. I also implemented transposition move in the search (before normal negascout search starts). However an assert is failing on makeMove because the current position doesn't belong to the current player on turn. Should I even bother with an assert there?
So you have an assert that fails for reasons you don't quite understand? It sounds like removing it is a horrible idea.
3. I would like to implment history heuristics. Are these local to the current search or should they be for the whole game?
I make them for the whole game, but I divide every entry by 4 at the beginning of each search, so old entries that are no longer relevant can decay. If you were to make them local to the current search, I think they would work just fine too.
good answer for question 2!! nah I will need to find out what the problem is and solve it.
for the history table and in the case of nine men morris where you have just placement of pieces, moving, and also placement+capture and move+capture is it wise to have a 4d array in this case or should I have a 2 3d arrays (one for each player).
when sorting the history, i would assume that the moves are sorted based on the array of player whose turn it is at that stage of the search. right?
small question about iterative deepening... I have a time limit of 2s and it goes 7 plies deep but sometimes it goes even 8 or 9 but because the time required to complete the search at that depth is more than 2s, it can take up to 6s to complete. should i also quite searching in negascout by checking outOfTim() in the move loop or is it wise to let it finish the search at that depth?