L O N G - R A N G E P L A N N I N G IN

C O M P U T E R CHESS
Jonathan Schaeffer

University of Waterloo,
Waterloo, Ontario
Canada

ABSTRACT

A serious deficiency in game-playing, tree-searching programs is their short-

sightedness. Program strategy revolves around the maximization/minimization of
what is attainable within the scope of the search tree with little consideration of
what lies beyond. This paper describes Planner, a long-range chess strategist t h a t
assesses positions, determines a long-range strategy, and makes moves in the short-
term (within the scope of the search tree) consistent with a long-term objective
(beyond the depth of the search tree). In effect then, Planner allows the program to
"see" beyond the limitations of the search tree.

Permission to copy without fee all or part of this material is granted

provided that the copies are not made or distributed for direct
commercial advantage, the ACM copyright notice and the title of the
publication and its date appear, and notice is given that copying is by
permission of the Association for Computing Machinery. To copy
otherwise, or to republish, requires a fee and/or specific permission.
© 1983 ACM0-89791-120-2/83/010/0170 $00.75

170
1. I n t r o d u c t i o n
G ame-playing, tree-searching
programs, such as for chess, usually
suffer from myopia. If one builds a tree
t h a t is n levels deep (n ply], one may be
missing something important t h a t can
only be seen by looking n+ 1 levels
deep. The use of sophisticated tree-
searching techniques (alpha-beta,
iterative deepening, transposition tables
[1], etc.) can limit the size of the game
trees built, but for a typical middlegame
chess position, 9 ply is the current limit
t h a t one can realistically expect to
search. Current solutions to this
problem are largely hardware based:
build faster machines t h a t can search
larger trees, extending the "sight" of the
program [2]. Although this does not
alleviate the problem, it does help
minimize its effects.
C o m p u t e r chess programs have
often been criticized for their superficial
play. The reasons for this are obvious.
The program selects its best move based
on what can be seen within the search
tree. On a move-to-move basis, each
search tree is different and the move
selected is not necessarily consistent
with the previous move. This lack of
continuity results in move selections
t h a t are the best in the short term, but
not necessarily in the long term.
Chess grandmasters analyze
variations as the computer does, but
they does so with a long-range plan in
mind. These plans are arrived at by a
detailed examination of the potential
possibilities that the position has to
offer. A strategy is then devised for
achieving these plans. Only once this is
done does the grandmaster start to do
concrete analysis, keeping in mind the
objectives that he has set out to
accomplish.
Using long-range planning in chess
programs, we can help minimize some of
the effects of short-sightedness of the
171
search tree. After deciding on a long-
range strategy, the program can make
moves in the short term (i.e., within the
scope of the tree) consistent with a
long-range objective whose attainability
may be beyond the depth of the search
tree. In a sense then, the program can
achieve greater foresight.
This paper describes Planner, a
long-range chess middlegame strategist.
Planner is concerned with strategic
(positional) plans that extend beyond
the depth of the search tree (see also
[3,4]), unlike other types of chess
strategists which limit themselves to
tactical plans within the scope of the
search tree [5, O, 7].
Planner to a large extent acts as a
pre-processor for a chess program. Each
time it is the program's turn to select a
move, Planner is called to analyze the
position at the root node of the search
tree about to be constructed. After an
extensive analysis, Planner selects an
appropriate long-range strategy. The
selected strategy is used to construct
move scoring tables t h a t are used to
rank moves at interior nodes, and to
help evaluate terminal nodes. Planner
also determines the features of the
position that caused a particular plan to
be selected. This status information is
used on a move-to-move basis to
determine if the original plan is still
valid. During the tree search, it
determines if the position has changed
to such an extent as to invalidate the
Planner move scoring tables.
Planner consists of three major
modules: Plan Selection, Strategy, and
Move Generation. The Plan Selection
module assesses the current position and
selects one or more plans based on t h a t
assessment. For the chosen plan(s), the
Strategy modules decides what has to be
accomplished, and how, by deciding the
piece positioning likely to accomplish
that strategy. It passes to the Move
Generation module a list of pieces, the
squares we want them on, and the value
of getting them there. From this
information, the move scoring tables are
created. These tables serve to
encourage moves to square(s) that best
contribute to the plan.
2. Plan S e l e c t i o n
~%en a grandmaster examines a
position, one of the first things he does
is to assess its long-range prospects:
'W~ere do I want to attack? Do I have a
weakness that needs defending? What
are my prospects, good or bad, in this
position? The answers to these
questions guide his subsequent play.
Plan selection is the most
important and, naturally, the most
complicated phase of Planner. This
routine does a detailed examination of
the position identifying the important
strategic features, such as the pawn
formation (weaknesses, blocked pawns,
potential levers, passed pawns, open files
and half-open files, etc.), center
formation, piece placement and
distribution, and king safety. The
routine attempts to identify which of
these features are the most relevant to
the selection of a plan. This analysis
may result in one of 13 plans being
chosen. Figure 1 lists the major plan
classifications. For each plan type,
there is a template defining various
board features that, if present, would be
conducive to the selection of this plan.
Each plan type is examined in turn and
scored on its feasibility, practicality, and
likelihood of success. The plans with
the highest scores, relative to a
dynamically determined threshold for
each plan type, are chosen for
implementation. In the event that no
plan is found, a default "Wait" plan is
invoked until such time as the program
can come up with a suitable plan.
172
It is not sufficient to do long-range
planning for only one of the players.
The opponent, too, has a plan. In chess
it is as important to anticipate and
disrupt the opponent's plan as it is to
execute your own. Thus we call
Planner for white and black and store
the results separately.
One plan for each side is usually
not sutIicient; it is not an uncommon
occurrence to be attacking on one flank
and defending on the other. T h u s one
must allow for multiple plans. In fact,
Planner allows each side to have one
offensive strategy and if necessary one
defensive plan.
The Plan Selection module not
only ehoses a plan, but also records an
approximation of the the conditions
under which t h a t plan is valid. This
information is used to decide when to
terminate a plan, on a move-to-move
basis as well as in the search tree. The
important positional feature(s) t h a t
resulted in the plan(s) being selected are
recognized and saved in various status
words. If any of these features change
significantly, this is used as an
indication t h a t the position has changed
to the extent that the current plan(s)
are possibly invalid. More details are
presented in Section 5.
3. Strategy
Having decided on his long-range
plans, the grandmaster now sets about
formulating how to implement these
chosen objectives. He will visualize
where on the board he wants each piece
so t h a t it can contribute maximally
towards his goals. Then he goes about
deciding how (if at all) the pieces can be
manoeuvered to these optimal squares.
The result is that for each piece, the
grandmaster knows where he wants it to
go and how to get it there. This
information is used to guide his play for
subsequent moves.
 Type Offence
