U

N
G400
C S

G53IDS
I D
40 C

Dissertation T C

Author: Robert M
rxm08u Submitted May 2011, in partial fulfilment of the conditions of the award of B S .

I hereby Declare that this dissertation is all my own work, except as indicated in the text: Signature:

May 5, 2011

Abstract Chess AI research has largely stagnated into optimisations of the same paradigms, such that some believe research should focus on a dierent game. We propose Time Chess, a Chess-related game designed to be interesting and challenging for humans, and prohibitively complex for currently prevalent Chess AI approaches, in an attempt to encourage advances in new AI paradigms. High complexity is achieved by extruding Chess into the higher dimension of Time. The game rules are designed and specied, and sample implementations of a Time Chess Engine and 3D Interface are designed and implemented, along with a Protocol Specication to ensure compatibility between future engines, GUIs and AIs.

Contents
1 2 Introduction 1.1 Aims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Background 2.1 Chess Programs . . . . 2.2 Current Chess AI . . . 2.3 Other HyperChesses . . 2.4 Other Complex Games 2.4.1 Go . . . . . . . 2.4.2 Arimaa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 7 7 7 8 9 9 10 13 13 14 14 15 17 18 22 23 23 25 25 26 27 29 29 29 30 30 31 31 32 39 39 40

Design 3.1 System Architecture . . . . . . . . . . . . . . . 3.2 Designing Time Chess as a Game . . . . . . . 3.2.1 Game Design Principles . . . . . . . . 3.2.2 Game Design Process . . . . . . . . . . 3.2.3 Move Notation . . . . . . . . . . . . . 3.2.4 Designing Backwards Time Travel . . . 3.2.5 Designing the Movement of the Pawn 3.3 Designing Time Chess as Software . . . . . . . 3.3.1 Requirements Specication . . . . . . 3.3.2 Engine Design . . . . . . . . . . . . . . 3.4 Designing the 3D Interface . . . . . . . . . . . 3.4.1 Piece Shapes . . . . . . . . . . . . . . . 3.4.2 Boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Implementation 4.1 Technology Choices . . . . . . . . . . . 4.1.1 Why Python? . . . . . . . . . . 4.1.2 Why NumPy? . . . . . . . . . . 4.1.3 Why VPython? . . . . . . . . . . 4.2 Implementing The Time Chess Engine 4.2.1 Implementation Description . . 4.2.2 How it works . . . . . . . . . . 4.3 Implementing the 3D Interface . . . . . 4.3.1 Implementation Description . . 4.3.2 How it Works . . . . . . . . . .

4.4 5

Extra Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Stereo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42 42 45 45 45 46 47 47 50 53 55 55 55 55 56 57 63 63 64 64 66 66 67 67 67 67 68 68 69 70 71 73 73 73 73 74

Evaluation 5.1 Diculty for Computers . . . . . . . . . 5.1.1 Branching Factor . . . . . . . . . 5.2 Unit Tests . . . . . . . . . . . . . . . . . 5.3 User Acceptance Testing . . . . . . . . . 5.3.1 The King becoming Lost in Time 5.3.2 Survey . . . . . . . . . . . . . . . 5.4 Requirements . . . . . . . . . . . . . . . . . . . .

6 Summary 6.1 Further Work . . . . . . . . . . . . . . 6.1.1 Interface Improvements . . . . 6.1.2 Accurate Complexity Estimates 6.1.3 Aective Analysis . . . . . . . . 6.1.4 Personal Reections . . . . . .

A The Rules of Time Chess A.1 Board and Pieces . . . . . . . . . . . . . . . . A.2 Objective . . . . . . . . . . . . . . . . . . . . A.3 Movement . . . . . . . . . . . . . . . . . . . A.3.1 Blocking . . . . . . . . . . . . . . . . A.4 Forward Time Travel . . . . . . . . . . . . . A.4.1 Appearance Order . . . . . . . . . . A.4.2 The Lost in Time Rule . . . . . . . . A.5 Backward Time Travel . . . . . . . . . . . . . A.5.1 Taking Pieces Back in Time . . . . . A.5.2 Braindead Pieces and Steamrollering A.6 Check . . . . . . . . . . . . . . . . . . . . . .

B Time Chess Engine Communication Protocol Specication B.1 Messages from the GUI to the Engine . . . . . . . . . . . . . . . . B.2 Messages from the Engine to the GUI . . . . . . . . . . . . . . . . C Time Chess 3D Interface: User Guide C.1 Looking Around . . . . . . . . . C.2 Selecting Pieces . . . . . . . . . C.3 Moving Pieces . . . . . . . . . . C.4 Keyboard Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 1

Introduction
This document documents the design of Time Chess, a new Chess variant which incorporates time travel as a core game mechanic, and the construction of a computer implementation of Time Chess to make the game playable by pairs of humans.

1.1 Aims
Time Chess has two main (interrelated) aims. The rst aim of Time Chess is to have an extremely high cognitive load. In laymans terms, this can be thought of as how dicult the game is to play. However this denition is insucient, because diculty is a broad term which can refer to many dierent challenges, including non-mental ones. Specically, cognitive load in this context refers to the level of mental activity involved in playing the game properly. It is a function of the amount of processing that must be done, and the amount of game state information that must be stored in working memory in order to play. (Paas, Tuovinen, Tabbers & Van Gerven 2003) Determinants of cognitive load include the number of possible moves available to the player and the number of factors that must be considered in evaluating a possible move. The cognitive load of a game is therefore closely related to its complexity. 5

Chess is generally considered to be a complex game (Shannon 1950), but Time Chess is far more complex. This complexity helps to contribute to the second aim of Time Chess, which is to provide a chess variant that presents new and interesting challenges to both human and machine players, encouraging AI research to yield results useful in general Chess AI and beyond. Its worth noting that we do not aim to implement a Time Chess AI here, but to provide the groundwork for others to build on.

Chapter 2

Background
2.1 Chess Programs

There is a very large number of programs allowing humans to play Chess on a computer. These are generally divided into Chess Engines and Chess User Interfaces. The player(s) interact with the interface, and the interface communicates with the engine, which is responsible for the rules of the game. This architecture is essentially a Model View Controller. Most chess software is written with loose coupling in mind, such that the engine and the interface need very little knowledge about one another to work together. They communicate by standardised protocols, for example Chess Engine Communication Protocol, and can thus work equally well with any component supporting the protocol. Should the player decide to play a computer (or set up a computer vs. computer game), the engine handles the AI.

2.2 Current Chess AI

Standard Chess is essentially beaten as an AI challenge. Easily available software running on a standard personal computer can beat master and even world champion human players. But some researchers nd existing Chess AI unsatisfying, and Chess AI research has not provided as much that is useful outside of the eld

as was once expected. Successful Chess AIs do not think about Chess in the way that humans do. The algorithms used generally work by evaluating large numbers of potential moves, looking ahead several moves, and deciding on the best move based on those evaluations. we should expect that machines will perform this narrow task so well that their skill will be orders of magnitude superior to the best human play What will be the signicance of this accomplishment for other areas of AI research? Sadly, not much. The brute force nature of the nal solution might tell us how to go about building a parallel architecture Go or Checker machine, if we are so inclined, but it does not scale up to problems in robotics or expert systems, for example. L. Stephen Coles (Coles 2002) We posit that if researchers are to make progress in Chess AI which will be useful in other elds, these brute-force based successful but boring approaches must rst be broken. Time Chess aims to do that.

2.3 Other HyperChesses

Time Chess can be thought of as Chess extruded into the extra dimension of time. Chess games extruded into higher dimensions can be called HyperChesses. Several HyperChesses have been designed (Pritchard & Beasley 2007). Most of these extrude into a single higher spatial dimension, creating 3D Chess. Perhaps the best known is P Tri-D Chess, which is played on a bizarre array of boards of dierent sizes. Programs like Parmen allow this game to be played on a computer. There is also Raumschach, a game played on a 555 board, and a large number of variants played on 883 boards, including Millennium 3d Chess and DragonChess. 8

Few attempts have been made to use Time as a dimension in HyperChess, and those that have have not been very serious. Jay Shastall proposed a Temporal Chess (Shastall n.d.), but little came of it. In all of these HyperChesses, with the possible exception of Raumshach, the extra dimension is treated as a second-class citizen, either by the board being smaller in that dimension, or by having movement in that dimension occur under limited or varied rules. In Time Chess, we aim to have t be as important a coordinate as x or y .

2.4

Other Complex Games

There are many games designed to be complex, and some that are specically designed to be challenging for machine players.

2.4.1

Go

