borg@wintermute.sdsu.edu (T Borg) (01/25/91)
Title: Smart Game Board and Go Explorer : a study in software and knowledge engineering. (technical) Author: Kierulf, Ander; Chen, Ken; Nievergelt, Jurg. Journal: Communications of the ACM Feb 1990 v33 n2 p152(15) * Full Text COPYRIGHT Association for Computing Machinery 1990. SOFTWARE ENGINEERING AND KNOWLEDGE ENGINEERING Software engineering is an established discipline that has accumulated and codified more than two decades worth of know-how. Knowledge engineering, on the other hand, is an emerging discipline with lots of issues but, at least so far, little structure. Despite its lack of maturity the practice of knowledge engineering promises to have a noticeable impact on software engineering doctrine. The experimental nature of knowledge engineering goes hand-in-hand with a style of software development best characterized as 'exploratory,' which has not been much studied in traditional software engineering. Exploratory Software Development: Uncertain Resources, Open-Ended Goals The vast literature on software engineering discusses, almost exclusively, the production and maintenance of software as an industrial process: Predictable in its outcome, repeatable in its execution, and portable in its independence on particular individuals. Many conditions must be met for the managerial and technical processes advocated in software engineering to work. The principal requirement is that the designer knows fairly well what end product can be achieved (so it can be specified), what resources are required (so the product can be sized up), and how to build the product (so the production process can be planned). The source of all this knowledge is experience based on previous production of similar products. Conventional software engineering know-how works best when producing the (n + 1)st version of a compiler, text processor, or other well known software systems component or apllications package. A small but important class of software development projects meets none of the conditions above. For good reasons, such first-of-a-king projects are typically conducted in a manner diametrically opposite to traditional software engineering practice. Typical conditions include: * The designer has a clear vision of the direction of achievement, or "goal at infinity," but has no way to predict how far along this route progress can be pushed. * For any specified level of achievement, it is impossible to predict the resources needed, perhaps not even their order of magnitude. * Because nothing can be promised about the outcome, no long-term commitment of resources is made, and the only predictable budget feature is that the project has to be run on a shoestring. * Software development cannot be planned, as the outcome of each phase and step is unpredictable; it proceeds, mostly by trial and error, along lines of least resistance or greatest promise. * Last but not least, such a project is intimately tied to the particular individuals involved and reflects their personal characteristics. Removing a key individual will kill the project or transform it beyond recognition; assigning another team to do "the same" project results in a different venture. The rapidly spreading use of interactive applications has kept software products in a state of flux for more than a decade: Spreadsheets, painting programs, hypertext are just some of the products that lacked practical models a decade ago. All indications point to a continuation of the trend that essentially new types of software will continue to be developed, along with the bread-and-butter tasks of perfecting the next version of existing models. Thus it behooves the software engineering community to recognize that exploratory software development is an activity of long-term importance worth studying. Even a casual acquaintance with several exploratory software projects suggests that they proceed according to rules different than those postulated in the software engineering literature. It is not just a matter of developing a prototype or two before starting on the product, and it is definitely not a matter of going through half a dozen phases of a life-cycle that includes requirements analysis, specification, coding, and testing. The style of exploratory software development is linked so intimately to the individuals involved that one might be reluctant to search for common traits, expecting only to see talented and dedicated individuals "doing their own thing." The opportunity to observe several such projects by different teams has convinced us, however, that there are significant similarities. These include: * A blatant bottom-up approach to systems building: The system evolves around key routines and components that are built early, are perennially modified, and pragmatically combined in different ways in response to feedback. System behavior, far from being specified a priori, is an ever-changing result of these experimental set-ups. * At all times, have a running system, even if it is only a mini version of what you are striving for. Since specification ahead of time is out, observation of the program's behavior, and of the users' reactions, is essential at all times. * Keep your tools sharp! Building an environment useful for rapid prototyping is effort well invested, as code is never "finished," and the turn-around time needed to implement a new version or perform an experiment is critical. * Strive for a design that leaves as many options open as possible--tomorrow we may know better than today what option to exercise. * Keep your ears to the ground! A significant project spans years, and during its lifetime the surrounding circumstances change considerably--a good dose of opportunism is necessary to keep the project relevant and up-to-date. Software developed according to this philosophy evolves through selection a bit like natural systems do--with one important exception. A single team cannot afford to imitate prolific nature and spawn mutations to be developed concurrently. At any time, the cumulative experience of the entire project must be distilled into one running version. It is worth remarking, though, that in situations where several independent teams work on a similar goal, the analogy with natural selection, and the multitude of related species it creates, is apt--consider, for example, the many versions of UNIX in existence. The Unpredictable Complexity of Knowledge Formalization The development of an expert system, or any project that involves the formalization of an open-ended domain of human knowlege, adds specific difficulties associated with knowledge engineering to all the traditional problems of software engineering. The chief difficulty added by knowlege engineering is that hardly anything of importance seems to be predictable, and hindsight becomes the only reliable basis of judgment. This is a drastic departure from the norm of engineering development, which is based on the assumption that we know ahead of time what we will end up with. It forces computer scientists to look at the process of formalization in a new light. Computer science is the technology of formalization. If anythingis to be processed by computer, the rules of processing are expressed in a formal system. This system may be a programming language defined by a collection of hardware and software that includes a computer, an operating system, and a compiler; it may be a programing or specification language defined abstractly; or it may be a more traditional mathematical system built on axioms and rules of inference. The programmer may or may not think of his/her activity as a task in formalization--the point here is that, once a program has been written, it is a formal system. One can view computer science education as having two major goals: To teach a sufficiently rich arsenal of techniques of formalization, and, in projects and case studies, to impart as much experience as is feasible concernign the practical application of these techniques. Thus we expect, for example, that a systems programmer can formalize a communications protocol, and a systems analyst or database administrator can formalize the structure of payroll information. Both of these examples rely on the fact that the domain of knowledge to be formalized is closed, as opposed to open-ended, and of every limited size and complexity. The word 'knowledge engineering,' on the other hand, is typically used for domains of knowledge much larger and more complex than the examples above. Attempts at formalization capture only a small fraction of therelevant domain. This is true, for example, of standard microwords of artificial intelligence, such as chess. The designer usually cannot even formalize all of his personal knowledge of the field, let alone that possessed by the community at large. The literature on expert systems at times presents interviews of human experts as the way to capture knowledge, but this is really a technique of identifying knowledge, rather than formalizing it. Given this state of affairs, the knowledge engineer typically starts with an educated guess of what small part of the vast collection of know-how can be formalized and will result in acceptable performance, then repeats the following steps until patience or resources run out: Implement this subset, observe the outcome (it can always be improved!), and tune the knowledge base to achieve a hoped-for effect. This is a basic human mode of operation, but is not what traditional software engineering doctrine has been advocating, and is not what most software environments support. We illustrate these points with a study of an exploratory software development project with a large knowledge engineering component. Its goal, a program to play the Oriental game of Go, is exotic and needs explaining, including a brief survey of the history and current state of computer Go. A Program to Play Go As a study in exploratory software development and knowledge engineering, we present Explorer, a program that runs on the Smart Game Board and plays the Oriental game of Go. It took four years to build and perfect the Smart Game Board, and test it in two applications: An interactive Go calculator that provides basic tactics routines, and a program that plays Othello. By the Spring of 1988 this powerful programming environment and test bed had matured to the stage where a new member of the team, who focused on the analysis of strategic features of board positions, could implement a program to play the full game of Go during a summer of intensive work. In the Fall of '88, in its first test against other programs, Explorer tied for 2nd among 16 programs that competed in the 4th International Computer Go Congress in Taiwan, the unofficial world championship organized by the Ing Foundation. Explorer proved to be a fierce if somewhat unsteady fighter, whose play revealed some crass shortcomings. The team split soon thereafter, each group trying out its own cure to avoid Explorer's predictable lapses. As a consequence, Explorer retired from active competition and spawned two offspring. Both run on the Smart Game Board and both improved on their parent's record in their very first encounter. In the summer of '89, Go Intellect won the North American Computer Go Championship, and Swiss Explorer won the Go tournament at the first Computer Olympiad in London. We attribute these results to a mixture of good luck and a solid dose of sound software engineering practices. Although this project is unique in several ways, it is typical of exploratory software development in others. We believe there are lessons to be learned with respect to the interaction between software engineering and knowledge engineering. This case study illustrates the decisive importance of a powerful development environment. A large investment of effort in building the best software engineering environment we were able to devise, out of components that are well understood, made it feasible to experiment extensively in the poorly understood realm of knowledge engineering. Why Work on a go Program? Work on game-playing programs is always, in part, a hobby. But there must be other justification as well, because game playing programs, when pursued far enough that they can compete among the best, require several man-years of effort. Such justification is readily found, in an academic environment, in terms of education and research. Education. The idea of robots playing games of strategy has intrigued people since the invention of clockwork, but it remained for electronic computers to turn it into reality. Famous computer pioneers prepared the ground: John von Neumann created the mathematical theory of games, alan Turing and Claude Shannon devised techniques that allow computers to play chess [20, 22]. The concepts and techniques developed range from game theory to knowledge representation, and from heuristic search to program optimization. Many of these ideas have become an accepted part of computer science lore, and students should be exposed to them. The concepts are empirical more than they are theoretical: The typical question is not whether something can be done in principle, but how well it can be done within practical constraints. In computer science, a meaningful exposure to empirical concepts must be based on working programs. We have been conducting seminars on heuristic search and computer game playing in which the Smart Game Board serves as a workbench and test-bed that makes it possible for students to write and test a game-playing program of their own design in one semester. It was a seminar held in '86 over North Carolina's state-wide two-way teleclass network that brought the authors together in cooperating on a Go playing program. Research. A significant part of our knowledge of what computers can and cannot do in artificial intelligence comes from experiments with computer game playing--so much so that computer chess has been called the "drosophila of AI," i.e. the preferred test object for experimentation. This assessment is based on two very useful properties. 1) Games of strategy form microworlds of just the right complexity (simple enough to be easily formalized, hard enough to tax computational resources) to develop and test our growing arsenal of artificial intelligence techniques. 2) Progress can be measured accurately in terms of improved playing performance--a chess rating or a Go rank are much more objective measures than exist in most other applications of knowledge engineering. What to Work On? We took up game-playing programs as a side-line in 1983 based on a combination of factors: personal interest, the view that there was still unexplored land, and the conviction that knowledge engineering must be approached empirically in a microworld where performance can be measured objectively, accurately, quantitatively. There was a lot of experience and information about chess playing programs, and computer chess appeared to be in a relatively mature stage where success came from doing the same thing better and faster. Comparatively little was known about computer Go and other games. Go has a reputation for being the most profound game of strategy, thus may be one of the hardest to program, and hence a fertile field for experimentation. We are aware of four Ph.D. dissertations written on computer Go [5, 13, 19, 26]. In contrast to chess, computer programs that play Go were still in their infancy, playing so poorly that their performance was essentially off the accepted scale for ranking human players. An increased interest in computer Go could be expected; in particular in Japan, where Go is a national hobby, and the government-sponsored project on Fifth Generation Computer Systems greatly boosted research in artificial intelligence. How? The combination of 1) little existing experience, and 2) an anticipation that during the course of the project many competitor projects might emerge, caused us to approach the subject on a broad front, and to design a project that emphasized basics and could be redirected to focus on different goals depending on where progress appeared most promising as the work evolved. Rather than setting specific goals, we decided on a few directions, on "goals at infinity," and embarked on a journey that would lead as far as we could go. These directions included: 1. Design and build a workbench, later called the Smart Game Board, for the development of game-playing programs. What do various games have in common, what components can be shared among programs that play different games? This workbench quickly became a useful teaching tool--a skeleton program to be tailored to specific games in student term projects. Soon it became a useful vehicle to maintain and enhance an Othello program developed independently [9], and to implement Go-Moku in one semester. 2. The Smart Go Board [12]--a useful teaching and studying tool for the Go player to analyze, annotate, store, and print games. This would ensure a small but dedicated community of users to help in testing and improving the program. 3. Go tactics calculator, expert-guided search. Goal at infinity: Can a person play noticeably better using a Go tactics calculator than when he relies on his own wits? 4. Testbed for experimenting with strategies and techniques for playing a full game of Go. The last part of this article is devoted to 4), so let us briefly mention the earlier phase 3), where we attacked the seemingly easier problem of developing a "Go calculator," with a function analogous to that of a handheld numerical calculator. Its purpose is not to play Go against an opponent, but to assist a human player in those tasks that are better delegated to a machine because they require speed and accuracy, as opposed to expert judgment. The human player decides on strategy and calls upon the program to calculate tactical sequences of moves to achieve a well-defined purpose. As the program builds and traverses a search tree, the player directs the search and can interactively modify the board if he so chooses. This approach can be described as using computers as "amplifiers of human intelligence," rather than as autonomous intelligent machines. And rather than building a computerized expert system that tries to capture human knowledge in executable form, we investigated 'expert-guided search', where human experience and intuition guide the great processing power and fast and accurate memory towards fruitful goals. This emphasis on interactive user control investigates computer-aided human decision making. Games of strategy such as Go have always served as simplified models for decision making. In the modern era of decision support systems, it is reasonable to assume that programs that support gaming can serve as test beds for some aspects of computer support for decision making. A reasonably objective test of this game calculator is easy to arrange: does a player with calculator play consistently better than without? What can be Foreseen? When this project was started in 1984, hardly any guidance was available: A few precursors served as warning of difficulties to be expected, none provided a model to be followed. With hindsight gained through five years' worth of experience, it is interesting to compare some of the questions and expectations we had at the start of the project, and current answers. Foreseen: A Smart Game Board is feasiable as a useful hypertext medium for storing an annotated collection of games, and browsing through them. It can support a variety of games and run on a low-cost personal computer. Advancing technology quickly solved initial problems such as insufficient main memory and disk, low screen and printer resolution. The result justifies the years spent in cumulating detailed improvements: The Smart Go Board is being used by at least 100 Go players to manage their games. One professional Go master was it as a teaching tool to exchange games and comments with his remote students. Might have been foreseen, but the idea evolved during the project: It is feasible to develop a common user interface that fits entirely into one screen, powerful enough to handle many different games. Interaction with different games takes place using the same windows, and, to a large extent, the same operations. This is possible because the majority of operations provided by the Smart Game Board are defined on the game tree, and thus are game-independent. So far the user interface has proven to be adequate for Go, Othello, Go-Moku, and chess. Unforeseen: How hard is it to develop a useful Go tactics calculator? We expected to develop an interactive program capable of analyzing and solving clear-cut tactical tasks identified by an expert amateur user. This tactics calculator has proven to be much harder than anticipated, and so far is useful for only a very limited range of tactical problems: Mostly, complicated ladders and loose ladders, i.e. forcing sequences in capturing a block that has no more than 2 or 3 liberties at any time. With hindsight, of course, we can see why this problem is hard--the interface between human strategy and machine tactics requires difficult formalization of intuitive, fuzzy concepts. To substantiate this point, we can do no better than quote the operator of Deep Thought (DT), today's strongest chess computer, as it assisted grandmaster Kevin Spraggett in an elimination match for the world championship [7]: 'I was in the fortunate position of being able to watch and assist the possibly first-time cooperation between a grandmaster and a computer.... Other problems were related to "interfacing" DT with Spraggett or his seconds. It is indeed hard to translate a question like "can black get his knight to c5?" or "can white get an attack?" or "what are black's counter chances" into a "program" for DT, since it just doesn't have these concepts. Translating back DT's evaluations and principal variations (PV) is easier, but this information is incomplete most of the time. Indeed, the alpha-beta algorithm generally gives accurate values on the PV only (other lines are cut off), whereas a human wants to know why alternatives fail.' Given the weak play of today's Go programs, a useful Go tactics calculator is far off. Unforeseeable: How strong a Go program to aim at. The lack of experience prevailing in the fifties and sixties triggered useless predictions about the strength of chess programs that ranged from wildly optimistic ("a computer will be world champion within the decade") to overly pessimistic ("computers will never beat human experts"). Simiarly, there was no rational basis for predicting how strong, or weak, a Go program we could develop. With hindsight, observing that half a dozen independently developed programs that competed at recent computer Go tournaments are comparable in strength, one can conlude that a knowledgeable and dedicated small team can develop a 15 kyu Go player (this rating scale is explained later) with an effort of a few man-years. The Development of Computer Go A brief survey of the history and current state of computer Go serves to place our project in perspective. Compared to other games of strategy, in particular checkers and chess, computer Go started late and, until recently, progressed very slowly. Many people feel this is due to the inherent difficulty of Go--a view well expressed in [4] as "The Game of Go--The Ultimate Programming Chalenge?" Work in Computer Go started in the early 1960s [18] and intensified with the Ph.D. dissertations of Zobrist [26, see also 23] and Ryder [19, see also 24]. Zobrist relied on pattern recognition, Ryder on tree search. Both of these approaches had already been explored in chess, where the latter, in particular, has proven its value beyond doubt. But although these approaches capture part of what Go is about, neither program played as well as a beginner plays after just a few games of experience. Humans use pattern recognition to a large extent, but their patterns are more complex and abstract than those used by Zobrist. And pure tree search runs into the hurdle that the branching factor of Go is significantly larger than that of other games on which this approach has been tried. Selective search is more important for Go than it is for chess, and setting goals to focus the search calls for insight into the posiiton. The Reitman-Wilcox program [17], based on a representation of the board that reflects the way good players perceive the board, was a step forward. They concentrated on strategy, adding some tactical analysis late in the project. Their program only reached the level of a novice player. Bruce Wilcox analyzed the strong and weak points of his first program, then rewrote it from scratch [25]. Since 1985 activity in computer Go has mushroomed. A strong Go-paying program was a goal of the Japanese "Fifth Generation" project, but was dropped (too hard?). Several dozen individuals and small teams are now involved in Go programming, and these efforts are beginning to bear fruit. The annual International Computer Go Congress, organized since '85 by the Ing Foundation of Taiwan, has provided an arena for competition and a yardstick for assessing progress. The best Go programs now play at the evel of 12 to 15 kyu, distinctly better than human beginners. But they have a long way to go as compared to chess, where commercial machines have achieved master ratings. SMART GAME BOARD The Smart Game Board supports two kinds of experiments with game-playing programs. First, as a hypertext medium: Its user interface is designed to help serious players study the game in ways that are impossible without a computer. Second, as a workbench for programming games: Its structure encourages experimentation with different search algorithms and strategies. Neither of these functions is bound to any one game; originally designed for Go, the Smart Game Board was expanded to include Othelo and chess. What is It? A Tool to Assist Game Players The Smart Game Board is a tool to assist game players in the many activities they now perform on a wooden board and paper: Playing, teaching, discussing, analyzing, studying, recording and printing. A personal computer should make a better tool for some of these activities, but, as with any new application, it is not a priori clear what functions a game workbench can and should provide. At the very least, it must provide the functions of a wooden board. This is much harder than it seems, because the board is not just used to pay moves: Players talk while pointing at it and rearranging stones at will. In computer jargon, the board is a shared workspace that supports very fast and convenient editing. A wooden board is more agreeable than a computer screen, and players wil only switch to the computer if it offers additional benefits: Easy annotation, ready access to a library of games and openings, help with tactical analysis, or a strong opponent. The Smart Game Board has passed the threshold of usefulness: About a hundred players use it, many say it is their preferred way of studying the game, it has been used at tournaments to record games and between rounds as an opening library. Its versatility is proven by applications we had not directly designed for: One-on-one lessons by professionals, and taking notes during lectures on Go. What Games have in Common There is no point in trying to make the Smart Game Board general enough to be used for any kind of game--games differ too much to be all brought under one hat. Our choice of Go, Othello, and chess reflects personal and professional interests, but we think they represent a sufficiently diverse sample of an important class of games: Two-payer board games with perfect information. How do these characteristics make it easier to build a game-independent user interface? * Two players: Limiting the game to two players, Black and White, reduces the complexity of the interface without unduly restricting the set of games. * Board game: The board is a convenient visual representation of the current state of the game, and makes it easy to enter a move by clicking or dragging the mouse. Throwing dice or drawing cards would make it more complicated to enter a move. * Complete information: If each player always has access to the complete state of the game, there is no need to hide information from one of the players. * Sequence of moves: Most games evolve as a fixed sequence of discrete actions (moves) by the players. Action games ike PacMan on the other hand, where moves come any time and timing is critical, do not fit this model. These common traits allow us to implement the functions presented below independently of any particular game. Renju (Go-Moku) was included in an earlier version; other games that could be added without major changes include: Kalah, Checkers, and Connect Four. It would be harder to integrate card games like Blackjack, Bridge, and Poker, dice games like backgammon, or word games like Scrabble. We discuss game-specific differences in more detail later. An Editor for Game Trees. The Smart Game Board is an editor specialized for game trees, and its user interface shows similarities with other editors. A game is treated as a document that can be opened, viewed, modified, and saved. We concentrate on those aspects that distinguish the Game Board from other editors. The underlying structure of a game is a tree, where a list of properties is associated with each node. In its simplest form, the tree degenerates into a sequence of nodes, each with exactly one property, a move. The generality of a tree is needed to let the user experiment with different sequences of moves while keeping the original game intact. The tree is extended to a directed acyclic graph for opening libraries (different move sequences may lead to the same position). The concept of a list of properties at each node is needed to store attributes such as comments referring to the move, marks declaring the move to be good or bad, or the time left at this point in the game. A game is replayed by traversing the tree: Advancing by one node executes the move stored at that node. It is useful to provide various ways of moving about the tree: Depth-first traversal, go to next/previous branch point or terminal node, or search for nodes with specific properties. General tree editing commands allow one to copy properties, nodes, and entire subtrees from one game to another. More powerful operations on game trees include backing up values in min-max fashion, or sorting the branches according to the number of terminal nodes in each subtree. Go, chess, and Othello players intuitively understand the concept of a game tree, as it is the simplest notion powerful enough to capture what they are doing while analyzing a game. If the user enters no alternative moves and thus grows no branches, the tree degenerates into a trunk corresponding to the sequence of moves actually played. Playing a move automatically adds a node to the currently active branch of the tree, adds a move property to that node, and executes the move. Simpler interfaces could be designed for programs that offer fewer services, such as merely playing against a computer, or looking up an opening library. In contrast, the Smart Game Board is a general tool that helps serious payers in unexpected ways. Database for Games. Database software dedicated to games, such as ChessBase [16], is rapidly becoming an essential tool for serious players, as it helps them track large collections of games, standard openings, statistics, etc. Users can order games by openings, play through famous master games, or get a printout of the games their next opponent recently played. Today, games from major tournaments are quickly made available to subscribers in machine-readable form. The Smart Game Board provides similar functions, but is not yet as good a database system as we aim at. It has been used to organize 1300 Othello games and therefrom create a library of standard Othelo openings. Given an opening position on the board, it retrieves all matching games from its database, as shown in Figure 1. Game Server. Some users working on their own electronic game board or game-playing program want to have access to Smart Game Board's functions from their own program. For example, it can be used as an opponent to test the strength of their programs, it might extract a game from the game library, or it could provide a collection of positions for statistical analysis. For that purpose, the program provides a serial interface where most functions availabe to the user can be accessed with textua commands. The concept of a game server helps us test and tune our Go program, with different versions of the program playing each other overnight. More work is needed to turn this personal game server into a service people can connect to and play games against. Structure of the System The structure of the Smart Game Board is designed to separate game-specific from game-independent aspects. It provides slots where each game can plug in its specific routines for the rules (egal move recognition and execution), the user interface (board display, move input, menu functions), and an optional playing agorithm. A search engine provides depth-first search and iterative deepening based on game-specific routines for move generation, positive evaluation, and time control. The program is written in SemperSoft[TM] Modula-2 under MPW (Macintosh Programmer's Workshop) and runs on the Apple[R] Macintosh.[TM] We lack the resources for porting it to other systems. The program now consists of a total of 44,000 lines of code (including definition modules and comments, excluding blank lines). The distribution among the components is shown in Table 1. The Go program compiles to 500 kBytes of object code, the Othello program to 250 kBytes. In addition, at least 150 kBytes are needed for data structures; if more memory is available, a larger has table and a larger tree are allocated. Game-specific modules make their presence or absence known by installing procedures in some common lower-level module. This structure facilitates experimentation with different search algorithms as well as different games, and it allows us to configure different versions of the program. While handling a command, the program switches back and forth between game-specific and game-independent routines several times. For example, a click on the board intended to enter a move triggers a call to a mouse-tracking routine. This routine is game-specific so as to give feedback appropriate to the game, e.g., in the case of illegal moves. Once the move is recognized as legal, a new node is added to the tree independently of the type of game. Then another game-specific routine is called to execute the move stored in the node. Implementing Go, Othello, Chess, and Nine Men's Morris So far, Go, Othello, chess, and Nine Men's Morris (Muhle) have been implemented. Go came first and determined structure and user interface. Integrating an existing Othello program in the Go framework caused only minor structural changes, as Go and Othello are superficially similar: Both have a board with black and white stones, stones are added to the board and never moved, the controlled territory at the end of the game decides the winner. Adding chess, however, required major surgery to make more operations game-dependent, such as move input, move representation, and board editing. Whereas in Go and Othello a move is given by a point on the board, chess has from--to moves and several kinds of pieces. 'Minor' differences cause delicate program changes if the Smart Game Board is to retain an elegant structure throughout its evolutionary adaptations. For example, moves are counted by plys in Go, but as a pair of white--black plys in chess. The consequence is that a simple incrementing statement in a display routine gets replaced by an interpreter for a game-specific descriptor for move-counting and displaying. Nevertheless, adding chess to the Smart Game Board was a minor task compared with implementing even a rudimentary chess user interface from scratch. A program that plays Nine Men's Morris was recently added in a few weeks of work. It benefited greatly from the changes due to chess and added no new requirements. Go and Othello programs that run on the Smart Game Board have competed successfully in several tournaments. The original Othello algorithm included in the Smart Game Board was Brand, which placed second at the 1982 North American Computer Othello Championship in Evanston. Recently, a better Othello program, Peer Gynt, was created by writing a new evaluation function and improving the time control. This work was done in only two man-weeks by using many existing building blocks from Brand and from the Smart Game Board. An early version of Peer Gynt placed third at the 1989 North American Computer Othello Championship in Northridge. The chess module is not intended to play, only to manage game collections. Nine Men's Morris (programed by Ralph Gasser) plays a fair amateur game, but so far we have found no computer opponents to challenge (none were present at the London Olympiad in August 1989). Most of the Smart Game Board's user interface is embodied in a control panel common to all games (Figure 3 shows it in a window at the top left of the screen). Game-independent operations are defined as motions on a game tree. Game-specific operations (e.g. setting up positions in chess, entering marks for annotating Go games) and status information (e.g. number of captives in Go) are provided in a menu specific for each game. What does it take to add another game to the Smart Game Board? A game-specific module that implements two functions: * Recognize, execute, and undo legal moves. * Display the board and track move input. Go-Moku, for example, is played on the same board as Go, and thus required no change to the board display. If the surface of a new game differs significantly from any of the implemented games, it is probably easier to change some parts of the Smart Game Board to better accommodate this and future games, rather than forcing the new game into the current framework of the Smart Game Board. EXPLORER Characteristics of Go Assuming the reader knows little or nothing about Go, we attempt to provide some intuition for this game's domain of knowledge, in part by comparing Go to chess. Several excellent introductory books are available from [3]. Go is a two-person game of perfect information in the sense of game theory; at all times, both players know the entire state of the game. The players alternate placing a black and a white stone on some empty intersection of a 19 by 19 grid. Once played, a stone never moves, but it may disappear from the board when captured. A player's objective is to secure more territory than his opponent, counted in terms of grid points. In the process of surrounding territory by laying down a border of stones that must be 'alive,' fights erupt that typically lead to some stones being captured ('killed'). Much of the difficulty of Go comes from the fact that during most of the game, few stones are definitively alive or dead. Stones are more or less vital or moribund, and their status can change repeatedly during the course of a game, as long as the surrounding scene changes. Only when the game has ended can all stones be classified definitively as alive or dead. Thus 'life or death,' the key concept of Go, exhibits a split personality. As an opeational concept during the game, it is the most important factor in estimating potential territory and for assessing the chances of battle, but is rather fuzzy. It becomes more and more precise as the game progresses, and is a well-defined concept used for counting territory when the game has ended. The game ends when neither player can find a profitable move and all points are classified as one of black, white, or no-man's-land. This situation typically arises after about 200 to 300 moves have been played, with anywhere between 60 and 90 percent of the 361 grid points occupied. Whereas in chess we count a move (by a white piece) and counter-move (black piece) as a single move, in Go we count the placement of each single stone as a move. Even keeping in mind that a Go move corresponds to half a chess move (a 'ply'), it is evident that a Go game can take a long time. Professional games last one to two full days. As an extreme example from the 1988 Honinbo Title match, the defending champion Takemiya spent 5 hours and 7 minutes on a single move. The rich tradition of Go records instances of games that took months. Kawabata Yasunari, winner of the Nobel Price for Literature in 1968, considered his novel 'The Master of Go' [8] to be his finest work. It is the chronicle of a single game, played in 14 sessions from August through December of 1938, a contest for supremacy between the heretofore invincible old Master of Go, Honinbo Shusai, and his younger challenger, Kitani Minoru. It is a moving tale of the contest between tradition and change, and, ultimately, between life and death. If chess is a model of a single battle (as fought thousands of years ago), Go is a model of war: Typically, several loosely interacting land-grabbing campaigns and battles proceed concurrently. Go is a great game of synchronization: The stronger a player, the better he is able to coordinate his campaigns and disrupt the coordination among enemy forces. Multipurpose moves are the most effective, such as a 'splitting attack' that wedges in between two enemy groups, or a move that threatens to kill an enemy group and extends one's own territory at the same time. Typically one player has the initiative, called 'sente,' which enables him to play strong threats that leave the opponent little choice but to respond locally. Thus the player with sente can choose the field of action to suit his goals, whereas his opponent, said to be in 'gote,' "follows him around the board." The sente/gote relationship alternates between the players, but among opponents of different skill, the stronger player will manage to keep sente most of the time. Intuition and experience let a player estimate the numerical value of each move he considers. In the opening, a typical move may be worth about 20 points (of 'equivalent territory'). Move values may be highest in the middle game, but then they decrease steadily towards the endgame, where fights may erupt over a single point, or even 'half a point.' This phenomenon of decreasing value of a typical move as the game progresses causes timing to be of the utmost importance. If a move is estimated to be worth x points in a local context, it must be played at just the right moment, when the value of other moves is also about x. If played too early, the opponent may ignore this move and reply with a bigger one elsewhere, perhaps gaining sente. If played too late, when the value of other available moves has diminished, the opponent may prevent it, even at the cost of ending in gote. Players analyzing a game are always debating which move, among several good ones, is 'the largest.' A handicap system makes it possible to balance players of different skill without changing the nature of the game much. The weaker player starts by placing anywhere from 2 to perhaps 13 stones on the board. In Japanese Go, these stones are placed in a fixed pattern on 'handicap points.' In Chinesse Go, the weaker player places them anywhere--he starts with x free moves. The handicap system defines a fairly accurate rating scale, illustrated in Figure 4. Player A is x stones better than B if the chances become equal when B receives x handicap stones. Playing strength of amateurs is measured on a scale where one unit corresponds to a handicap stone. A very weak player may be 20 kyu, implying that he receives 10 handicap stones from a 10 kyu, who in turn receives 9 handicap stones from a first kyu. A first kyu 'takes Black,' i.e. plays first, against a first dan, who receives 5 stones from a 6 dan. That's about as high as the amateur scale goes. Above that, there is a separate scale for professionals, from the first (lowest, perhaps equal to an amateur 6 dan) to the 9th (highest). The professional scale has a finger grating: 9 skill levels are compressed into a difference of about two handicap stones. As computer Go is in its infancy, one would like to build on the mature experience with other games, but such experience does not transfer readily. At chess, for example, computers owe their spectacular prowess more to the computer's speed at searching than to its knowledge of chess lore. But experience with the computer chess approach of full board search does not apply directly to Go, for two reasons: * Branching factor. As Go is played on a 19 * 19 board, the number of legal moves decreases from 361 at the start to several dozen at the end, creating a tree with an average branching factor of about 200, as compared to a branching factor of about 40 legal moves from a typical chess position. This larger fan-out may be compensated partly by the fact that in Go a greater number of move sequences (permutations of each other) lead to same position than is the case in chess. (This phenomenon is due to the fact that almost all Go moves onto an empty grid point are legal, thus they can be played at any time, whereas many chess moves cease to be legal after some other pieces have moved). Thus transposition tables that detect positions analyzed earlier promise to be relatively more effective in Go than in chess. Still, we must assume that the vastly larger search space of Go greatly reduces the depth of feasible search. * Position evaluation. Material and mobility, the dominant factors in chess evaluation functions, are easily computed. In Go, possession of territory is the closest equivalent to material possession in chess, but its evaluation is much more subtle: Except at the very end of the game, a player's claim to territory can always be challenged. Go has no clear analog to chess mobility; perhaps 'shape' comes closest, but good and bad shape are hard to measure. Whereas success in computer chess was achieved mostly by sidestepping the issue of knowledge engineering, and using fast search to compensate for meager chess knowledge, the analogous recipe is unlikely to lead to comparable success in Go. The insight that both domain-specific knowledge and search are of critical importance makes Go a more diverse and balanced test bed for artificial intelligence research than chess is. Computer Go may well become the new "drosophila of AI." Despite the large branching factor, strong players routinely look 10 to 20 moves ahead when a fight demands it--an activity called 'reading.' This perplexing term suggests that a player, at that moment, is not free to let his imagination roam, but simply has to discover what is given--whether a plausible, perhaps forced, sequence of moves works or does not. Go does know the concept of narrow and deep search, as does chess, but with a difference. 'Reading' is limited to a local scene, say a 5 by 7 corner, and never extends to the full board. Even if reading guarantees a win in a local battle, that does not necessarily mean much--the enemy might ignore this battle and get compensation elsewhere. A separate, more intuitive mental act is required to assess the relevance of such a local search to the overall situation. So far, there is no alternative to the vast amount of Go knowledge accumulated by analyzing thousands of professional games each year, compiled and distilled in hundreds of Go books and journals. Explorer is designed to explore the feasibility of a knowledge-based approach to computer Go, augmented by focused tactical lookahead in local fights. What Aspects of Knowledge Engineering are Relevant to Go? It is useful to distinguish four major steps in the task of formalizing knowledge: Acquisition, selection, representation, and use. The nature and difficulty of each step differs from application to application. Acquisition and representation are most widely discussed in the literature, but turn out be non-issues in our project of formalizing Go knowledge. Selection and use, on the other hand, are critical. Knowledge acquisition. How do you get at the subject matter knowledge that you may want to capture? In contrast to other applications where this knowledge may be scattered and needs to be painstakingly assembled, we have all the Go knowledge at hand necessary at this stage of our project--mostly as the experience of Ken Chen, amateur 6 dan. It is interesting to reflect on the fact that most progress in computer chess is due to amateurs of medium playing strength--strong chess players were evidently not essential to the development of champion chess machines. This reflects the fact that computers can play amazingly powerful chess without much explicit chess knowledge. We expect that explicit representation of game-specific knowledge will be more important for Go than for chess. Knowledge selection. Selecting a 'domain of discourse or competence' that matches the program's abilities is the crucial task. At this stage it is hopeless to develop a Go program by trying to capture as much Go knowledge as possible. And if we managed to get a lot of knowledge into a system, it would probably get "confused" and not know how to use it. The key design issue in this knowledge engineering task is an expert assessment of what small part of the vast collection of Go lore can be programmed and will result in increased playing strength. Emphasizing fundamentals, we try to make Explorer understand concepts such as: What stones are dead and should be given up, what groups are unsafe and should be protected or attacked, what blocks are important and deserve high priority. Knowledge representation. The question as to whether this knowledge is explicitly represented, say as rules in some appropriately chosen notation, or implicitly in program fragments, has been decided by pragmatic considerations of expediency. At this early stage of the Explorer project, the choice is overwhelmingly in favor of procedural representation of knowledge--there is less overhead in getting started. Some aspects of Go knowledge, such as the beautifully geometric nature of patterns, clearly invite the design of a pictorial language to specify condition-action rules--for example, as generators for 'tesuji' moves, the trademark of a highly skilled player. Such notations have been developed [15], but their design and efficient implementation is a project in its own right. [21] is another example of explicit knowledge representatin, where patterns are encoded not pictorially, but verbally in terms of standard Go concepts. In contrast, we have chosen not to tackle the general issue of assessing advantages and disadvantages of various representations of knowledge, but to focus on the specific question of what is feasible for a program under continuous development that has to make a move in 20 seconds on the average. Putting knowledge to good use. If knowledge selection is the key design issue, knowledge use is the key implementation problem. The major source of difficulty is the fact that human knowledge is ubiquitously contradictory--for every proverb there is a counter-proverb. In Go, the goal of maximizing territorial claims contradicts, or at least competes for resources against, a dozen other goals, such as influence, safety, making good shape, attacking or restraining opponent forces. Explorer has two dozen move generators that all scream for their respective goals. In a later section we show how the structure of Explorer attempts to coordinate and filter their screaming. Go Knowledge: Design and Windfall Among the Go concepts designed into Explorer, influence is the most basic. Any stone radiates influence across the board: Its influence peaks at the location of the stone, and decays exponentially with distance. The superposition of the influence of all the stones on the board creates a field of force, a terrain that determines the structure of the board at this moment. Another basic concept of Go is that of a block: A set B of stones of the same color such that any two stones in B are connected by a sequence of stones in B, with any consecutive pair horizontally or vertically adjacent. A block is 'strongly connected,' and its stones die and are removed in unison when they lose their last 'liberty,' i.e., when there is no free point adjacent to any stone in the block. Blocks, more than single stones, are the basic building blocks of Go positions. 'Block' is a rigorously defined concept essential for checking the legality of moves, but a block is too small a unit for discussing the quality of moves. For this we need two higher concepts, 'chain' and 'group,' that turn out 'o be fuzzy. The intent of these concepts is clear, but their definition is not. A chain is a set of blocks that, under normal circumstances, can be connected into a single block at will, even against (most) measures taken by the opponent. A chain is a 'potential block,' and for purposes of planning can be treated as such. Many chains will turn into block as the game progresses, but there are exceptions: A higher level of planning may decide that the connectivity of a particular chain is not worth preserving (for example, during a 'ko fight'). A group is a set of chains that typically fight together--an attack on any chain in a group is an attack on all of them. Like an army that can operate and survive independently, it has a claim to territory, and many groups will turn into the boundary of a single territory as the game progresses. But there are lots of exceptions--groups split and merge routinely, perhaps according to the players' plans, often dictated by the unpredictable whim of the fortunes of war. Figures 5-8 illustrate these concepts, and the results of Explorer's analysis, on half a board in the early stage of a game. There are three nontrivial blocks (see Figure 5): The two stones labeled 11, two adjacent stones labeled 9, and three adjacent stones also labeled 9. All other blocks consist of a single stone. The labels identify chains. The two diagonally adjacent stones labeled 12 are not currently a block, but can be turned into one whenever black desires, as white would need two consecutive moves to separate them. The same argument explains chains 9 and 6. The two chains 7 and 11 are connected for most practical purposes, but if a fight erupts later on, white might wedge in between and separate them. Explorer considers them to be two chains, not one. Figure 6 shows the combined influence wielded by all these stones, measured on a scale from 1 (low) to 64 (high) in favor of black or white. As an example, notice how the gap between chains 11 and 7 in Figure 5 is under a strong black influence of 50 units; at the moment, this square is under black's control. The lower right corner is under very strong influence exerted by chain 9, and will almost certainly turn into white territory. The black stone 8 is dwarfed by the white chain above it, and thus exerts little influence. It will most likely end up as a prisoner inside white's territory, but before that fate is final, it has some nuisance value ('aji')--it might link up with chain 12, or, less likely, support a black invasion of the corner. Influence combines with chains to identify groups, shown in Figure 7 labeled by their group safety. Safety ranges from 0 (hopeless) to 64 (totally safe). The two chains 11 and 7 in Figure 5 are now clearly identified as a single group, a fighting unit. So are the single stones labeled 10 and 13 in Figure 5. Experience shows that these two stones, or any two stones on the third line separated by two empty spaces, control the territory between the below them; this know-how is preached in every beginner's book. Explorer has no explicit concept 'two stones on the third line separated by two empty spaces,' and thus can have no explicit rule about them. But Explorer seems to know this fact anyway, as reflected by the relatively high influence on these points, as shown in Figure 6. The influence measure was tuned to produce a reasonable result on such standard configurations. Unlike a collection of explicit rules that can never capture all situations, influence applies to all configurations, and gives reasonable results for most. It is also used to define a territorial claim for each group, shown shaded in Figure 7. This analysis of the board is updated after each move. Figure 8 shows the effect of a single move in the position of Figure 7. Left: A black invasion lowers the safety of white's 2-stone group from 47 to 13, and enhances the safety of black's group to the right from 47 to 51. Right: A white 'peep' that threatens to break black chain 6 drastically reduces its safety from 46 to 28 and 4. A last comment on knowledge selection. Explorer is a weak player playing other week players who are likely to exhibit typical beginners' shortcomings in their repertoire of techniques. It is tempting to design tricks into it, that is, schemes and techniques that stand a good chance of catching a novice unaware, but are basically unsound and will be refuted by an alert stronger player. Inspired by Bobby Fischer's famous creed: "I don't believe in psychology, I believe in strong moves," we tried to avoid falling into this trap. Although tricks might lead to short-lived success, they are sure to lead into a dead end, as tricks, by definition, contradict general truths, and will only aggravate a problem inherent in knowledge engineering: That different rules contradict each other. Any expert player will recognize the Go concepts we aim at as belonging to the classic fundamentals of Go lore. Structure of Explorer Explorer's knowledge is represeted internally in four different ways: (1) Relationships among stones on the board are represented by three types of frames: Blocks, chains, and groups. Each has eight to thirty slots, filled by attached procedures at the start of each move decision cycle. (2) Knowledge concerning local urgent Go patterns is implemented as pattern recognition procedures. (3) Josekis, local urgent moves in a corner opening, are stored separately as a tree on disk. (4) Knowledge concerning moves to achieve specific goals is scattered in two dozen move generators in implicit production rule form. Explorer's Go knowledge is the major sourcefor its decision making. Note that with the exception of tactical information, Explorer's knowledge is all derived from the present position. The move generation and selection process is shown in Figure 9. Experience and Current Work Reviewing the games Explorer played in the November 1988 International Computer Go Congress in Taiwan, and in human tournaments in New Jersey and Oklahoma in early 1989, we observe that our knowledge-based approach to computer Go is feasible for developing a low-related amateur. Knowledge is power: Its knowledge of group safety and block values alone gave Explorer an advantage over most other Go programs, as reflected in its strong performance in large scale fighting during the mid game stage, in most cases making end game play irrelevant to the win/loss results. As is the case in chess, a computer's style of playing is different from people's. Explorer committed bigger blunders than its human opponents, but often exhibited better positional understanding than human players of equivalent strength. Explorer is now a non-voting member of the American Go Association rated 15 kyu. With that official status it accomplished its purpose as a guinea pig and we immediately raised our level of ambition. Ken Chen believes in capturing crucial Go knowledge. He redesigned the position analyzer and produced Go Intellect, a program with a much improved understanding of Go. Anders Kierulf produced Swiss Explorer, a relatively solid player that improved on the components Explorer already had. In August '89 Go Intellect won the North American computer Go championship at Rutgers 4:0,and a week later in London Swiss Explorer won the Computer Go Olympiad in a 10-player round-robin tournament 8:1. Experience with Explorer and its improved successors clearly shows that using an additional source of knowledge to advantage is much harder than making the additional knowledge available to the system. Knowledge may backfire--more knowledge does not necessarily mean better performance. Different sources of knowledge will suggest different urgent moves that conflict with each other. The coordination of all knowledge sources in the system is the hardest knowledge engineering task in the Explorer project. Some knowledge of importance to human problem solvers amy be of little value to a machine. For example, human players memorize standard corner opening sequences, called joseki, because they are safe and save a lot of thinking. It is easy to implement such book knowledge, and Explorer has a large joseki library on disk [6]. But it takes considerable strategic understanding to take advantage of sophisticated opening sequences, and today's programs are lacking in this respect. During computer Go tournament, we turned Explorer's joseki option off, in order to increase the chances of middle game strategic fighting, where we felt Explorer had an advantage over other programs. Almost all Go knowledge is heuristic, and thus imprecise. We continually attempt to refine our programs' knowledge in order to reduce conflicts and improve performance, and investigate additional Go concepts that can profitably be captured and used. As computer chess has proven repeatedly, game playing is an experimental subject where predictions are difficult. But we believe that an expanded pattern library may capture part of the concepts of tesuji and aji, and serve as move generators that focus search on goals that would otherwise be lost beyond the horizon. Explorer had no concept of one of the most important aspects of Go: Coordination among several battles, as discussed in Section 1. Synchornization of campaigns is a major extension beyond our programs' current structure. As a step in this direction, we have experimented with making use of the concepts of 'sente' and 'gote' in the endgame, where most scenes of action are independent [11]. Tactics is the one aspects of game-playing amenable to exact calculation. Explorer's computing power was woefully inadequate for solving tactical problems it was aware of. Improving tactical prowess is an open-ended route to a stronger Go program--no inherent limitation can be seen as yet. Strong chess machines use special-purpose hardware to generate and evaluate 100 to 1000 times more positions per second than a conventional microprocessor could. We are not aware of any work on Go hardware, but that's an obvious approach to investigate. What motivates researches to pursue this never-ending race for stronger computer players? Computer game playing is one of the few cases in the fuzzy area of knowledge engineering where performance and progress can be measured with remarkable accuracy, and the causes that affect performance can be identified. Computer chess, for example, has shown that you do not need to understand much about chess at all in order to play at the level of an international master, all you have to do is to look at 1 million positions per second. This insight may not generalize beyond chess, but it is an impressive statement about the power of computation. CONCLUSION Computer Go stands today where computer chess was 20 years ago. Among dozens of programs, each one seems to follow its own approach, and the most visible characteristics they share are a very low amateur level of play, and a lot of hope. It was impossible, two decades ago, to predict with any degree of assurance how far and how fast computer chess would progress, and it is impossible today to predict how successful computer Go will be, and what it takes to get there. The only road to insight and progress is hard, trial-and-error experimentation. Explorer is one data point along this road. It tackles a difficult issue head on: Can a dumb program make good use of classical Go knowledge? Acknowledgments. Thanks to Bill Hargrove, Martin Muller, Monty Newborn, Jim Stein, and Ken Thompson for helpful comments. REFERENCES [1] American Go Association, P.O. Box 397, Old Chelsea Station, New York, NY 10113. [2] Computer Go. D.W. Erbach, Ed., 71 Brixford Crescent, Winnipeg, Manitoba R2N 1E1, Canada. [3] Ishi Press International, 1400 North Shoreline Blvd., Bldg. A7, Mountain View, CA 94043. [4] Bradley, M.B. The Game of Go--The Ultimate Programming Challenge? Creative Computing 5, 3 (Mar. 1979), 89-99. [5] Friedenbach, K.J. Abstraction hierarchies: A model of perception and cognition in the game of go. Ph. D. dissertation, Univ. of California, Santa Cruz, 1980. [6] Ishida, Y. Dictionary of Basic Joseki, Vol. 1, 2, 3. [7] Jansen, P. DT as Spraggett's second in Quebec. Msg on electronic news, Feb. 17, 1989. [8] Kawabata, Y. The Master of Go. Perigee Books, NY, 1981. Originally published in Japanese, as 'Meijin', in 1951. [9] Kierulf, A. Brand--an Othello Program. In M.A. Bramer, Ed., Computer Game-Playing: Theory and Practice, 197-208, Ellis Horwood, Chicheester, 1983. [10] Kierrulf, A. Computer Go Bibliography. Part 1 in [2] (Winter 1986/87), 17-19; part 2 in [2] 1, 3 (Summer 1987), 15-19. [11] Kierulf, A. Human-Computer Intersection in the Game of Go. In "Methodologies for Intelligent Systems", Z.W. Ras and M. Zemankova, Eds., North Holland, 1987. [12] Kierulf, A., and Nievergelt, J. Computer Go: A smart board and its applications. Go World No. 42, Winter 1985/86, 62-65, Ishi Press, Tokyo. [13] Lehner, P.E. Planning in adversity: A computational model of strategic planning in the game of go. Univ. of Michigan, Ph. D. dissertation (1981). [14] Levy, D.N.L. (Ed.). Computer Games II. Springer Verlag, New York, 1988. [15' Mano, Y. An Approach to conquer Difficulties in Developing a Go Playing Program. J. Info. Proc. 7, 2 (1984), 81-88. [16] Nunn, J. Life with ChessBase. ICCA J. (International Computer Chess Association) 11, 2/3 (June/Sept. 1988). [17] Reitman, W., and Wilcox, B. The structure and performance of the interim.2 Go program. In Proceedings of IJCA-6 (Tokyo, August 20-23, 1979), 711-719. [18] Remus, H. Simulation of a learning machine for playing Go. In Proceedings of IFIP Congress, North Holland, 1962. [19] Ryder, J.L. Heuristic analysis of large trees as generated in the game of Go. Ph.D. dissertation, Standford Univ., 1971. [20] Shannon, C.E. Programming a computer for playing chess. Philosophical Mag. 41, 314 (1950), 256-275. [21] Shirayanagi, K. A new approach to programming Go--Knowledge representation and its refinement. In Proceedings of the Workshop on New Directions in Game-Tree Search (Edmonoton, Canada, May 28-31, 1989). [22] Turing, A.M. Digital computers applied to games. In Faster than Though: A Symposium on Digital Computing Machines? (B.V. Bowden, Ed.), Ch. 25, 286-310, Pitman, London, 1953. [23] Wilconx, B. Zobrist's program. Amer. Go J. 13, 4/6 (1978), 48-51. [24] Wilcox, B. Ryder's program. Amer. Go J. 14, (1979), 23-28. [25] Wilcox, B. Reflections on building two Go programs. SIGART News 94 (Oct. 1985) 29-43. [26] Zobrist, A.L. Feature extraction and representation for pattern recognition and the game of Go. Ph.D. dissertation, Univ. of Wisconsin (1970). ANDERS KIERULF is an assistant in computer science at Informatik ETH in Zurich. His research interests include heuristic search and computer game playing, user interfaces, algorithms and data structures. Author's Present Address: Informatik, ETH, CH-8092 Zurich, Switzerland. kierulf@inf.ethz.ch. KEN CHEN is associate professor of computer science at the University of North Carolina at Charlotte. His research interests include artificial intelligence, in particular heuristic search and computer game playing, knowledge-based systems. Author's Present Address: Dept. of Computer Science, University of North Carolina, Charlotte, NC 28223. chen@unccvax.uncc.edu. JURG NIEVERGELT, professor of computer science, has recently returned to ETH Zurich after 4 years as chairman of the Department of Computer Science at the University of North Carolina at Chapel Hill. His research interests include algorithms and data structures, and interactive systems. Author's Present Address: Informatik, ETH, CH-8092 Zurich, Switzerland. jn@inf.ethz.ch. 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 data 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.