General Attack king-side
Attack queen-side
Attack center
Specific Attack pawn weakness
Occupy open file
Pawn break
Advance passed pawn
Other
Figure 1
Having decided on a course of
action, Planner must now generate a
strategy for achieving these goals. Like
the grandmaster, Planner decides where
it wants its pieces located and devises a
means for achieving these locations.
For each plan type, there is a strategy
routine that uses the position features
found by the Plan Selection modules as
clues for deciding where the pieces
should be located. This routine decides
where it wants its pieces (and where it
does not) and calls the Move Generator
to lay out a method for manoeuvering
the pieces from their present to their
desired squares.
Each strategy routine uses the
information uncovered by the Plan
Selection module to break the selected
plan(s) into one or more sub-plans; each
directed at a different part of the
problem. The sub-plans may be very
simple, such as to move a piece to a
specific square, or more difficult, such as
prying open a file. The former involves
only one piece and one square; the
latter, several pieces and several squares.
The idea is to find the best square(s) for
each piece (queen excepted) and for each
square, assign a value (priority)
indicating the relative worth of
successfully attaining that square. For
173
Defence
Defend king-side
Defend queen-side
Defend center
Defend pawn weakness
Block passed pawn
Wait
queens, it is usually much more difficult
to assign it a "best square" because of
its tremendous versatility. Instead, the
queen is assigned a region of the board:
the closer to the region, the greater the
contribution of the queen to the plan.
A simple example of a plan from
Planner'8 repertoire is attacking an
opponent's pawn weakness. For this
plan, depending on the actual position,
there may be three sub-plans. The first
one is to prevent the opponent from
liquidating the weakness. This may
involve manoeuvering pieces/pawns to
squares to restrain the weak pawn.
After the weakness is fixed, the second
strategy is to attack the weakness as
many times as possible. Typically, the
square in front of the weak pawn
(restraint) and the square of the pawn
itself (attack) are the ones that the
Strategist keys on. The third sub-plan
involves preventing the opponent from
defending the weakness. With this
strategy, Planner determines the most
likely squares the opponent will use for
defence of the weakness and attempts to
attack those squares. How successful
this strategy will be depends on the ease
with which the sub-plans can be
accomplished and the events happening
elsewhere on the board.
 In addition, Planner recognizes