Go is a highly complex game (Allis 1994), and provides a much more dicult challenge in AI research than Chess. The reasons for this are explored in detail in Crsmaru (1999), we will only briey summarise them here. The board is 1919, much larger than a chess board. Movement is less restricted. Generally almost any unoccupied space is a legal move. The game becomes more complex as it goes on, as pieces are added, in contrast to Chess, in which pieces are removed. Evaluating a move requires analysis of the structure of the layout, with few of the computationally cheap move evaluation factors available to Chess, like Whats the value of the pieces I can take if I make this move.

For these reasons, Go is thought of by many as the next challenge and focus of game AI research (Stone n.d.). However, there are also those who think that Chess still has a lot to teach us (Iqbal n.d.), and should not be abandoned yet.

2.4.2

Arimaa

Arimaa is a game designed with fairly similar goals to those of Time Chess. It is intended to be playable by a four year old, and very dicult to play for an AI (Syed & Syed 2003). One way in which it poses a problem for brute-force based AI players is by having a very high number of possible moves available each turn (17,281 compared to Chess 35). The number (called the branching factor) is so high in Arimaa because each turn is made up of several moves, and there are several choices that need to be made in each move. In chess, there is only one move per turn, and two choices to be made per move - which piece to move, and where to move it to. There are a maximum of 16 pieces from which to choose, and generally only a few possible moves for a piece. For example, Knights get at most 8 possible moves, and the most mobile piece, a queen, when placed in its most free position, the centre of the board, still has only 27 possible moves. In Arimaa, four moves a turn are possible, immediately increasing possibilities by a factor of four. However, not all four moves must be used each turn, a player can elect to make any number of moves between one and four. This further increases the number of possible turns. The player may elect to allocate their up to four moves however they want between their pieces, further increasing the number of possibilities. The game revolves around a mechanic of pushing and pulling, by which pieces can move opposing pieces on the board. A piece can move away from an opposing piece leaving it in place, or it can move and pull the opposing piece with it, which provides another choice, doubling the search space for many moves. Each extra choice provides an extra dimension to the abstract turn-space, exponentially increasing the size of that space (this is often called The Curse of Dimensionality). The resulting explosion of options makes the search space ex-

10

tremely large and dicult for an AI to handle, but doesnt inconvenience human players much. Human players can be thought of as having a particular maneuver, goal or strategy in mind, and searching for a way to work within the restrictions set by the game rules to achieve that aim. Most Chess AIs can be thought of as having a space of possible moves, and attempting to search that space for a good move to play. Looked at in this way it is clear that for a human, more freedom means weaker restrictions applied by the game, which makes it easier to play, but for a Chess AI that freedom means a much larger move-space to search. More choice makes things easier for the human and harder for the AI. 2.4.2.1 Dierence to Time Chess The aims of Arimaa vary from those of Time Chess, in that Arimaa attempts to be simple for a human and dicult for a machine, whilst Time Chess makes no attempt to be simple for a human to play. While Arimaa, like Time Chess, can be played on a standard chessboard, Arimaa is so radically dierent in its gameplay that it cannot be considered a chess variant, but is rather a completely dierent game played on the same board. Advances in Arimaa AI may not be helpful in developing more interesting AI for normal Chess. Time Chess on the other hand is similar enough to Chess that advances in Time Chess AI are more likely to be applicable to standard Chess.

11

12

Chapter 3

Design
3.1 System Architecture
At the highest level, the design consists of two separate programs - The Time Chess Engine, and the User Interface. The programs are functionally independent, and communicate using a simple text protocol. This architecture is inuenced by the design of popular existing chess programs, most notably the GNUChess engine and the XBoard chess GUI. This approach has many advantages over monolithic designs. Firstly, it is a sensible separation of concerns. The loosely coupled design means that the two programs are insulated from changes in the other during development. The engine can be rewritten to operate in a very dierent way, but as long as it still supports the protocol, the GUI need not be changed at all, and vice versa. Not only this, but the modularity of the system allows parts to be swapped out and replaced by completely dierent ones. Other programmers could develop their own interfaces, which could be completely dierent from mine but would work with the engine without any reconguration. The components are unconcerned not just with the nature of the other component, but also with the nature of the connection between them. My implementation will use operating system level pipes, but the system could work just as well over a TCP connection for example.

13

3.2
3.2.1

Designing Time Chess as a Game

Game Design Principles

Before formalising the design of the game, I decided on some principles which I wanted the game to adhere to. 3.2.1.1 Remain true to Chess

Styling, gameplay concepts, terminology etc. should not be changed unless necessary. This will make the game more clear to those already familiar with Chess Piece movements should be their Chess equivalents extruded into a higher dimension as literally as possible 3.2.1.2 Be complex for computers

The games state space should be large, as should the number of available choices, to keep the branching factor high. 3.2.1.3 Allow for interesting and tactical gameplay Attempt to nerf the FOO strategies, that is to say dont allow First-Order Optimal strategies to allow players to win without requiring much skill 3.2.1.4 Player-Time is linear

Repetition is dull and long-winded. Never require the same turn to be played more than once If moves to the past require the intervening turns to be played again, it would be possible to have a never-ending game that continually loops over the same few moves, because players would be motivated to continually backtrack to attempt to prevent past losses and mistakes.

14

3.2.1.5

To hell with paradoxes

Paradoxes should be either impossible to create, or trivial to resolve unambiguously and deterministically.

3.2.2

Game Design Process

The rst part of the design process, since Time Chess is a variant of Chess, was to fully familiarise myself with the details of the rules of Chess. I obtained and read a copy of Laws of Chess, a document published by the F, the World Chess Federation. The document is probably the most authoritative chess rule-set available. By use of this document, and the freely available source code of the GNUChess Chess engine (GNU Project n.d.), I implemented my own chess game in Python. An interaction with the resulting program is shown in gure 3.1. This made sure that I properly understood the rules of Chess, since its not possible to write a program to simulate chess without understanding all of the rules. It also helped me to gather my thoughts on what kinds of algorithms and data structures work well for this class of problem, which would be useful later. Once I had a good grasp of the rules of Chess, I began planning in detail how to extrude it into a higher dimension. For this I looked at the hyperchess games discussed in section 2.3, which gave me a good idea of the general approach taken by other Chess variants, and made me aware of their shortcomings that I wished to avoid. During the course of the design process I discussed the rules with a number of people, including the members of The University of Nottingham Chess Club, which made several things clear to me. Firstly, this game was (as intended) very confusing, and dicult to discuss verbally. English grammatical constructions are very poorly suited to talking about time travel, so clear and consistent use of language was required. Secondly, the game was much easier to discuss with Chess enthusiasts than with those not as interested in Chess. There is no doubt that this had many causes, not least of which was interest, but a larger part than anticipated 15

Figure 3.1: Interaction with the command line interface of the chess game, showing movement and display of possible moves

16

was due to knowledge of a shared terminology with Chess. Chess terminology could be exapted to describe related concepts in Time Chess, which conrmed my belief that Time Chess should echo Chess as closely as practical, to aid understanding of the game by Chess players. Thirdly, because verbal discussion of the rules was dicult, we made use of sketches and diagrams as visual aids. From this it became apparent that Time Chess is a fundamentally three-dimensional game, which is dicult to express on a two-dimensional plane. This need for a 3D way to explain the game, combined with the ineectiveness of hand gestures, demonstrated a need for a tool to allow easy 3D visualisations of arrangements of pieces. The tool was built fairly quickly, making use of the Python language and the visual module (see section 4.1.3). It allowed simple 3D scenes of Time Chess scenarios to be built quickly and interacted with, which was a great help in discussing hypothetical scenarios and complex rules. An screenshot of the tool is shown in gure 3.2. The excellent performance of the visual module for this task led to the decision to use it for a full 3D interface to the engine.

3.2.3 Move Notation

Because positions in Time Chess have an extra dimension, a new notation had to be created to describe them. Normal notation simply concatenates the le letter with the rank number, so a piece on le c and rank 6 is at position c6. In Time Chess there is also a time coordinate representing the turn. One option is simply to concatenate the turn onto the standard notation, so the same piece in turn one would be at c61. This would work, because the rank number is only ever 18, and thus is always exactly one digit long, so there is no need to delimit the elds. However, the chosen solution was to separate the values with a t. Thus the piece would be at c6t1. This makes the positions easier to understand, since the t can be read as time or turn. It also allows for future variants to be played on boards with more than 9 ranks without modifying the notation.

17

Figure 3.2: The 3D visualisation tool demonstrating the move options of a Knight For denoting movements, the notation simply concatenates two positions, so c6t1e8t1 means Move from le c, rank 6 in turn 1 to le e rank 8 in turn 1.

3.2.4

Designing Backwards Time Travel

The main game design challenge of Time Chess is backwards time travel. 3.2.4.1 Dierent Time Travel Models

