Visualizing Chess Games - Semantic Scholar

3 downloads 0 Views 294KB Size Report
have on the balance of power in the game. Novice players often fail to detect threatened pieces of either color. They also find prediction difficult and frequently ...
Visualizing Chess Games Scott Lewis, Stephen A. Voida, Chris C. Martin College of Computing Georgia Institute of Technology Atlanta, GA USA +1 404 876 1573 {slewis, chmartin, svoida}@cc.gatech.edu

ABSTRACT

Chess is a strategic game in which players recognize the threats to their pieces and their opponents' pieces at any given time. Players also evaluate the affect each move will have on the balance of power in the game. Novice players often fail to detect threatened pieces of either color. They also find prediction difficult and frequently neglect to think ahead about the negative ramifications of their moves. We have developed a chess visualization tool that helps novice players track the relative risk in which either their pieces or their opponentÕs pieces reside. The visualization tool also enables novice players to maintain a sense of the amount of influence each side has over empty squares. Advanced players may also find value in the chess visualization tool in evaluating and identifying the critical decisions made in grandmastersÕ games. Keywords

Chess, education applications, entertainment applications, computer graphics, information visualization, visualization INTRODUCTION

Chess is a game in which every move irrevocably changes the future directions in which the game can move. What makes expert chess players exceptionally good is that they can compare and evaluate these potential outcomes to one another and choose the current move that will benefit them the most. Chess masters can easily evaluate board situations at a glace and begin concentrating on their future strategies. In contrast, novice players cannot evaluate their current situation in the game. They are unable to use the static information provided by a glance at the game board to their advantage. The novice frequently experiences difficulty identifying which squares are covered by whom and which of their own pieces are threatened by their opponentsÕ. He or she often overlooks moves in which

opposing pieces can be taken without retribution in favor of moves that leave his or her own critical pieces at risk. The act of visualizing future implications on play forces novices to work harder and places them under a heavier cognitive load, just to understand the implications of and options afforded by their current position. In addition to these tactical problems, the novice player lacks the ability to make mental representations of the board in the same way that the expert player may understand the semantic layout of the pieces. Novice players are unable to perform on more involving strategic levels because of their inability to completely and quickly understand the current board space. We attempted to resolve this difficulty by developing a visualization tool that assists the novice playerÕs understanding of the current board configuration, as well as the results of subsequent moves. We wanted to bootstrap the noviceÕs playing ability by supplying complex, semantic information about the current board layout graphically, allowing them to more richly comprehend their current situation and play the game at a greater strategic level. Additionally, we also wanted to assist players in understanding common guidelines in playing a successful game of chess, such as the need for the control of the center of the board, and individual strategic guidelines, such as Òbad bishop.Ó Design Decisions We wanted to create a chess visualization that would allow the players to understand critical information needed to create predictive and forward-looking strategies. However, this information would be useless to the player outside of the context of a match in progress. We wanted the information to be readily available with each new move, but not to distract the player from the game in progress. Additionally, we wanted the visualization to be as interactive as possible Ð to allow players to try out future moves and to see their effects before committing to the move. These constraints restricted us by preventing us from compromising the layout of the board or the look of the pieces. As a result, we felt that modifying the status of

the individual squares would be the most effective way to visualize the information.

most useful when evaluating the amount of influence a player has on the empty squares.

We used evaluation of the current board status, instead of any predictive information, because we wanted to make it possible for the user to easily understand and to individually derive the contents of the visualization. The color of the squares directly relate to either the number of pieces that can have access to that square or the quality of pieces that are involved in the possession, support, or capture of the square.

Occupied squares often need to be considered more critically than unoccupied squares, because the number and color of the pieces covering an occupied square can have a direct effect on whether the piece occupying the square is captured. Additionally, the state of an occupied square is much more context-based than an unoccupied square, since the rankings of the piece involved can significantly affect the game play in relation to that square. Squares that are covered by pieces of the same color as the piece occupying the square are said to be supported, since the neighboring pieces help to reduce the chance of the square being attacked, and squares that are covered by pieces of the opposite color are said to be threatened, as they afford attack and capture by the opponent.

