Wow ... great code!
Yup, thanks for caching that. I guess my compiler probably reserves 36 bytes when asked for 33, which is what "saved" me in my tests.
I tried to run it and get the following error:
"Run-Time Check Failure #2 - Stack around the variable 'moves' was corrupted"
Edit: found the problem, since there can be maximum of 34 moves the declarations of "Move moves;" must be changed to "Move moves;" !
I did not implement that, and the rule didn't come up in the games I played. This is an important rule because without it there are infinite games (draws, I would say). I'll implement it later.
P.S: there are 2 additional rules i idn't mention cuz of simplicity:
- once a piece moves into hostile base, that hostile base is broken, which means that any pieces moving into it will be destroyed
Yes, I figured this out from playing with the emulator.
- a piece located directly beside a base will always move into it regardless of the move-type, e.g. if piece is on 3rd row beside the hosile base and the chossen move is "up", then the piece will go into the base on 3rd row and not , as expected, into base on 4th row.
That seems a little harsh. My program picks one of these moves that you forbid occasionally. What I did was penalize them as costing 2 plies in depth. So the nominal depth that my program searches to is only for normal moves (1,2,4,8,16,32,33,34 in my notation). I have a table called "cost" (bad name, sorry) to encode that.
PPS: i am not sure but bringing out too many pieces out of a base may strategically not be so good. So in my move generation i only consider moves with only one base (in your case 1,2,4,8,16) with additional base moves only if there is a hostile piece outside beside the base. This reduces the number of possible moves a lot.
I might also be wrong with this consideration ... i have to get a better player with this game.
EDIT: Oh, I also generate normal moves before multiple-figures-out-of-base moves, in the hopes that this order will speed up alpha-beta.