There are many dierent models of time travel (Nahin & Nahin 1994), which have dierent underlying assumptions, levels of internal consistency, and consequences for gameplay. Among the decisions that must be made are: Single vs. Multiple Timelines In some models there is only one timeline, and thus the past that the traveller arrives at leads directly to the present from which the traveller left, which may be the same or dierent from when the traveller left it.

18

 In others, travelling backwards in time causes a new timeline that splits and diverges from the rst when something is changed Choice vs. Fate In some models, changes to the past have consequences for the present and future In other models (known as Eternalist or Block Time models (Stanford University 2008)) the past, present and future are a consistent immutable whole, so any change you make to the past inevitably leads to the conditions observed before making the change. In other words, every backwards time travel must by denition establish a stable time loop, such that changing the present by changing the past is impossible, because the present you observe is the result of you having already changed the past. Stable vs. Unstable In some models, the universe itself is in endangered by time travel, because the creation of paradoxes creates contradictions that cause reality itself to collapse Physical Laws vs. Regulatory Laws In some models, the limitations on time travel are inherently inviolable, as they are natural consequences of the laws of the universe Other models contain an agent or agents responsible for ensuring that certain rules are obeyed by time travellers. These can be in the form of Time Cops, or some form of disembodied entity that acts to attempt to maintain the natural order of things. Low Level Consistency vs. High Level Consistency vs. No Consistency Some models require low level consistency, that is to say that at every point in the timeline(s), from the perspective of every individual, the 19

universe must remain consistent (or make sense). Almost all models of time travel proposed by physicists fall into this category. Some models require only high level consistency, meaning that impossible or inconsistent things are permissible in certain timelines or from certain perspectives, as long as the denitive or nal time line makes sense. Some models seem to require almost no consistency at all, but this is mostly down to lazy writing. 3.2.4.2 Choosing a Time Travel Model

The original intention was a system with a single timeline, choice, stability, physical laws, and low level consistency. However, it quickly became clear that a single timeline was incompatible with choice and low level consistency, without overwriting the timeline by re-playing past moves, which I decided would be bad for gameplay (section 3.2.1.4). In other words, in order to have a timeline that is consistent at all points (in a game like this this would mean that all moves in every timeline must be legal), its necessary that either the past can never be changed (which would negate the point of having it as a possible move), or turns must be replayed when something changes them (to maintain consistency). 3.2.4.3 Limitations to Causality Low level consistency means that causality always follows properly. Models with low level causality are subject to the Buttery Eect (Hilborn 2004); A change to the past is likely to cause other changes, and those changes are likely to cause their own corresponding changes, and so on. The easy way to deal with this in a Time Chess game is to, whenever there is a change, play from that point, with the players obeying the normal rules, thus maintaining low level consistency. However this is unacceptable for reasons discussed in section 3.2.1.4, chief among them being the possibility of being stuck in an endless game replaying the same few turns.

20

So, consistency must be gured out without human interference if the game is to remain playable. The nature of the situation - each change causing a number of further changes - clearly calls for a recursive algorithm. The problem is that many backward time travel moves would involve a change which creates changes which undo the original change - a paradox. A recursive algorithm attempting to resolve such a move will enter an innite recursive loop. Such loops can be detected (Van Gelder 1987), but the best course of action when such a loop is detected is not clear. At what point of the loop should it be stopped and the board state xed? Perhaps all moves resulting in paradoxes should be illegal, but this would reduce the number of available moves at each turn, reducing the branching factor of the game, which we decided against in section 3.2.1.2. So, without human interaction, true recursive low level consistency in Time Chess quickly becomes very messy. Some form of limit must be put on causality, and thus consistency. Changes cannot be allowed to cause more changes indenitely. The question then becomes Where to draw the line?. How much can you restrict causality without negating the point of travelling backward in time in the rst place? 3.2.4.4 The Decision

The system I settled on (described in section A.5) is that when pieces travel back in time, any opposing piece they land on is captured and removed from the game from that point forward, but no further change is made to the timeline. Pieces taken by a captured piece are not returned, moves made illegal by the changes remain as they are. The piece that travelled back remains in place, propagating forward to the present as though it had just sat still in the intervening time. If another piece moves into the space occupied by the backward traveller as it propagates to the present, the backward traveller is destroyed. This stops the existence of the inactive backwards traveler from having knock-on eects on the timeline.

21

3.2.4.5 An Alternate Possibility An option was considered which involved a degree of consistency and causality higher than that of the chosen solution, was one that attempted to guarantee that all moves at all times were either legal or didnt happen. That is to say that if any move is, due to changes brought about by time travel, rendered illegal, that move is simply undone, and the timeline continues as though at that turn no move of any kind was made. It is worth noting that in both Chess and Time Chess, the only way a player may end their turn is by making a move, there is no option to skip a turn, so undoing a move does not render it legal in the normal sense. The advantage of this system is that moves are able to have tactically useful knock-on eects (like undoing an opponents move) but are not susceptible to paradoxes. In the case of a paradox, all moves involved in the loop will eventually be rendered illegal and undone. However, this solution was rejected because in situations of paradox (which are quite likely for long backwards time travel) the eect is to undo every move up to the present, eectively resetting the board to the latest point not aected by the paradox. This means that although the turn number is larger, for all intents and purposes the players may as well be replaying a turn from several moves ago, which goes against the principles discussed in section 3.2.1.4.

3.2.5 Designing the Movement of the Pawn

The Pawn is an unusual piece in both Chess and Time Chess, following unique movement rules. The Pawn is the only piece which is restricted in the direction it can move based on its colour, since it can only move forward. It could be argued that in order to properly extrude this concept into higher dimensions, White Pawns should be able to move backwards in time but not forwards, and Black Pawns should be able to move forwards in time but not backwards. However, due to the dierences in the practical gameplay consequences of forward and backward time travelling moves, this would almost certainly unbalance the game 22

by giving one sides pawns an unfair advantage. So the movement of the Pawns described in section A.3 applies to pawns of either colour.

The nal result of the game design process is the document The Rules of Time Chess, Appendix A.

3.3

Designing Time Chess as Software

3.3.1 Requirements Specication

3.3.1.1 Aim The aim of the software system is to allow human and machine players to play the game of Time Chess, as dened in The Rules of Time Chess (appendix A). 3.3.1.2 Engine Keeps track of the state of a game of Time Chess Maintains a data structure storing the state of the board at every past turn Maintains a count of what turn the game is at, which increments with every legal move Allows moves to be made Only allows moves to occur if they are legal Responds with informative messages when an illegal move is attempted Supplies the reason that the move is illegal Enforces player turn order, starting with white and only switching turns when a legal move is made
according to The Rules of Time Chess (appendix A)

23

 Detects when the game is nished, and which side was victorious Starts a new game when a game is concluded Supports the Time Chess Engine Communication Protocol (appendix B) Receives TCECP messages via stdin Sends TCECP messages via stdout Outputs all non-TCECP output to stderr Returns accurate and relevant information in response to TCECP information requests Acts on TCECP commands appropriately Comprehends Time Chess Move Notation (section 3.2.3) 3.3.1.3 3D Interface Allows the user to see a 3D representation of the game state Represents pieces as 3D objects * Objects must be recognisable as chess pieces * Objects must be dierentiable by shape into dierent types of piece Represents the squares of the board Shows game state as a stack of chess boards * Places the beginning of the game at the bottom and subsequent turns on top as layers Allows the user to adjust their view of the game state Allows adjusting the rotation of the view Allows adjusting the tilt of the view Allows adjusting the zoom level of the view Allows adjusting which layers 24

 Allows the user to select their pieces Selects pieces by clicking on them Allows the user to see which moves are available for a selected piece Visibly highlights positions which can be moved to by that piece Allows the user to select intended moves Selects moves by clicking on the highlighted positions Opens a connection to a program supporting the engine side of the TCECP Supports the GUI side of TCECP Sends properly formatted TCECP commands and requests to the TCECP Interface Responds appropriately to data received through the TCECP Interface

3.3.2 Engine Design

The general structure of classes outlined in gure 3.3 was devised to be able to meet the requirements. The engine is to be operated by the makeMove method, and interrogated for data by the getPossibleMoves and getState methods. These can be called by an interface program which will use them to support TCECP (appendix B), acting as an intermediary to allow the engine to be driven by the user interface.

3.4

Designing the 3D Interface

The main focus of this project is the creation of the game of Time Chess, and an engine to allow it to be played by human and machine players. In order for the game to be playable by humans, some form of User Interface is required. However, intuitive user interaction and a large game-play feature set were not required by

25

Figure 3.3: UML Class Diagram showing an overview of the Time Chess Engine structure the project aims or proposal, and were considered to be low priority goals. The design of the 3D interface is functional, and meets the requirements.

3.4.1 Piece Shapes

The piece shapes had to be recognisable as their respective pieces, but there was also a motivation to keep them simple, with low polygon counts, so that in complex scenarios with large numbers of pieces the program performance would not suer. The nal piece designs were inspired by real world chess sets designed in the minimalist style, with simple geometric shapes.

