Time Management in a game of Blokus

Started by
9 comments, last by shishio64 10 years, 3 months ago

in move ordering i only try the move from the transposition tables (the best move from previous iteration). i also use the transposition tables to store exact values or bounds in case we reach a state with depth lower or equal to the one stored in the TT (i used an old post of yours which was very helpful to do this :) ).

can you explain what killer moves are and how do they differ from moves stored by the history heuristic? i understand how the history heuristic works in general but i don't really know how to maintain it throughout the game. should i clear it after each move search or share the information between moves searches? i also don't really see how it could help here? in Blokus the same move cannot be applied more than once so wouldn't the information be useless? what tweaking would it require?

i will look into the late move reduction scheme you mentioned, but i think it's too advanced for me... i only know alpha-beta, i haven't even learned NegaMax so NegaScout might be a bit too much...

finding a good evaluation function is part of the assignment. the evaluation function im using takes into consideration square balance (which is actually the score balance computed at O(1)) and "corner balance". the problem with corner balance is that the value is computed at O(n) which slows search down a lot.

i was also thinking about "center control" (my player tries to go for the center) but it is also computed at O(n). do you have any idea for a simple yet powerful heuristic?

the first thing i did was to build a mechanism for matches and also a mechanism to run two players on the same states to really see the difference.

This topic is closed to new replies.

Advertisement