My program does this to an extent - it's time control is based on an
aggressive percentage of the remaining time but it is modified by
other factors.
It has the interesting characteristic that it can get into time
trouble! I think a really good time control must get into trouble
once in a whi
It seems important to have some way of measuring how good / settled the
current "best move" is, particularly if you're also going to think in your
opponent's time. Otherwise, you could end up spending significant amounts
of "allocated" time when, for example, a sequence of forced moves is being
p
Hello,
I was thinking about this a few days ago and I decided I will try the
following:
When the engine is searching for best moves there is a "game path" of 3, 4 or
up to 10 moves that the engine have found to be the "best moves" so far.
0) Before start the search, based on total available ti
How much time should a program spend on each move?
I think this is one of the most important and also difficult questions in
game programming. Much effort is done to speed up the node-count by 10%, but
a good time control is a much more effective speedup.
If my program has t milliseconds le
On Wed, 2007-01-03 at 22:04 -0800, Peter Drake wrote:
> How much time should a program spend on each move?
>
> If my program has t milliseconds left to use in a game, and there are
> an estimated m moves left on the board (e.g., this many vacant
> spaces), one reasonable choice is t / m.
Exce
How much time should a program spend on each move?
If my program has t milliseconds left to use in a game, and there are
an estimated m moves left on the board (e.g., this many vacant
spaces), one reasonable choice is t / m.
In practice, this seems to spend too much time on early moves, whi