26

3.4.2

Boards

Because several boards would be stacked on top of one another, it was important that it be possible to see through them. The possibility of a semi-transparent board was considered, but it caused performance issues and could not easily be clicked through. For these reasons it was decided that the boards would be represented with simple white gridlines on the borders between squares. This loses the marking of black and white squares, but in Time Chess this is made less important by the more varied movement that the pieces are capable of. For example Time Bishops are not guaranteed to stay on the same colour of square in the way that regular bishops are.

27

28

Chapter 4

Implementation
4.1 Technology Choices
4.1.1 Why Python?

Python is an interpreted, general-purpose high-level programming language. I decided to use it in this project for a number of reasons. Python is well suited to the project. Because it is high-level, interpreted, and dynamically typed, Python is well suited to a rapid prototyping style of development, with large numbers of small, quick development-testing cycles. This suits my needs, because it must be possible to quickly change the workings of the game to experiment and test new game rules. The standard library of Python is extensive, and there is a large community of third party modules providing all sorts of extra functionality. This is useful because it keeps the possibility of extra features open. For example, if I want to add functionality to play Time Chess over a network later, I know that there are a wide variety of modules to ease network communications in the standard library, providing good support for a number of protocols, including HTTP, XML-RPC, Telnet etc. There are also lower-level networking and data processing modules like socket, ssl and json which would make it easy to design my own. The same is 29

true for other areas of expansion like display, interaction, data storage etc; There are modules for almost anything Id be likely to need.

4.1.2

Why NumPy?

I decided to use NumPy to store the game state. NumPy is a module for Python which allows the creation of large, multi-dimensional arrays and matrices, and includes a large library of high-level mathematical functions to operate on these arrays. I made this decision for several reasons. Speed is potentially very important for an application like this, and Python, being an interpreted language, is not particularly fast. The NumPy module is written in native C code and runs very quickly (Cai, Langtangen & Moe 2005). Elegance is made possible by closely corresponding metaphors. A game of chess in which time is a valid dimension of motion, translates very neatly into a 3D array of chess pieces. The wide array of high level functions NumPy provides for handling 3D arrays is likely to contain many direct analogues to operations one may want to perform on a Time Chess game.

4.1.3 Why VPython?

The visual module provides Python with a simple way to make 3D graphics. I chose originally to use it for the visualisations used to help me imagine the rules of Time Chess, and decided that it would be well suited to the task of making a full 3D Time Chess GUI. I feel that it is well suited to the task for the following reasons: Simplicity is one of the modules main selling points. Its tag-line is 3D programming for ordinary mortals, and it was designed to allow students of physics with no prior knowledge of programming to write 3D physics simulation and demonstration programs (Scherer, Dubois & Sherwood 2000). I am simply attempting to

30

represent the game state in a clear way, and to allow a user to interact with it, so this simplicity helps to avoid unnecessary complications. Features like variable opacity, complex lighting, pixel shader enhanced material eects etc. are available if required, but set to sensible defaults to allow them to be ignored. Cross-platform support is an important feature. It doesnt make sense to lose the benets of using a cross-platform language by binding to a single platform 3D library.

4.2

Implementing The Time Chess Engine

This section covers two levels of detail. One is the broad overview to give a feel of the structure of the software, and the other is specic and quite detailed description of the workings of the program wherever it is doing something particularly complicated or interesting.

4.2.1

Implementation Description

If the whole system is a form of Model View Controller, then the engine plays the part of the model and the controller, with the interface playing the part of the view. 4.2.1.1 The Pos Object Pos objects represent positions in the game. They have three coordinates, x, y and t. They can be initialised either by giving these coordinates separately, or in the form of Time Chess Position Notation (see section 3.2.3). 4.2.1.2 The Piece Object Piece is a parent class for the subclasses Pawn, Rook, Knight, Bishop, Queen and King. Objects of these classes represent pieces, but more specically they repre31

sent a specic instance of a piece in a game. For example, the White King is one piece in the game, but is represented by several King objects, one for each turn in which the King exists. If the King doesnt move, there might be King objects at e1t0, e1t1, e1t2 and so on. Two Piece objects represent the same in-game piece if they share the same pieceId attribute. The Piece objects representing one ingame piece form a lineage , with the same pieceId attributes and sequential age attributes. 4.2.1.3 The Game Object Within the MVC structure, the Game is the model. It is eectively a data structure class, mostly concerned with storing the state of the board in a game of Time Chess. It inherits from a NumPy array object, and can be thought of as a thin wrapper around a three-dimensional array of Piece objects. A major function of this wrapper is to allow the array to be indexed into using Pos objects, but it also provides some extra functionality for nding sets of pieces that meet certain criteria. 4.2.1.4 The TimeChessEngine Object

The TimeChessEngine object plays the role of the controller in the MVC architecture. It contains a Game object, and manipulates it in accordance with the rules of Time Chess as the game progresses. It handles commands from the view mostly using the attemptMove method, through which the view can relay intended moves from the user. The TimeChessEngine is responsible for calculating if moves are legal, and working through their ramications on the state of the Game object.

4.2.2
4.2.2.1

How it works
Overview

When the program is started, a new TimeChessEngine object is created. It initialises itself, making a fresh Game object with the board in its starting position.

32

When attemptMove is called with a Move, the system rst checks whether the given move is legal according to the rules of Time Chess. If it is illegal, attemptMove returns a false Result and concludes. If the move is legal, it is carried out. A move in the present simply moves a piece on the board in the current turn. A move to the past makes an instance of the moved piece at the destination and propagates the changes up to the present. A move into the future adds an entry into the futureQueue, which stores in transit pieces. Once the move has been carried out, the futureQueue is checked for legality (since the move may have rendered some of the moves illegal), and any travellers due to arrive on the board this turn are placed on the board. The system then checks to see if the turn resulted in checkmate. If it did, the game is over, but if it didnt, the turn is incremented, the contents of this turns layer are propagated up to the next layer, and the system waits until attemptMove is called again, for the other side to make a turn. 4.2.2.2 Implementing Forward Time Travel

The original design was that movements into the future would simply involve removing the piece from its starting location and placing it in its nishing location. However, this turned out to be insucient for a few reasons, most important of which is the Lost in Time Rule (section A.4.2). Because the legality of a forward time travelling move cannot be known for sure at the time the move is declared, placing the new piece directly at its target position on the board would be premature, since the move may be rendered illegal in the intervening turns. The solution chosen to deal with this was to maintain a collection containing all of the pieces which are attempting to travel forwards in time. When the part of the turn sequence comes for pieces to come out of time travel, this collection is examined, and any pieces which are due to come out of time travel at this turn must rst verify that their move has been legal, and if it is, they appear, and if it isnt, they become Lost in Time. A future move can become invalid in a few dierent ways. The rst occurs

33

when the piece making the move is captured in the past. The piece was taken before it could make the move into the future, so the future move never happened. This is checked for by nding the immediate predecessor to the piece in the futureQueue (see section 4.2.2.3 for more about nding predecessors). If the piece has been taken, it will not be possible to nd its parent, so the system knows that the time travelling piece has been killed in the past and never got to make the move into the future. The second way in which a move stored in the futureQueue may become invalid is blocking (section A.3.1), which occurs when pieces are positioned in between the piece and its destination. This is checked for by nding the parent of the travelling piece, and ensuring that the move it is making is still returned by the parents getMoves object. If a piece has moved in the way of the move, getMoves will no longer list it as a possible move (see section 4.2.2.4 for more about nding possible moves for a piece). Pawns have a special case, because they can move forwards, but can only capture diagonally. So if a Pawn moves diagonally into the future, in order for the move to be legal, there must be an opposing piece there to capture, or the Pawn would not have been able to make the diagonal move. 4.2.2.3 Implementing Backward Time Travel Implementing backwards time travelling moves proved to be an especially challenging task, which required substantial refactoring. The original design for the Game object was an array of signed integers, with each integer representing a piece. Zero denoting an empty space, positive numbers for white pieces and negative numbers for black pieces, with each piece type being its own number. This had the advantage of keeping the array small in memory and fast to copy, but proved too simple. The diculty occurs when the system tries to deal with taking pieces back in time. The rules state that when a piece is taken in the past, all occurrences of the piece between the time it is taken and the present

34