outposts (weak squares in the enemy's
camp) which it treats as sub-plans.
Occupation of these squares is usually of
considerable value, even if the
occupation does not directly contribute
to any of the plans chosen. Improving
the position of any piece is always
worth-while. There is no strategy
required to occupy an outpost, so the
list of outposts is passed directly to the
Move Generator.
4. M o v e G e n e r a t i o n
Having decided where it wants its
pieces located, Planner then determines
how to get them there from their
current position. This may be a trivial
task in the case where a piece is already
on its best square, or can move there
directly. But usually it is not so
obvious; a square in the way may be
attacked or occupied so that several
moves are required to successfully
deploy the piece.
The information on where and how
to move the pieces is used in position
and move evaluation by the host chess
program. As these evaluations comprise
a high percentage of a chess program's
total execution time, it is essential to
store the Move Generator information in
a data structure t h a t allows very fast
retrieval. The structure used is called a
board image - an array of 04 elements
with a score for each square on the
board (along the lines of Botvinnik's
maps/3D. There is one image for each
piece type and colour. The value for a
given move is then the value of the
square moved to less the value of the
square moved from.
To entice a piece to move from its
current square to a square consistent
with the selected plans, we use the
board images to contain a "trail" of
successively increasing scores t h a t lead
to the desired square. A piece follows
174
its trail in order to maximize its score.
In assigning scores to squares in
the board image, it is necessary to
consider how likely the piece is to use
that square along the path in the near
future. If it is very unlikely, then the
path in t h a t direction is discontinued.
If the path is blocked by a friendly
piece, an examination is made to see if
it is feasible to move t h a t piece out of
the way. If not, the assignment of path
scores in t h a t direction is halted.
Otherwise, the scores along the path are
assigned to the appropriate squares.
Just as certain squares are
desirable, so are some undesirable. The
board images can have negative scores
placed on squares deemed poor, thereby
making it very unattractive for a piece
to move there.
Figure 2 illustrates the concept of
the board image. Here we want to
manoeuver a knight from C1 to FS. If
F5 is to be occupied, we give t h a t
square in our board image full value of
the score given by the Strategy module.
If the square is only to be attacked, we
give t h a t square a value of zero to
discourage pieces from actually moving
to it.
All squares that can be safely
occupied by the piece and are one move
away from the desired square receive
part of the total score. Similarly, all
safe squares t h a t lead to squares t h a t
can reach the desired square in one
move receive a smaller percentage of the
total score. In Figure 2, the F5 square
receives a score of 10 as determined by
the Strategy routine. All squares t h a t a
knight could safely occupy and be
within one of F5 (such as H4, G3, E3,
and D4) receive 8 points; half the total
score. Squares within two moves of F5
(e.g., B3 and E2) receive half of the
value of squares t h a t are within one
move. Note t h a t Figure 2 shows scores
assuming an e m p t y board. In practise,
 8
0 0 4 0 4 0 4 0
7
0 4 0 0 8 4 8 0

6
0 0 4 8 4 0 4 8

5
0 4 0 4 0 16 0 4
4
0 0 4 8 4 0 4 8

3
0 4 0 0 8 4 8 0
2
0 0 4 0 4 0 4 0
i
1
!0 0 N 4 0 I 4 0 4

A B C D E F G H

Figure 2

the board image is sparser because most
paths are found to be impractical.
Now examining the knight on C1,
we can easily see how it can be
manoeuvered to F5 if we know that
chess programs try to maximize scores.
The knight on C1 would prefer to move
to E2 or B3 (score 4) than to any other
square (score 0). Once on B3, the
knight's best move is to D4 (score 4).
Finally, once on D4, the knight can
achieve its goal and move to F5 for an
additional 8 points. Thus the knight
follows a trail to maximize its point
gains; deviating from this path earns
negative or zero scores, much to the
chess program's distaste.
Note t h a t the board images merely
provide scores to be used in evaluating
moves. The chess program must also
evaluate the move and score it on other
factors (material, king safety, pawn
structure, for example) as well. It is the
combination of these scores that will
determine if and when the the knight
journeys from C1 to F5. The Planner
scores attempt to bias chess program
scoring mechanisms towards moves that
are consistent with a plan.
The grandmaster will look at a
piece's position and determine a method
of moving the piece from its current
location to its desired location. The
Move Generator, in a sense then, works
backwards. We start with the desired
position and move backwards towards
the current position. Programming
techniques that emulate the human
approach have had limited success
because it is ditficult to find a correct
path given that squares along it may be
unsafe or occupied. Working backwards
has the advantage of leaving a trail
behind for every feasible path that can
safely lead to the destination. Move
scoring mechanisms easily force pieces
onto such paths if they are not already
on them.
Figure 3 shows the situation where
H5 (value of 20) and F5 (value of 16)

175
are both set as desirable. Under these
circumstances, the optimal path for the
knight on C1 is unambiguous: from C1
to E2 to G3. This move sequence leaves
both options, F5 and H5, open. Note
t h a t moving the knight from C1 to B3
to D4, as in the previous example, is
now less flexible - an important chess
consideration.
5. T r e e S e a r c h i n g
The Planner score for each move
considered at an interior node of a
search tree, can be computed by looking
in the table for that piece. As one
descends the search tree, the scores
associated with each move in the
sequence are summed to give a net score
(white scores - black scores) that can be
used to help score terminal nodes. In
this manner, positions that were
achieved through play consistent with
long-range strategy (or alternatively,
with prevention of the opponent's
strategy) score more favourably. This
factor is particularly noticeable in
positional chess games. The scorcs
associated with each individual move
can also be used at the interior node to
help determine the order in which the
moves should be examined. Tree
searching is much more efficient if you
search the best move at the interior
node first [1]. If you are using an
alpha-beta tree pruning mechanism, this
can result in more cut-offs. The interior
node ranking mechanisms can use the
Planner scores as additional information
which does result in a better ordering of
moves and hence (minimally) smaller
search trees.
During a tree search, positions will
often arise that do not agree with
assessments made by Planner at the
root node. Events on the board can
change very rapidly, depending on the
moves made. The chess program must
be able to recognize when conditions
have changed enough to invalidate the

8 0 [0 4 0 9 0 9 0

7 0 4 0 5 8 4 18 5

6 0 0 4 8 9 10 9 8

5 0 4 0 9 0 21 0 24

4 0 0 4 8 9 10 9 8

3 0 4 0 5 8 4 18 5

2 0 0 4 0 9 0 9 0

I 0 0 N 4 0 9 0 9

A B C D E F G H

Figure 3

176
Planner tables. T h e Plan Selection
module computes a variety of status
information t h a t defines the position
conditions necessary for the plan. If
these conditions change significantly, it
is doubtful t h a t the plan is still reliable.
Therefore one has a standard against
which to measure the current position,
and to determir~e the validity of Planner
scores. If the two agree within certain
limits, the plan endures. Once the
current position's value disagrees with
the root position to a significant degree,
the Planner scores are ignored and play
no role in subsequent analysis for that
particular sub-tree. For example, if the
current plan is to block a passed pawn,
during the tree search in lines where the
passed pawn is captured, Planner's
scoring tables are turned off.
The status information is also used
on a move-to-move basis. At the root
node of each search tree, a comparison
is done between the features of the
position and the status information. If
they agree within a limit, the current
plan is continued and only the move
scoring tables are updated. If they
disagree, then the Plan Selection module
is called in to choose a possibly new
plan. This feature allows the program
to have a measure of consistency over a
series of moves.
6. R e s u l t s
Planner was originally interfaced
with the chess program Tree.frog (1974
North American Champion, 2nd place
tie in 1st World Championships). In
1980, a match was carried out between
Treefrog and Treefrog supplemented by
Planner. A set of 5 standard opening
positions was selected for the match,
with the programs playing each position
from both the white and black side.
The result was 8 wins and 2 draws for
the Planner version of Tree frog.
177
More recently, Planner has been
used in the University of Waterloo chess
programs Prodigy (1981 North American
Championships participant) and
Phoeniz. Both these programs play
consistently better chess with Planner
than without as numerous training
games have shown.
Analysis of games played by
programs using Planner have pointed
out some important problems
introduced by long-range planning.
The selection of plans by Planner
is acceptable, though far from perfect.
In most positions, a reasonable plan is
chosen and carried out reasonably
consistently. However, Planner can bc
fooled into poor plan selections resulting
in some pretty bad (but consistent!)
chess. One can make the excuse t h a t
these errors are a result of insufficient
chess knowledge, but the problem is
really more of inflexible knowledge.
Patterns for plans can come in various
guises under varying circumstances.
Any sort of non-generalizing knowledge
cannot hope to cope with all possible
scenarios properly.
Another problem is timing. The
program tries to maximize the score for
a position and thus likes the moves t h a t
give the highest scores from the move
scoring tables. But there are many
types of positions where the moves t h a t
are scored highly by Planner are better
delayed so as to achieve an even greater
effect on the position. A good example
is the pawn break. The program will
push the pawn forward at the first
possible opportunity because there is a
high score associated with doing this,
However, delay of the break until all
your pieces are in their proper position
may make the actual pawn break even
stronger.
Another problem is a version of the
horizon effect[8]. During a tree search,
when the program detects t h a t a plan is
no longer valid, it turns off the Planner
move scoring tables. The program then
tends to select lines of play which push
the plan termination condition to the
last ply of search (so as to maximize the
amount of Planner score it receives). In
a sense this problem is the opposite of
the first one mentioned - procrastination
vs haste. This problem was not evident
in programs that searched shallow trees,
but as the level of ability of programs
that have used Planner has increased, it
became a serious problem (directly
resulting in the loss of 1 tournament
game). As a result, in the chess
program Phoeniz the move scoring
tables are not turned off during tree
searching.
7. C o n c l u s i o n s
Planner has proved to be an
invaluable aid for increasing the playing
abilities of chess programs. At the
University of Waterloo, the succession of
chess programs Treefrog, Prodigy, and
Phoeniz have all used Planner to
advantage.
For Prodigy, a version of Planner
was implemented for endgame positions.
The program's structure is basically the
same as the one described in this paper.
However, endgame play requires
different types of plans and strategies
than does middlegame play. It is
interesting to note that for some
simplified endgame positions (king and
pawn endgames), Planner can actually
play winning move sequences with as
little as a one ply search, even though
the solution requires 25 ply. In these
positions, conventional programs fail to
find the solution because of the need to
look very deep. These shallow tree
searches are possible only because the
program has a plan that it executes by
making moves in the short-run (1 ply)
consistent with its long term objective
(25 ply).
178
8. A c k n o w l e d g m e n t s
Randy Goebel and Amy Goldwater
greatly enhanced the readability of this
manuscript,
9. References
[11 T.A. Marsland and M. Campbell,
Parallel Search of Strongly
Ordered Game Trees, Computing
Surveys 14(4), Dec, 1982.
[21 Joe Condon and Ken Thompson,
Belle Chess Hardware, Advances in
Computer Chess, vol. 3, Pergamon
Press, 1982.
[3] Mikhail M. Botvinnik, Computers,
Chess and Long-range Planning,
The English Universities Press
Ltd., London, England, 1970.
[41 H. Kaindl, Positional Long-Range
Planning in Computer Chess,
Advances in Computer Chess,
vol. 3, Pergamon Press, 1982.
[5] Jacques Pitrat, Using Plans in a
Chess Playing Program, 5th
International Joint Conference on
Artificial Intelligence vol. 2, 1977,
Cambridge, Massachusetts.
[0] Jacques Pitrat, The Behaviour of a
Chess Combination Program using
Plans, A dt,anees in Computer
Chess, vol. 2, Edinburgh
University Press, 1980.
[7] David Wilkins, Using Patterns and
Plans to Solve Problems and
Control Search, STAN-CS-79-747,
Computer Science Department,
Stanford, 1979.
[8] Hans Berliner, Chess as Problem
Solving: The Development of a
Tactics Analyzer, Department of
Computer Science, Carneige-Mellon
University, 1974.

[9] Jonathan Schaeffer, Long-Range

Planning in C3mputer Chess,
M.Math dissertation, Computer
Science Department, University of
Waterloo, 1980.

[10] Peter Frey, Che88 Skill in Man and

Machine, Springer-Verlag New
York Inc., New York, 1977.

179