The visualization is designed to allow the users to evaluate the visualized representations as recommendations, and to make their movement decisions based on them. The visualization can help players to more readily identify locations that have inadequate support and points of conflict on the board that would otherwise go unnoticed. We believe that providing more intelligent move outcome prediction, the focus of many artificial intelligence research efforts, may make the visualization more useful in winning chess games, but that it will not provide the user with as much assistance in building the skills they need to become better chess players. Variables Fundamentally, there are only two pieces of data that can be gathered from a static board display and used in chess visualization: the location of the pieces and what squares those pieces can access. All of our hypothetical constructs that we created are based on these two pieces of data. It is important to note that we are only looking at static information for an individual piece or square. Historical information concerning the number of times a piece has been moved or the number of pieces taken by the piece has not been included. Likewise, future implications of a pieceÕs movement are not directly considered. We have not included this information to keep our design visually simple and clear. This information may be useful in helping an expert player analyze the strengths and weaknesses of the positions, but is less useful for the novice chess player. Using the data gathered directly from the game board, we are able to generate more interesting variables, as well as composite information that is potentially useful to a player. The data gleaned from vacant squares can be used to visualize the ÒcoverageÓ of that square by both players. Coverage is defined as the number of pieces that can could take a piece if an opposing piece moved to that square. A vacant square can have multiple levels of coverage: it can lack coverage when no piece is able to attack pieces that move to the square, it can have unilateral coverage when piece of only one color are able to attack pieces that move to the square, and it can have bilateral coverage when pieces of both colors are able to attack pieces that move to the square. We believe that this notion of coverage is

For most pieces, movement and coverage are the same. Every square a piece can move to, it can take a piece located there as well. Unfortunately, pawns are the exception to the rule, because they have different movement/taking behaviors. For this visualization, encoding a difference between movement and coverage would have been exceptionally difficult, and we feel that such an addition would not have added enough information to the visualization to be worthwhile. Color We decided to use color of the squares of the chessboard to encode the values of the variables because it adds information to the visualization in a very lightweight manner. The only information that is lost from modifying the color of the underlying squares is the standard tiling of the chessboard. This tiling information is useful in determining the movement abilities of the game pieces, but is otherwise not essential to the game play. We had four major variables that we wanted to represent in our visualization: amount of unilateral coverage of an unoccupied square, amount of bilateral coverage of an occupied square, amount of support for an occupied square, and amount of threat for an occupied square. These variables encode both a numerical amount, i.e. the number of pieces involved in the calculation, as well as the color of those pieces. An example of this encoding strategy is that the displayed coverage of a unoccupied square should indicate which color is controlling it, as well as how many pieces can potentially attack at that location. One of the design goals for our visualization is that the display of information should not distract the players. However, we wanted to highlight those areas that demand the playerÕs attention, such as areas that are strongly threatened or weakly controlled. Because unoccupied squares hold relatively low importance for the players, coverage information of the unoccupied squares should be presented in a calming, almost peripheral way. Support information should be similar to the unoccupied coverage

information, and should clearly indicate which pieces are covered and which are not. Threatened pieces should be the focus of the visualization because these are the most important points on a static board, and movement involving these squares may radically change the status of the board. These critical squares should be brighter, filled with attention-grabbing color, and should draw the playerÕs eye toward the square in conflict. Initially, we considered using different colors for each of the variables, so that the users could easily correlate the colors between the variables represented. We found this to be so confusing as to be completely ineffective. Users had a difficult time understanding what colors were associated with their interests and which colors indicated the opponentÕs.

more intensely-colored square indicates that more pieces of one color could potentially by mobilized to attack opponents located in that square. We did a pseudologarithmic progression of the color intensity, because while it was important to differentiate between one, two, and three pieces covering the square, differentiation of more pieces becomes increasingly irrelevant. Figure 1 shows the colorization of unoccupied, unilaterally covered squares in the center of the game board. For bilaterally-covered unoccupied squares, we adjusted the hue and saturation as a mixture of the blue and green colors, indicating which side has more pieces capable of capturing the square. The coloring is based on a simple linear calculation that uses the number of pieces of one color that can move to the square subtracted from the number that can move from the other square, divided by the total number of pieces. This gives us a ratio, which is used to modify the hue and saturation, and indicates which side has an advantage in capturing the unoccupied square.

Figure 1: An early game visualization showing coverage and support. To simplify the visualization, we overloaded the hues used for three of the variables. The less important variables, unilateral coverage, bilateral coverage, and support, were overloaded to the same series of colors, and threat was encoded using a separate color. We assigned a green to blue spectrum to the coverage and support variables, with blue indicating strength or support of white and green indicating the strength or support of black. The colors were assigned to each side arbitrarily. We did not believe that there was any interaction between the two colors, and that a consistent application would suffice for the requirements of the visualization. For unoccupied, unilaterally covered squares, we colored the squares according to the number of pieces that could attack a piece occupying the square. This magnitude was indicated by the intensity of the color of the square. A