are removed from the game (section A.5.1). The problem then arises of how to nd all the instances to remove from the game. If the Black Queen is taken in the past, that piece is represented by the integer -5, so its a simple matter of changing all occurrences of -5 in the array between the time of capture and the present to 0. However, if the White Knight is taken, represented by the integer 3, removing all 3s from the required turns will remove both white knights, not just the one that has been captured. One solution to this issue that was considered was using separate integers for each specic piece, like a piece ID number. White Pawns could be 1 to 8, Black Pawns 1 to 8, Rooks as 10, 11, 10 and 11, Knights as 20, 21, 20 and 21, and so on. However, there was another aw with using simple integers. When a piece travels back in time, it then sits still in the intervening turns as a braindead piece (see section A.5.2). Thus in the turns between the start and end of the backwards move, there may be more than one instance of the same piece - the original as it was on the rst pass, and the older time traveller copy making the second pass. If that piece is subsequently captured at a point in its timeline between the times of the two copies, only the older copy should be destroyed. But a simple integer identier for the pieces gives no way of knowing which piece is the original, and which the older time travelling copy. Because of these limitations, it was decided to store an object in the array the Piece object - rather than a simple integer., and represent empty spacesPiece objects have a pieceId attribute that keeps track of which in-game piece they represent, and an age attribute, keeping track of how many turns they have directly lived through at that point. When the turn changes, the makeChild method is called for every Piece in the old turn, which produces a child Piece with the same pieceId as the parent, and an age of the parents age incremented by 1. The resulting Pieces populate the new turn. Using this system, the proper removal of instances from the board is simple - just remove every piece with the same pieceId as the captured piece, and equal or greater age. In this way any form of

35

convoluted time travel situation can occur, and if a piece is taken, all instances of it further on in its timeline are destroyed. This is done by the eraseLineageFrom method. 4.2.2.4 Finding Possible Moves for a Piece Every instance of a subclass of Piece knows its type, the board it is on, and its position on that board. The getMoves method returns a list of moves that may be legal for that Piece at the current time. However, a move returned by getMoves may still be illegal because of factors like check. Each subclass of Piece implements their own getMoves method, reecting how the pieces move dierently. For a piece type like Knight, getMoves simply returns moves to all of the positions a knights move away which are on the board and dont contain any pieces of its own colour. The movements of the Rook, Bishop and Queen follow the same general pattern, involving moves being available in a particular direction until the way is blocked by the edge of the board or by another piece. Rooks do this in the compass directions, Bishops do it diagonally, and Queens do both. Because of these similarities, movement for these pieces can be generalised out. This is done with the getMovesInDirections method, which is given a list of directions as 3D vectors, and goes through each one adding legal moves for as long as the path remains clear. 4.2.2.5 Pawn Promotion If a Pawn reaches the far side of the board, it is promoted and becomes a Queen. This is elegantly implemented using the id/age system described in section 4.2.2.3. When makeChild is called on a Pawn object to produce the next instance of the in-game piece, the Pawn rst checks to see if it is on the rst or last ranks of the board (since Pawns can never move backwards, the piece does not need to ensure it has reached the opposite end of the board, because a Pawn can never reach its own

36

end). If the Pawn is at the end of the board, instead of creating a new Pawn object with the same pieceId and incremented age, it creates a Queen object instead. The nice thing about this is that the Queen object has the pieceId attribute of the Pawn it once was, so if the Pawn is captured in the past, before it was promoted to a Queen, the Queen is still destroyed in accordance with rules described in section A.5.1. 4.2.2.6 Checking for Check The state of check occurs when an opposing piece is in a position where it can attack the King (see section A.6). The TimeChessEngine object tests for the state of check with the isInCheck method. This method works by nding all moves available to the enemy and checking whether and of those positions contain an instance of the King. In many Chess implementations, check is tested more quickly by looking backwards, starting from the position of the King and looking for knights in the positions one knights-move away, pawns one pawns-move away and so on. This is faster because there is only one King, and many pieces that could attack it. However in Time Chess this is not necessarily the case. Because the king can be attacked in the current turn or any turn before it, there may be a large number of positions which, if attackable, would cause check. Since the only pieces that can threaten the king are those in the current turn (since pieces may only be commanded from the present), there are at most 16 pieces which could threaten the king, and generally fewer, since check is more likely to happen towards the end of the game when many pieces have been taken. 4.2.2.7 Checking for Checkmate The state of Checkmate occurs when a side has no available moves that would not result in their king being in check. Because of the complex nature of Time Chess, we could nd to way to detect

37

if a move ends in check, other than simply making the move and then checking to see if the move ended in check. This means that in order to detect checkmate, you must check every move available, to be sure that every one of them ends in check. The moveEndsInCheck method returns whether or not the given move ends in check. To achieve this, it rst makes a deep copy of the TimeChessEngine object. A deep copy of a composite object is a copy not only of the object, but of the objects it contains, so a deep copy of the TimeChessEngine object also copies the Game object and its contained Piece objects, making a full copy of the game state. The copy is given the move to execute by the attemptMove method, and the isInCheck method is then called to see if the copied game is in check. Performance The isInCheckmate method must call moveEndsInCheck on every move available, to ensure that they all end in check, and thus that the game is in checkmate. This means that detecting checkmate is the most expensive operation in the program by a substantial margin. Some measures were taken to improve its performance. Firstly, not all possible moves must be searched. As soon as a move is found which does not end in check, there is no checkmate, so the search can stop there. This means that isInCheckmate runs quickly for most non-checkmate game states, because as soon as it nds a move that doesnt end it checkmate, it stops. Secondly, the number of possible moves that need to be checked can be reduced by 33% or more by eliminating future moves for everything other than the King. A move into the future eectively removes a piece from the board for a number of turns, so no move into the future (by a piece that is not the king) can ever result in a checked king no longer being in check.

38

4.3

Implementing the 3D Interface

4.3.1 Implementation Description

4.3.1.1 The Piece Object

The Piece object represents a 3D object that looks like a Chess piece. It gets most of its functionality by inheriting from the VPython frame object, which is designed as a container for other VPython 3D objects. The frame holds all of the objects together in one frame of reference, eectively grouping them into a more complex 3D object. For example, a Piece representing a pawn groups together a cone object and a sphere object, which together form the shape of a pawn. 4.3.1.2 The Ghost Object

The Ghost object represents ghost pieces, which are semitransparent pieces used to indicate positions where pieces will come out of time travel in the future. They inherit from Piece and their only dierence is a lower opacity. 4.3.1.3 The Layer Object The Layer object represents the state of the board during one turn of the Time Chess game. It also inherits from frame, and groups together some curve objects, which show as white gridlines separating the positions on the board, and the Piece objects on the board. 4.3.1.4 The Controller Object The Controller object is responsible for conveying user input to the game engine, and updating the 3D scene to show the results.

39

4.3.2 How it Works

4.3.2.1 Overview When the program is started, a controller object is created. The Controller object initialises itself and opens a connection to a program which is started by a command given on the command line. The intention is for this program to be an engine or other program that supports TCECP through stdin and stdout. In this implementation this is TCECPInterface.py, which runs a TimeChessEngine object, supplying it with commands it receives, and returning the results. The Controller then enters a game loop, in which it handles mouse and keyboard input from the user. When interaction with the engine is required, the send, recv and communicate methods are used to send and receive TCECP messages. The showLayer and hideLayer methods are used to create and hide layers of the board, and the makeHighlight and clearHighlights methods are used to create and destroy possible move highlights. 4.3.2.2 Creating Pieces

Because Piece objects have no behaviour determined by their type, it didnt make sense to have a large number of subclasses, one for each piece type. There is only one Piece class, which can have the appearance of any piece type. This is achieved by a data structure that stores the attributes of the 3D objects that make up each piece type, and a generalised method to build them, which makes use of a lot of Pythons more advanced features, such as tuple unpacking, module dictionaries and keyword argument unpacking. The geometries data structure is a Python dictionary (like a hash table) which uses piece type characters (b for bishop, r for rook etc) as the index to store a list of entries which form the instructions to make a specic simple geometric object. This is best demonstrated with examples. In gure 4.1, we can see that the pawn piece type (represented by the character p) is made up of two pieces of geometry; The rst is a cone positioned 40

geometries = { "p":[ ("cone", ("sphere", ], ...

{"pos":(0,0,0), "axis":(0,0,.5), "radius":.3}), {"pos":(0,0,.5), "radius":.15})

"k":[ ("cylinder", {"pos":(0,0,0), "axis":(0,0,.7), "radius":.2} ), ("box", {"pos":(0,0,.85), "width":0.1, "height":0.1, "length":.3, "axis":(1,0,0)}), ("box", {"pos":(0,0,.85), "width":0.1, "height":0.1, "length":.3, "axis":(0,0,1)}), ] } for prim, args in geometries[ptype]: visual.__dict__[prim](frame=self, color=col,**args)

