Computer Bridge: A Big Win for AI Planning
Smith, Stephen J. J., Nau, Dana, Throop, Tom, AI Magazine
A computer program that uses AI planning techniques is now the world champion computer prograni in the game of Contract Bridge. As reported in The New York Times and The Washington Post, this program-a new version of Great Game Products' BRIDGE BARON program-won the Baron Barclay World Bridge Computer Challenge, an international competition hosted in July 1997 by the American Contract Bridge League.
It is well known that the game tree search techniques used in computer programs for games such as Chess and Checkers work differently from how humans think about such games. In contrast, our new version of the BRIDGE BARON emulates the way in which a human might plan declarer play in Bridge by using an adaptation of hierarchical task network planning. This article gives an overview of the planning techniques that we have incorporated into the BRIDGE BARON and discusses what the program's victory signifies for research on Al planning and game playing.
One long-standing goal of AI research has been to build programs that play challenging games of strategy well. The classical approach used in Al programs for games of strategy is to do a game tree search using the well-known minimax formula (eq. 1) The minimax computation is basically a bruteforce search: If implemented as formulated here, it would examine every node in the game tree. In practical implementations of minimax game tree searching, a number of techniques are used to improve the efficiency of this computation: putting a bound on the depth of the search, using alpha-beta pruning, doing transposition-table lookup, and so on. However, even with enhancements such as these, minimax computations often involve examining huge numbers of nodes in the game tree. For example, in the recent match between DEEP BLUE and Kasparov, DEEP BLUE examined roughly 60 billion nodes for each move (IBM 1997). In contrast, humans examine, at most, a few dozen board positions before deciding on their next moves (Biermann 1978).
Although computer programs have done well in games such as Chess and Checkers (table 1), they have not done as well in the game of Contract Bridge. Even the best Bridge programs can be beaten by the best players at many local Bridge clubs.
One reason why traditional game tree search techniques do not work well in Bridge is that Bridge is an imperfect-information game. Because Bridge players don't know what cards are in the other players' hands (except for, after the opening lead, what cards are in the dummy's hand), each player has only partial knowledge of the state of the world, the possible actions, and their effects. If we were to construct a game tree that included all the moves a player might be able to make, the size of this tree would vary depending on the particular Bridge deal-but it would include about 5.6 x 1044 leaf nodes in the worst case (Smith 1997, p. 226) and about 2.3 x 1024 leaf nodes in the average case (Lopatin 1992, p. 8). Because a Bridge hand is typically played in just a few minutes, there is not enough time for a game tree search to search enough of this tree to make good decisions.
Our approach to this problem (Smith 1997; Smith, Nau, and Throop 1996a, 1996b, 1996c) grows out of the observation that Bridge is a game of planning. The Bridge literature describes a number of tactical schemes (finessing, ruffing, cross-ruffing, and so on) that people combine into strategic plans for how to play their Bridge hands. We have taken advantage of the planning nature of Bridge by adapting and extending some ideas from hierarchical task network (HTN) planning. We have developed an algorithm for declarer play in Bridge that uses planning techniques to develop game trees whose size depends on the number of different strategies that a player might pursue rather than the number of different possible ways to play the cards. Because the number of sensible strategies is usually much less than the number of possible card plays, we are able to develop game trees that are small enough to be searched completely, as shown in table 2. …