Figure 2: Unoccupied squares in conflict contain a weighted average of the green and blue hues. Note B5, E5, and G5 on the board. For supported squares, we overloaded the hue and intensity of the square, much in the same way as we did for unoccupied, unilaterally-covered squares. However, instead of using quantity to determine the intensity of the color, we used the quality Ð the relative strength Ð of the pieces supporting it. We did this because we wanted to indicate how expensive a transaction would be, should the square be attacked. For example, the movement of a pawn to re-take a lost piece is less strategically expensive, and often more effective than having to move the queen or king. To quantify the amount of support for a square, we used the typical chess point scoring, in which pawns are worth 1

point, bishops and knights are worth 3, rooks are worth 5, and the queen is worth 9. The king is considered infinitely valuable. Since it is more advantageous to have a lowervalue piece supporting another, we used an inversion of the chess scoring values to indicate support: we subtracted each of the values from 10 to get their value in supporting another square. For each square, these points are summed to get a total. This support value was utilized in our visualization to modify the intensity of the color of the supported squares; the hue and saturation of the squares are determined by which side is providing the support. When the sum of the support piece values is less than 20 (which covers most cases during game play) the intensity would change more readily than when the sum of the support point values exceeded 20. We felt that, as in the case of the unoccupied, unilaterally covered squares, it was more important to understand coverage differences on a smaller scale. When 3 or more pieces can move to a square, our visualization becomes more subjective, and, therefore, or less value to the novice player.

interest to the player. The gradient of the color indicates which player has an advantage, according to the number of points lost, if all the transactions possible at that square were to occur. The position within the gradient is determined by the difference of points lost divided by the total points lost. Extreme transactions will display as bright reds or yellows, indicating a clear advantage for one side or the other.

FUNCTIONALITY

We used a simple chess engine as the basis of our system. All the moves of a regular chess game, including castling and en passant are allowed. The system allows players to select a piece that they wish to move, and select the square into which the piece should be moved. The game prevents players from making moves that will put the king (or leave the king) in check. The system also detects check and checkmate conditions. Currently, the system does not support the piece exchange that occurs when a pawn reaches the opposite end of the board, but that functionality will be added at a later date. By default, a standard, black and white tiling of the game board is displayed. When users wish to use the visualization features of the system, they select a check box, and the board is redrawn using the current state of the game board. The state of the visualization can be turned off or on at any time during play, allowing players to refer to the visualization features less as they become more proficient and self-reliant chess players. When the visualization feature is active, color values for each square on the chessboard are computed at the beginning of each turn and displayed beneath the normal chess pieces. Dynamic Visualization

Figure 3: The points of conflict on the board are clearly apparent by the bright red and yellow squares. Squares where black has advantage (G3, B5) are bright yellow, and squares where white has an advantage (A6, F5) show as bright red. Places where multiple exchanges could occur and would not give a clear final result are a mix of the red and yellow hues, as in square C6. For threatened squares, we used a different gradient hues in order to differentiate the squares from the lighter coloration of covered and supported squares. We selected a gradient from bright yellow to bright red, and assigned the colors such that red squares show a strong advantage for the white player, and yellow squares show a strong advantage for the black player. We assigned these colors to each side because yellow is closest to green on the color wheel. Although red does not necessarily match well with blue, we needed a bright color to indicate an point of

When the "visualize dynamically" box is checked and a player selects a piece they wish to move, the color of the board squares is updated each time the piece is moved over a valid destination. This feature allows players to evaluate the outcome of several moves in the same turn without having to commit to the move, because they do not have to wait until they have completed the turn for the visualization to update. If a player is interested in evaluating how moving a bishop will affect the board, he can click on the bishop and then move the cursor over each of the squares to which he is considering moving it. The entire board updates as the cursor moves over different squares, showing the ways in which the coverage, support, and threat will change both locally around the bishop, and in remote corners of the board. To deselect the bishop, the player simply clicks on it again, and the board colors return to the reflect current state of the board. Unlike the visualization option, the dynamic visualization option helps novices compare different options to one another.

As a result, it prevents slips such as placing a piece where it can be threatened or exposing covered pieces to threats.

Figure 4: In a dynamic visualization scenario, the user has selected the black queen (D8) and is currently holding the cursor over (A5) Ð not a safe destination for the queen. FUTURE DIRECTIONS