Figure 4.1: System to generate 3D objects from stored geometry information at the origin, with an axis of 0.5 units straight up, and a radius of 0.3 units, and the second is a sphere located 0.5 units up from the origin (at the top of the cone), with a radius of 0.15 units. The last two lines of gure 4.1 construct the required geometry objects for the given piece type (stored in the ptype variable). The for loop iterates over the list returned by geometries[ptype], and unpacks each item into the variables prim and args. In the case of a pawn, where ptype='p', the rst iteration of the loop would occur with prim="cone" and args={"pos":(0,0,0), "axis":(0,0,.5), "radius":.3}. Inside the loop, the builtin dictionary of the visual module is accessed by the __dict__ attribute. Indexing into the modules __dict__ with the key "cone" returns the constructor for the cone object, which is then called. The ** before the args argument informs Python that args is a dictionary which is to be unpacked into keyword arguments. So for the rst iteration of the loop for a pawn, the line
visual.__dict__[prim](frame=self, color=col,**args)

is eectively translated into

cone(frame=self, color=col, pos=(0,0,0), axis=(0,0,.5), radius=.3)

41

This sort of dynamic introspection is one of the things that makes Python such a powerful language. 4.3.2.3 Displaying Layers The process of using the TCECP interface to request the contents of a layer from the engine and then constructing 3D objects from that data is time consuming, and should not be done more often than necessary. So, Layer objects have a turnMade attribute, which stores the turn the game was at when the Layer was made. When the Controller requires a layer to be displayed, it calls the showLayer method, which rst checks the existing Layer object for that layer to see if it was made this turn and thus is up to date. If the layer is out of date, buildLayer is called to create a new Layer object with data fetched from the engine. The hideLayer method does not destroy the Layer object, but simply sets its visible attribute to False. The visible attribute is an attribute of the VPython frame object, which causes the object to disappear from the 3D scene, but stay in memory. If showLayer is called and an existing Layer object is up to date, it is simple set to be visible, and no new layer must be built. This eectively works as a cache of 3D objects, improving performance.

4.4

Extra Features

4.4.1 Stereo
In the course of a game of Time Chess, complex 3D congurations of pieces must be analysed. This can become dicult when there are many overlapping layers of varying opacity, because the user has no sense of depth perception. By rendering two images of the scene as seen from slightly oset camera positions, and mapping the right one to the red channel and the left to the blue channel (gure 4.3), a stereoscopic 3D eect can be produced for users wearing red/blue lter glasses (gure 4.4) (Konrad & Halle 2007).

42

Figure 4.2: Complex, densely layered scenes can be dicult to understand Since user preference will vary, and not all users will have red/blue glasses available to them, this feature can be toggled on and o with the s key.

43

Figure 4.3: Red/Blue Stereo can enormously improve game immersion and ease of use

Figure 4.4: Red/Blue Filter Glasses used for stereo viewing

44

Chapter 5

Evaluation
5.1 Diculty for Computers

5.1.1 Branching Factor

One of the factors that makes a game dicult for move-space searching AI algorithms is a high branching factor. Since one of the aims of Time Chess was to have a high branching factor, this will be evaluated. Chess has a branching factor of about 35 (Larame 2000). This number was calculated by taking a large corpus of good quality games, calculating the number of legal moves available at each point of the game, and taking a mean. We dont have a large corpus of good quality games, because there are as yet no good Time Chess players. To obtain some data to give a rough idea of a branching factor, a program was written to play games by picking moves randomly from the set of legal moves for each turn. The result of ten such games is shown in gure 5.1. As expected, the branching factor falls as the game goes on, as pieces are taken. I believe this is not a particularly good representation of a real human game, because the random choice loses a lot of pieces in time, by jumping pieces blindly into the future with no care for clearing a path for them. Many, possibly most future moves, while perfectly legal, are eectively suicide because there is no easy way to ensure that the move remains legal until the piece reappears at its desti-

45

140 120 100 Branching Factor 80 60 40 20 00 20 40 60 80 Turn number 100 120 140

Figure 5.1: Mean branching factors for ten games of random Time Chess nation. This is likely to have led the branching factor to fall more rapidly than it normally would, as pieces like Queens, which contribute a lot of options, are for that very reason highly vulnerable to being Lost in Time by random movement choice. Nonetheless, the mean branching factor overall was 68, which is approximately twice the branching factor of Chess. This is high enough for Time Chess to be considered to have achieved its aims with regard to branching factor.

5.2

Unit Tests

The Python programming language provides good support for unit tests in the standard library, through the unittest module (Oboyle, Tenderholt & Langner 2008). Unit tests were written for major features and edge cases, and used for regression testing when new feature were implemented.

46

5.3

User Acceptance Testing

Late in the development process, the alpha release level software was tested by a number of third party volunteer software testers, of varying levels of experience in computer use and Chess. During this testing a number of bugs were discovered and corrected.

5.3.1

The King becoming Lost in Time

A bug that was discovered during later stages of play testing was that of losing the King in time. The possibility of a King becoming Lost in Time had been briey considered, but dismissed as impossible, since a King can move at most one turn forwards in time. When a piece moves forward in time by one turn, it disappears, the opposing side has a move, and then the time travelling piece reappears at its destination. Blocking is thus impossible, because any opposing piece attempting to block will simply be taken by the reappearing piece. A move forward of one turn doesnt move through any intermediate spaces, so there are no spaces which can be lled by an opposing piece attempting to block it. However, this thinking was incomplete. While its true that its impossible to cause a King to become Lost in Time by blocking it, thats not the only way a piece can become Lost in Time. A piece is Lost in Time if a forward time travelling move it made is rendered illegal before it is complete. So if a piece moves forward in time to a position which is already occupied with a piece of the same colour, the time travelling piece becomes Lost in Time, because its not legal to take a piece of the same colour. With a King this almost certainly has to be done deliberately, since the only way it could happen is if the King is moved one forward in time and one position in space, to a space directly above an existing piece of the same colour. It should be clear to the player making the move that as soon as the opposition has its turn,

47

the piece the King is over will still be there when the King tries to reappear, which makes the move illegal and renders the King Lost in Time. This move is so clearly stupid that I had never thought to try it. Theres a lesson here about the benets of play testing. So, when the play tester made this stupid move, their King became Lost in Time. But because Lost in Time pieces are not captured, just gone, the system did not detect any problems. The King was not on the board, but it wasnt checkmated, so the game continued. Not only was the King not checkmated, it was now un-checkable from that turn forwards, because it was no longer on the board! It was not a stupid move at all, in fact it was probably the best move in the game, rendering the King almost completely un-checkable! Clearly this was a gamebreaking loophole of the kind I decided not to allow in section 3.2.1.3 I examined several possible solutions. 1. Dont allow the King to move to positions directly above pieces of the same colour. The problem with this is that it is possible for this move to not result in the King becoming lost in time, since the piece can be captured in the intervening turn, making the Kings move legal. This is extremely unlikely, since not only would the player need to decide to take the very risky move of moving their King forwards in time to directly above a piece of the same colour, but their opponent would have to then decide to capture that piece to make the move legal again. But however unlikely this is, it is legal, so declaring the all moves to directly above pieces of the same colour illegal would reduce the branching factor of the game unnecessarily, which goes against section 3.2.1.2. 2. Make the King capture any piece it lands on when reappearing from time travel, even pieces of the same colour.
Its worth noting that the King was not completely invulnerable, as it could theoretically still be checked in the past before it made the move that caused it to become Lost in Time.

48

This would be very simple to implement, and would x the problem, but it has a wider reach than just making the King never be lost in time. It introduces a strange precedent of deliberately taking your own pieces, which is inelegant and divergent from chess, going against section 3.2.1.1 3. State that if a King becomes lost in time, the game is lost by the owner of the King. This is the solution I chose. It keeps options open, and doesnt change the rest of the game, but punishes players for deliberately causing their King to be Lost in Time.

49

5.3.2 Survey
After using the software, testers were asked to rate their agreement with a series of statements, on a scale of 1 to 5. Number 1 2 3 4 5 Meaning Strongly Disagree Disagree Neither agree nor Disagree Agree Strongly Agree

To what extent do you agree with the following statements? 1. I am a skilled Chess player (here 1 means you never play Chess, 5 means you play in competitions) 2. I found the concept of Time Chess confusing. 3. The Rules of Time Chess document helped me to understand the game 4. Playing the game on the computer helped me to understand the game 5. I feel that I now understand the game well 6. I found the game fun to play 7. Playing Time Chess required more thought than playing Chess 8. Playing Time Chess required a dierent kind of thought to playing Chess 9. The 3D interface was easy to use 10. The 3D interface gave me all the information I needed to make decisions 11. The game was stable (it didnt crash or have many glitches) 12. The game was responsive

50

The results of the survey are shown in gure 5.2.

Figure 5.2: Mean Responses of the Survey Participants The mean self-assessed Chess skill of the testers was 2.7, meaning on average testers considered themselves casual chess players. Time Chess does not seem to have been thought to be confusing, or at least people were not prepared to admit that they found it confusing, averaging 2.8 on that question. Playing the game through the 3D interface was found to be more eective than reading the documentation at teaching testers to understand the rules. Many test participants also had discussed the nature of the game with the designer before testing, which is likely to have biased those results. The combination of rules documentation and playing the game was deemed successful in helping users to understand the game, with testers on average agreeing that they now understand Time Chess. The game was agreed to be fun on average, with no individuals rating lower than 3. Testers strongly agreed, with an average of 4.4, that Time Chess required more thought than ordinary Chess, and also agreed, though less strongly with an average of 3.6, that Time Chess required a dierent kind of thinking to regular Chess. 51

The interface was agreed to be easy to use (mean rating of 3.6), but not thought to provide all the information useful to making Time Chess decisions (mean rating of 2.4). Follow-up questions about this failing found that testers would have liked more ne control over exactly which turns are viewed at any time, rather than just seeing which turns can be aected by a pieces movement. It had been assumed that unless a player wanted to move a piece to a turn in the past, they would not want to see that turn, but this turned out not to always be the case. The interface was agreed to be stable (there were no unexpected crashes during testing), rated on average at 3.7, and acceptably responsive (mean rating 2.9). The responsiveness score is likely to be caused by the lag in detecting cases of checkmate. Running cross correlations between the questions, we nd a lot of things that are fairly obvious; More skilled chess players are less likely to nd Time Chess confusing, more likely to say they understand it, and more likely to nd it fun. So Time Chess appeals more to skilled Chess players. Also, better Chess players are more likely to have gained more understanding from reading the rules, relative to playing the game. It seems skilled players were more able to understand the written rules, and people who played less Chess learnt better from the hands on experience of playing the game. Theres a very strong negative correlation between nding Time Chess confusing and nding it fun. People do not seem to enjoy being confused. This was a little unexpected, because the complexity of Time Chess is one of its selling points. It is possible that those who enjoy being confused are less likely to report their experiences as being confusing, because it is more likely to be remembered as a learning experience. Its worth noting that the sample size of this survey is too small to make statistically signicant claims, but as far as conclusions can be drawn from this data, Time Chess seems to have broadly achieved its aims.

52

5.4

Requirements

The requirements for the project are specied in section 3.3.1, and nothing would be gained by repeating them all here with check-marks next to them. All of the requirements specied were met, and some extra features (like those mentioned in section 4.4) we also added. From a requirements perspective, the project was a success.

53

54

Chapter 6

Summary
6.1 Further Work
The obvious and intended follow-up work to this project, as stated in the project aims (section 1.1), is the development of an Articial Intelligence solution able to play Time Chess to a good standard. However this is not the only opportunity for expansion on this work that presents itself.

6.1.1 Interface Improvements

The 3D interface broadly met its stated aims, but the survey indicated that testers were not entirely happy with the level of information it provided, so there is room for improvement to the interface in future work.

6.1.2

Accurate Complexity Estimates

The calculation of the mathematical complexity of games like Chess and Go has had articles and papers dedicated to it (Storer 1983, Crsmaru 1999). This document touched briey on the subject of calculating some complexity measures for Time Chess in section 5.1.1, but there is a great deal more work that could be done in making more accurate measurement of branching factor, as well as estimating the size of the games state-space and other complexity metrics.

55

6.1.3 Aective Analysis

Since one of the main stated aims of Time Chess as a game was to have a high cognitive load, this should be assessed in more detail than time and resources allowed. The survey (section 5.3.2) asked testers how much they agreed with the statements I found the concept of Time Chess confusing and Playing Time Chess required more thought than playing Chess, and the responses suggested that playing Time Chess was likely to have a high cognitive load. However this approach is very limited. Self-reported aect information is known to be unreliable (Clark & Watson 1988), and even if this data is accurate it is very simple and one dimensional. The eld of Aective Computing has a lot to oer here, in terms of the accuracy, detail, depth and volume of data that is achievable. One of the main elds of focus for current AC research is education (Tao & Tan 2005), a eld in which assessing confusion and cognitive load are important goals, so fairly robust systems have already been developed for that purpose (Ikehara & Crosby 2005). There is also substantial existing research into measuring the aect of test subjects playing educational games (Sykes 2006). Time Chess is not a particularly educational game, but techniques for measuring aect in a gaming individual would be readily transferable to the task of measuring cognitive load in the mind of a Time Chess player. Information gathered from the interface, such as time taken for each move, number of pieces selected and examined before move selection, time spent adjusting views of the board, time spent inactive etc. could be examined as possible determinants of cognitive load, as could facial analysis techniques. By gaining clear, detailed, temporally and contextually indexed empirical data on the aect of people playing variants of Time Chess, the game can be optimised for mental challenge.

56

6.1.4 Personal Reections

The idea of Time Chess occurred to the author at a young age, at a time when actually implementing it was an unreachable goal. Although the original idea was, in the course of its being rened and eshed out into a full specication, found to be a logical impossibility, a working version of the rules could be devised which kept to the spirit of Time Chess. It is satisfying to have the skills and opportunity to nally realise an idea which has been harboured for almost a decade, and in the course of doing so to make both a fun game and what is hopefully a useful contribution to the eld of AI research.

57

58

Bibliography
Allis, L. (1994), Searching for solutions in games and articial intelligence, Ponsen & Looijen. Cai, X., Langtangen, H. & Moe, H. (2005), On the performance of the Python programming language for serial and parallel scientic computations, Scientic Programming 13(1), 3156. Clark, L. & Watson, D. (1988), Mood and the mundane: Relations between daily life events and self-reported mood., Journal of Personality and Social Psychology 54(2), 296. Coles, L. S. (2002), Computer chess: The drosophila of ai. URL: http://www.drdobbs.com/high-performance-computing/184405171 Crsmaru, M. (1999), On the complexity of Tsume-Go, Lecture notes in computer science pp. 222231. GNU Project (n.d.), GNU Chess SVN Repository. URL: http://svn.savannah.gnu.org/viewvc/trunk/src/?root=chess Hilborn, R. (2004), Sea gulls, butteries, and grasshoppers: A brief history of the buttery eect in nonlinear dynamics, American Journal of Physics 72, 425. Ikehara, C. & Crosby, M. (2005), Assessing cognitive load with physiological sensors. Iqbal, A. (n.d.), What Computer Chess Still Has to Teach Us. 59

Konrad, J. & Halle, M. (2007), 3-D displays and signal processing, Signal Processing Magazine, IEEE 24(6), 97111. Larame, F. D. (2000), Chess Programming. Nahin, P. & Nahin, P. (1994), Time machines, AIP Press. Oboyle, N., Tenderholt, A. & Langner, K. (2008), cclib: A library for packageindependent computational chemistry algorithms, Journal of computational chemistry 29(5), 839845. Paas, F., Tuovinen, J., Tabbers, H. & Van Gerven, P. (2003), Cognitive load measurement as a means to advance cognitive load theory, Educational psychologist 38(1), 6371. Pritchard, D. & Beasley, J. (2007), The Classied Encyclopedia of Chess Variants, Beasley. Scherer, D., Dubois, P. & Sherwood, B. (2000), VPython: 3D interactive scientic graphics for students, Computing in Science & Engineering 2(5), 5662. Shastall, J. (n.d.), Temporal Chess. URL: http://www.squidoo.com/temporalchess Shannon, C. (1950), XXII. Programming a computer for playing chess, Philosophical Magazine (Series 7) 41(314), 256275. Stanford University (2008), Stanford Encyclopedia of Philosophy on Time. URL: http://plato.stanford.edu/entries/time/ Stone, R. (n.d.), A Brief Study and Review of Chess and Go Articial Intelligence. Storer, J. (1983), On the complexity of chess, Journal of Computer and System Sciences 27(1), 77100. Syed, O. & Syed, A. (2003), Arimaa-a new game designed to be dicult for computers, International Computer Games Association Journal 26, 138139. 60

Sykes, J. (2006), Aective gaming: advancing the argument for game-based learning, Aective and emotional aspects of human-computer interaction pp. 37. Tao, J. & Tan, T. (2005), Aective computing: A review, Aective Computing and Intelligent Interaction pp. 981995. Van Gelder, A. (1987), Ecient loop detection in Prolog using the tortoise-andhare technique, The Journal of Logic Programming 4(1), 2331.

61

62

Appendix A

The Rules of Time Chess

For the purposes of this document, it is assumed that the reader is generally familiar with the rules of standard Chess. Because Time Chess is a chess variant, it shares a substantial part of its setup and rules with Chess.

A.1 Board and Pieces