Our visualization software was crafted hastily to test the usability of the visualization and the appropriateness of our evaluation equations. As a result, the software has been incompletely tested, and lacks a number of features that would improve its functionality, as well as make the visualization itself a more powerful tool. Currently, the software features no animation, and, as a result, the software is usable almost exclusively as a visualization tool. Adding animation so that the pieces move continuously from one square to another, with added motion cues such as acceleration and deceleration, would help the program to be more user-friendly and playable. In the dynamic visualization, a ghost piece would walk over the possible squares while the actually piece would stay in the original location. This change would give the interface a more direct-manipulation feel. One of the fundamental shortcomings of the visualization tool is that our color spectra were selected somewhat arbitrarily, to satisfy criteria of ÒunobtrusiveÓ and Òattention-focusing.Ó A more professional implementation would require then changing of our color spectra to help users distinguish between the intermediate colors in the spectra. Blue and green are similar colors, and hence the blue-green scale is less sensitive to small changes between the colors. We would like to add an option so that players could choose which of several optimized spectra be used to provide the visualization during the game. We would also need to upgrade the underlying game engine to support the loading and saving of games. Although this is a standard feature in many chess games,

and should be implemented simply to meet usersÕ expectations, it adds an additional level of usefulness to our program, as saved portions of grandmaster matches could be loaded and analyzed using the visualization feature. This ability would make the program valuable not only for novice users, but also for more experienced chess players looking to improve their interpretation skills. Adding an Ôinstant replayÕ feature that would replay the game from beginning to end, showing the result of each move after a brief pause. The pieces on the board, the colors of the underlying squares, or both could be shown during the replay, allowing players to analyze their decisions during the game and see which moves caused significant shifts of control or creating openings which were later exploited during the game. Currently, the visualization immediately conveys through color the power of the current game on the board. When the a region of the game board is predominantly one color, players can quickly recognize which player has a strong hold on that area. If the predominant color changes greatly after a certain move, users can evaluate that move as a particularly valuable one. The change in color that occurs is sudden, however, and can appear jarring, when users are trying to notice how the power relationship is changing. If the users focus on particular squares, they can hold that focus when the color change occurs to see how the control over those squares have changed. The users cannot possible focus on all 64 squares at the same time, however. We would like to add two functions that would help users recognize the changes as they occur. First, the system should change the color of each square gradually from the original color to the new color. This gradual, continuous change could emphasize the direction of each change on the board as it occurs, so users will be more likely to remember what the original color of each square was. In addition, all 64 squares should not be updated at the same time. When white makes a move, the row of square closest to white should update first, followed by the second row and so forth. Similarly, when black makes a move, the updating will start from black's side of the board. With this change in implementation, users will find it easier to keep track of more changes, even though the system's speed will drop. Updating the squares from the relevant player's side will first indicate whether the player has endangered any of her own pieces, which are more likely to be closer to her side of her board even at intermediate stages of the game. Then the player can observe changes to less critical areas in the middle of the board. The board could also be enhanced to show special cases. One such case is the "bad bishop," in which a bishop is immobilized because its own pawns occupy all the squares it can move to. Pawns tend to end up in diagonal configurations, so bishops are particularly vulnerable to becoming trapped among them. The system could use a

factor other than color, such as text, to draw the player's attention to these special cases. Certain special scenarios also occur. The "x-ray" is a scenario in which a player's piece threatens an opponent's piece of high value, while a piece of lesser value is obscured behind the highly valued piece. In order to save the highly valued piece, the opponent must move it away, and thus leave the less valued piece open to capture. The player has thus x-rayed through the first piece to capture the second. In such cases, a factor such as text could again inform the players of the potentially damaging scenario. If people play the game over a network, each player could choose a handicap level that would then limit how much information the visualization would provide. As a player gets better, he or she may choose to receive less information about special cases and vulnerabilities, but still have information about attack options. An even better player may only want to have information displayed indicating whether the sum of a series of sacrifices will benefit or hurt him or her. CONCLUSIONS We have developed a chess visualization tool that holds promise for novice chess players. The tool provides information about the current state of the game board by manipulating the color of each of the 64 square on the board. The visualization shows four variables using this color display scheme: the amount of coverage of unoccupied, unilaterally-covered squares, the amount of coverage of unoccupied, bilaterally-covered squares, the amount of like-colored support for occupied squares, and the amount of threat caused by opposing pieces for occupied squares. The visualization was designed to convey a maximum amount of information without altering the overall look and feel of the chess board, and satisfied all of our basic design goals. There are a number of improvements that could be made to the visualization that would expand its usefulness, both to novice and expert users. REFERENCES 1. Liqun, J. and Banks, D. G. ÒTennisViewer: a browser for competition trees,Ó in IEEE computer Graphics and Applications, pp. 63-65, Jul.-Aug. 1997. 2. Morales, E. M. Learning playing strategies in chess. Blackwell, Cambridge, MA, 1996. 3. Kierulf, A., Gasser, R., Geiser, P.M., Muller, M., Nievergelt, J., Wirth, C., and Maurer, H. ÒEvery interactive system evolves into hyperspace: the case of the Smart Game Board,Ó in Hypertext/Hypermedia Õ91, pp. 171-180, 1991.