Time Chess pieces are closely related to Chess pieces, and share their names, symbols, appearances, and much of their behaviour. If an aspect of a piece is not specied in this document, it may be assumed that it shares that aspect with its equivalent in Chess. Time Chess is conceptually played on a standard Chess board, and could be played using one or more physical Chess boards, however this would be impractical. Time Chess is only practically played on a computer, which will generally model the game as a three dimensional object which can be thought of as a stack of Chess boards. Each layer of the stack archaeologically represents a turn of the game, and the stack becomes taller (or deeper) as the game progresses.

63

A.2

Objective

The objective of Time Chess is broadly the same as that of Chess - To place the opponents King under attack, such that your opponent has no legal moves.

A.3 Movement
Time Chess piece movements can be thought of as Chess movements generalised and extruded into a higher dimension. As well as moving around the board as normal, pieces can move both forward and backward in time. Their time travelling movement options closely mirror their normal movement options. A Rook in Chess may pick a direction, x+, x, y + or y and move any number of places in that direction. So a Time Rook may pick a direction, x+, x, y +, y , t+ or t, and move up to 7 of places in that direction. Positive movement in the t dimension is movement forwards in time, negative movement in the t dimension is movement backwards in time. A Bishop in Chess picks two orthogonal directions and moves an equal number of places in each of those directions, eectively moving diagonally. The same is true of a Time Bishop, but it also has the choice of t+ and t as directions. See Figure A.1. . . . . t2 . . . . . . .. . . . . . . . . . t+2 . .

. .

. . B .

. .

. .

t1 .

t .

t+1 .

Figure A.1: Movement of a Time Bishop (within a two place radius)

A Knight in Chess picks two orthogonal directions, and moves two spaces in one dimension and one space in the other. Again, this is extruded into the

64

higher dimension of time to provide the Time Knight movement shown in Figure A.2 . . . . . . . t1 . . . . . . N . . t . . . . . . . . . t+1 . . . . . .

. .

t2 .

t+2 .

Figure A.2: Movement of a Time Knight

A Queen in Chess picks either one direction or two orthogonal directions, and moves any number of places in those. This makes a Queens possible move set eectively the union of the move sets of a Bishop and a Rook. The same is true of a Time Queen, as seen in Figure A.3. . . . . . t2 . . . . . . . . t1 . . . . . . . . . . Q . . . t . . . . . . . . . . . . . t+1 . . . . . . t+2 . .

Figure A.3: Movement of a Time Queen (within a two place radius)

A King in Chess can move one space in either one direction or in two orthogonal directions. The Time Kings movement is the same with possibility of forwards and backwards in time as directions.

. . . . . . t1 . .

. . .

. K . . t .

. . . .

. . . . . t+1 .

Figure A.4: Movement of a Time King

Time Pawn movement is show in gure A.5. The Time Pawn can move to 65

positions marked with 1 if they are unoccupied, and to positions marked with 2 if the pawn has not moved before, and the target position and the 1 position between the pawn and the target position are both unoccupied. It can capture opposing pieces in positions marked with an . 2 .. 1 . .. . p . . .

.. 1 . . .

2 ..

t .

t+1 .

t+2 .

Figure A.5: Movement of a Time Pawn

A.3.1 Blocking
For all pieces other than the Knight, movement cannot be made through an occupied space. This applies in time as well - for a piece to move to a position, all the spaces in between must be empty. Thus the location of pieces in past turns decides which moves into the past are possible, and the locations of piece in the future determines what moves into the future are possible. p . p . B . . t2 . . t1 . .

t .

Figure A.6: Blocking: The Bishop could normally move to point p, but cant in this case because the Pawn is in the way.

A.4

Forward Time Travel

When a player declares that they are moving a piece forward in time, that piece is removed from the board. When the turn that the piece was moved to comes 66

around, at the end of that turn the piece is placed at its destination.

A.4.1

Appearance Order

If two pieces are due to arrive from forward time travel in the same turn, the one which departed rst arrives rst. This is generally only signicant if both pieces are arriving at the same square at the same time.

A.4.2

The Lost in Time Rule

The legality of a forwards time travelling move is not necessarily known at the time the move is made. This is because the move may require certain spaces to be empty, but at the time the move is made, the state of the spaces is yet to be determined. Thus it is possible to render a forward time travelling move illegal after it has been made. If this happens, the in transit time travelling piece is said to become Lost in Time. A piece that is Lost in Time is never returned to the board, and is hors de combat. Note that this makes something similar to an En Passant rule for Pawn time travel, since a Pawn moving two spaces into the future may become Lost in Time due to a piece moving into the space one turn ahead of it. If a king becomes Lost in Time, the owner of the king loses the game.

A.5 Backward Time Travel

When a piece moves backwards in time, it is removed from its present position, and placed at its destination position.

A.5.1 Taking Pieces Back in Time

If a piece is captured in the past, all occurrences of the piece from the time it is captured to the present are removed from the game. Any consequences caused by the taken piece in the time between its capture and the present (pieces it has taken, moves it has made possible etc.) remain unchanged. 67

A.5.2 Braindead Pieces and Steamrollering

Since the players may only command pieces which are in the present, when a piece moves into the past it cannot be given commands, and thus will not move. Such a piece is said to be braindead in the time between its arrival in the past, and the present. It is propagated upwards towards the present in a straight line. While a piece is braindead, any piece of either colour which moves into a space occupied by it, destroys it. Naturally if an opposing piece happened, in the past, to move into a space occupied by a braindead piece, it would capture it, but the same is true of a piece of the same colour as the braindead piece. This is called steamrollering. The steamrollering piece could not have been ordered to move into an occupied space, but the space was not occupied when the order was given, so the move goes ahead and the braindead piece is steamrollered.

A.6 Check
Because pieces can be captured in the past, a King is in check if it can be attacked in the present or the past. If any past instance of the King is under attack, the King is considered in check.

68

Appendix B

Time Chess Engine Communication Protocol Specication

The Time Chess Engine Communication Protocol (TCECP) is a simple text protocol designed to facilitate communication between Time Chess engines and Time Chess GUIs. It is inspired by the Chess Engine Communication Protocol (CECP). The protocol works by exchanging single line messages. The GUI sends single line messages to the Engine. Some of these messages require the engine to respond with a line of its own. The Engine does not send messages to the GUI except in response to a message from the GUI.

69

B.1 Messages from the GUI to the Engine

new Abandon any ongoing games and make a new game, as though the system has just been started up. Expects no reply. ping <NUMBER> <POSITION> (e.g. a1t0) Check the engine is connected and responding. Request a list of moves possible for the piece at <POSITION> (See section 3.2.3). <MOVE> (e.g. a2t0a4t0) getState t Attempt to make the move <MOVE> (See section 3.2.3). Get the current turn. In theory this need never be called, but a disagreement between the GUI and the Engine about what turn it is would be disastrous. getState <TURN> Request the state of the board at turn <TURN>

70

B.2 Messages from the Engine to the GUI

pong <NUMBER> (In reply to ping <NUMBER>) Conrm that the engine is connected and responding by ponging the same number you were pinged moves (<POSITION>): [<LIST>] (In reply to <POSITION>) [<LIST>] is a list of moves possible for the piece at <POSITION>, as a valid JSON array of strings. (e.g. moves (a4t5):
["a4t5","a3t6"])

Move Result

(In reply to <MOVE>) Either the string Success if the move worked, or an error message in the format Illegal move (<REASON>): <MOVE>.
(e.g. Illegal move (Move puts you in check): a1t0a4t0)

<TURN>

(In reply to getState t) An integer showing the current turn number

state (<TURN>): [LIST]

(In reply to getState

<TURN>) [LIST]

is a list of pieces on the board at turn <TURN>, as a JSON array of arrays of the form each [<POSITION>,<COLOUR>,<TYPE>], representing a piece.
(e.g.

[["c3t30","w","k"],["e7t30","b","k"], ["e8t30","b","q"]])

futureQueue: [LIST]

(In reply to getState futureQueue) [LIST] is a list of pieces in the future queue, in the same format at the board state.
[["a1t5", "w", "r"]]) (e.g.

71

72

Appendix C

Time Chess 3D Interface: User Guide

C.1 Looking Around

Holding down the right mouse button and moving the mouse will rotate the board. Moving left and right spins the board horizontally, moving up and down tilts the board up and down. Holding down the middle mouse button and moving the mouse adjusts the zoom. Moving up zooms in, moving down zooms out.

C.2 Selecting Pieces

You can select a piece by clicking on it if it is that sides turn to move. Clicking on a Black piece when it is Whites turn (and vice versa) does nothing. To deselect a selected piece, click it again.

C.3

Moving Pieces

When a piece is selected, the places it can move to are shown by semitransparent red squares. Click one of the red squares to move the selected piece to that

73

position.

C.4
Key F P N S

Keyboard Controls
Eect Hide all layers representing the f uture Hide all layers representing the past Hide all layers representing either the future or the past, showing only now. Toggle red/blue stereoscopic 3D, viewable with red/blue lter glasses

74