You are on page 1of 74






40 C



Robert M

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:


May 5, 2011

Chess AI research has largely stagnated into optimisations of the same

paradigms, such that some believe research should focus on a different game.
We propose Time Chess, a Chess-related game designed to be interesting
and challenging for humans, and prohibitively complex for currently preva-
lent 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 specified, and sample implementations
of a Time Chess Engine and 3D Interface are designed and implemented,
along with a Protocol Specification to ensure compatibility between future
engines, GUIs and AIs.


1 Introduction 5
1.1 Aims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Background 7
2.1 Chess Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Current Chess AI . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Other HyperChesses . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Other Complex Games . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 Go . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2 Arimaa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Design 13
3.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Designing Time Chess as a Game . . . . . . . . . . . . . . . . . . 14
3.2.1 Game Design Principles . . . . . . . . . . . . . . . . . . . 14
3.2.2 Game Design Process . . . . . . . . . . . . . . . . . . . . . 15
3.2.3 Move Notation . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.4 Designing Backwards Time Travel . . . . . . . . . . . . . . 18
3.2.5 Designing the Movement of the Pawn . . . . . . . . . . . 22
3.3 Designing Time Chess as Software . . . . . . . . . . . . . . . . . . 23
3.3.1 Requirements Specification . . . . . . . . . . . . . . . . . 23
3.3.2 Engine Design . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Designing the 3D Interface . . . . . . . . . . . . . . . . . . . . . . 25
3.4.1 Piece Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.2 Boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

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

4.4 Extra Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4.1 Stereo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Evaluation 45
5.1 Difficulty for Computers . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.1 Branching Factor . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Unit Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3 User Acceptance Testing . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.1 The King becoming Lost in Time . . . . . . . . . . . . . . 47
5.3.2 Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6 Summary 55
6.1 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.1.1 Interface Improvements . . . . . . . . . . . . . . . . . . . 55
6.1.2 Accurate Complexity Estimates . . . . . . . . . . . . . . . 55
6.1.3 Affective Analysis . . . . . . . . . . . . . . . . . . . . . . . 56
6.1.4 Personal Reflections . . . . . . . . . . . . . . . . . . . . . 57

A The Rules of Time Chess 63

A.1 Board and Pieces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
A.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.3 Movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.3.1 Blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
A.4 Forward Time Travel . . . . . . . . . . . . . . . . . . . . . . . . . 66
A.4.1 Appearance Order . . . . . . . . . . . . . . . . . . . . . . 67
A.4.2 The ‘Lost in Time’ Rule . . . . . . . . . . . . . . . . . . . . 67
A.5 Backward Time Travel . . . . . . . . . . . . . . . . . . . . . . . . . 67
A.5.1 Taking Pieces Back in Time . . . . . . . . . . . . . . . . . 67
A.5.2 Braindead Pieces and Steamrollering . . . . . . . . . . . . 68
A.6 Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

B Time Chess Engine Communication Protocol Specification 69

B.1 Messages from the GUI to the Engine . . . . . . . . . . . . . . . . 70
B.2 Messages from the Engine to the GUI . . . . . . . . . . . . . . . . 71

C Time Chess 3D Interface: User Guide 73

C.1 Looking Around . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
C.2 Selecting Pieces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
C.3 Moving Pieces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
C.4 Keyboard Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Chapter 1


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 com-

puter implementation of Time Chess to make the game playable by pairs of hu-


1.1 Aims

Time Chess has two main (interrelated) aims.

The first aim of Time Chess is to have an extremely high cognitive load. In lay-

man’s terms, this can be thought of as “how difficult the game is to play”. However

this definition is insufficient, because ‘difficulty’ is a broad term which can refer

to many different challenges, including non-mental ones. Specifically, ‘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 mem-

ory in order to play. (Paas, Tuovinen, Tabbers & Van Gerven 2003)

Determinants of cognitive load include the number of possible moves avail-

able 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


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.

It’s 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


2.1 Chess Programs

There is a very large number of programs allowing humans to play Chess on a com-

puter. These are generally divided into Chess Engines and Chess User Interfaces. The

player(s) interact with the interface, and the interface communicates with the en-

gine, 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 ex-

ample 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 cham-

pion human players. But some researchers find existing Chess AI unsatisfying,

and Chess AI research has not provided as much that is useful outside of the field

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


What will be the significance of this accomplishment for other areas of

AI research? Sadly, not much. The brute force nature of the final solu-

tion 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 fields, these brute-force based ‘successful but boring’ approaches

must first 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 ex-

trude 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 different sizes. Programs like Parmen allow this game to be

played on a computer.

There is also Raumschach, a game played on a 5×5×5 board, and a large num-

ber of variants played on 8×8×3 boards, including Millennium 3d Chess and Drag-


Few attempts have been made to use Time as a dimension in HyperChess, and

those that have have not been very serious. Jay Shaffstall proposed a ‘Temporal

Chess’ (Shaffstall 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 un-

der 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 specifically de-

signed to be challenging for machine players.

2.4.1 Go

Go is a highly complex game (Allis 1994), and provides a much more difficult chal-

lenge in AI research than Chess. The reasons for this are explored in detail in

Crâsmaru (1999), we will only briefly summarise them here.

• The board is 19×19, 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 con-

trast 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 “What’s 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 difficult 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 in-

creases 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 num-

ber 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-

tremely large and difficult for an AI to handle, but doesn’t 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. Difference to Time Chess

The aims of Arimaa vary from those of Time Chess, in that Arimaa attempts to

be simple for a human and difficult 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, Ari-

maa is so radically different in its gameplay that it cannot be considered a ‘chess

variant’, but is rather a completely different game played on the same board. Ad-

vances in Arimaa AI may not be helpful in developing more interesting AI for nor-

mal 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.

Chapter 3


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 influenced 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 en-

gine can be rewritten to operate in a very different way, but as long as it still sup-

ports 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 different ones. Other programmers could develop their own inter-

faces, which could be completely different from mine but would work with the

engine without any reconfiguration. The components are unconcerned not just

with the nature of the other component, but also with the nature of the connec-

tion between them. My implementation will use operating system level pipes, but

the system could work just as well over a TCP connection for example.

3.2 Designing Time Chess as a Game

3.2.1 Game Design Principles

Before formalising the design of the game, I decided on some principles which I

wanted the game to adhere to. 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


• Piece movements should be their Chess equivalents extruded into a higher

dimension as literally as possible Be complex for computers

• The game’s state space should be large, as should the number of available

choices, to keep the branching factor high. Allow for interesting and tactical gameplay

• Attempt to ‘nerf the FOO strategies’, that is to say don’t allow ‘First-Order

Optimal’ strategies to allow players to win without requiring much skill 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 To hell with paradoxes

• Paradoxes should be either impossible to create, or trivial to resolve unam-

biguously and deterministically.

3.2.2 Game Design Process

The first 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 Fed-

eration. 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 figure 3.1. This made sure

that I properly understood the rules of Chess, since it’s 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 difficult to discuss verbally. English grammatical constructions are

very poorly suited to talking about time travel, so clear and consistent use of lan-

guage 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

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

was due to knowledge of a shared terminology with Chess. Chess terminology

could be exapted to describe related concepts in Time Chess, which confirmed

my belief that Time Chess should echo Chess as closely as practical, to aid under-

standing of the game by Chess players. Thirdly, because verbal discussion of the

rules was difficult, 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 difficult to express on a two-dimensional plane.

This need for a 3D way to explain the game, combined with the ineffectiveness

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 figure 3.2.

The excellent performance of the visual module for this task led to the deci-

sion 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 file letter

with the rank number, so a piece on file 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 1–8,

and thus is always exactly one digit long, so there is no need to delimit the fields.

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.

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 file c, rank 6 in turn 1 to file 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. Different Time Travel Models

There are many different models of time travel (Nahin & Nahin 1994), which have

different 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 different from when the traveller left it.

– In others, travelling backwards in time causes a new timeline that splits

and diverges from the first 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 condi-

tions observed before making the change. In other words, every back-

wards time travel must by definition 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


• Stable vs. Unstable

– In some models, the universe itself is in endangered by time travel, be-

cause the creation of paradoxes creates contradictions that cause real-

ity itself to collapse

• Physical Laws vs. Regulatory Laws

– In some models, the limitations on time travel are inherently invio-

lable, 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

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 impos-

sible or inconsistent things are permissible in certain timelines or from

certain perspectives, as long as the ‘definitive’ or ‘final’ time line makes


– Some models seem to require almost no consistency at all, but this is

mostly down to lazy writing. Choosing a Time Travel Model

The original intention was a system with a single timeline, choice, stability, physi-

cal laws, and low level consistency. However, it quickly became clear that a single

timeline was incompatible with choice and low level consistency, without ‘over-

writing’ the timeline by re-playing past moves, which I decided would be bad for

gameplay (section In other words, in order to have a timeline that is con-

sistent at all points (in a game like this this would mean that all moves in every

timeline must be legal), it’s 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). Limitations to Causality

Low level consistency means that causality always follows properly. Models with

low level causality are subject to the ‘Butterfly Effect’ (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, chief among them being the

possibility of being stuck in an endless game replaying the same few turns.

So, consistency must be figured 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 re-

solve such a move will enter an infinite 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 fixed?

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

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 indefi-

nitely. 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

first place? 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 prop-

agates to the present, the backward traveller is destroyed. This stops the existence

of the inactive backwards traveler from having knock-on effects on the timeline.

21 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 didn’t 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 effects (like undoing an opponent’s move) but are not susceptible to

paradoxes. In the case of a paradox, all moves involved in the loop will eventu-

ally 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

effect is to undo every move up to the present, effectively resetting the board to

the latest point not affected by the paradox. This means that although the turn

number is larger, for all intents and purposes the players may as well be replay-

ing a turn from several moves ago, which goes against the principles discussed in


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 direc-

tion 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. How-

ever, due to the differences in the practical gameplay consequences of forward and

backward time travelling moves, this would almost certainly unbalance the game

by giving one side’s pawns an unfair advantage. So the movement of the Pawns

described in section A.3 applies to pawns of either colour.

The final 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 Specification Aim

The aim of the software system is to allow human and machine players to play the

game of Time Chess, as defined in The Rules of Time Chess (appendix A). 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


– 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)

• Detects when the game is finished, 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 in-

formation requests

– Acts on TCECP commands appropriately

– Comprehends Time Chess Move Notation (section 3.2.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 differentiable by shape into different 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

• 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


– Responds appropriately to data received through the TCECP Interface

3.3.2 Engine Design

The general structure of classes outlined in figure 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

Figure 3.3: UML Class Diagram showing an overview of the Time Chess Engine

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 com-

plex scenarios with large numbers of pieces the program performance would not

suffer. The final piece designs were inspired by real world chess sets designed in

the ‘minimalist’ style, with simple geometric shapes.

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 mark-

ing 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 Bish-

ops are not guaranteed to stay on the same colour of square in the way that regular

bishops are.

Chapter 4


4.1 Technology Choices

4.1.1 Why Python?

Python is an interpreted, general-purpose high-level programming language. I de-

cided 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 develop-

ment, 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 be-

cause 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, pro-

viding good support for a number of protocols, including HTTP, XML-RPC, Tel-

net 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

true for other areas of expansion like display, interaction, data storage etc; There

are modules for almost anything I’d 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 han-

dling 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


Simplicity is one of the module’s main selling points. Its tag-line is “3D program-

ming for ordinary mortals”, and it was designed to allow students of physics with

no prior knowledge of programming to write 3D physics simulation and demon-

stration programs (Scherer, Dubois & Sherwood 2000). I am simply attempting to

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

effects etc. are available if required, but set to sensible defaults to allow them to

be ignored.

Cross-platform support is an important feature. It doesn’t make sense to lose

the benefits of using a cross-platform language by binding to a single platform 3D


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 specific and quite detailed descrip-

tion 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. 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). 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 specifically they repre-

sent a specific 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 doesn’t 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 in-

game piece form a ‘lineage’ , with the same pieceId attributes and sequential age

attributes. The Game Object

Within the MVC structure, the Game is the model. It is effectively a data struc-

ture 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 wrap-

per 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 pro-

vides some extra functionality for finding sets of pieces that meet certain criteria. The TimeChessEngine Object

The TimeChessEngine object plays the role of the controller in the MVC archi-

tecture. 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 in-

tended moves from the user. The TimeChessEngine is responsible for calculating

if moves are legal, and working through their ramifications on the state of the Game


4.2.2 How it works Overview

When the program is started, a new TimeChessEngine object is created. It ini-

tialises itself, making a fresh Game object with the board in its starting position.

When attemptMove is called with a Move, the system first 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 propa-

gates 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 didn’t, the turn is incremented, the

contents of this turn’s 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. Implementing Forward Time Travel

The original design was that movements into the future would simply involve re-

moving the piece from its starting location and placing it in its finishing location.

However, this turned out to be insufficient 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 prema-

ture, 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 first verify that their move has been legal, and if it is, they appear, and if it

isn’t, they become Lost in Time.

A future move can become invalid in a few different ways. The first occurs

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 hap-

pened. This is checked for by finding the immediate predecessor to the piece in

the futureQueue (see section for more about finding predecessors). If the

piece has been taken, it will not be possible to find 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 in-

valid is blocking (section A.3.1), which occurs when pieces are positioned in be-

tween the piece and its destination. This is checked for by finding the parent of

the travelling piece, and ensuring that the move it is making is still returned by the

parent’s 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 for more about finding

possible moves for a piece).

Pawns have a special case, because they can move forwards, but can only cap-

ture 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. Implementing Backward Time Travel

Implementing backwards time travelling moves proved to be an especially chal-

lenging 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 difficulty 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

are removed from the game (section A.5.1). The problem then arises of how to find

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 it’s 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 specific 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 flaw 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 first 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 identifier 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 rep-

resent, 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 parent’s age incremented by 1.

The resulting Pieces populate the new turn. Using this system, the proper re-

moval 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

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. 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, reflecting

how the pieces move differently. For a piece type like Knight, getMoves simply

returns moves to all of the positions a knight’s move away which are on the board

and don’t contain any pieces of its own colour.

The movements of the Rook, Bishop and Queen follow the same general pat-

tern, 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 com-

pass 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 vec-

tors, and goes through each one adding legal moves for as long as the path remains

clear. 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

When makeChild is called on a Pawn object to produce the next instance of the

in-game piece, the Pawn first checks to see if it is on the first 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

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. 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 finding 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 ‘back-

wards’, starting from the position of the King and looking for knights in the po-

sitions one knight’s-move away, pawns one pawn’s-move away and so on. This is

faster because there is only one King, and many pieces that could attack it. How-

ever in Time Chess this is not necessarily the case. Because the king can be at-

tacked 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 com-

manded 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. 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 find to way to detect

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 first 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.


The isInCheckmate method must call moveEndsInCheck on every move avail-

able, 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 pro-

gram by a substantial margin. Some measures were taken to improve its perfor-


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 finds a move that doesn’t end it checkmate, it stops.

Secondly, the number of possible moves that need to be checked can be re-

duced by 33% or more by eliminating future moves for everything other than the

King. A move into the future effectively removes a piece from the board for a num-

ber 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.

4.3 Implementing the 3D Interface

4.3.1 Implementation Description 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 to-

gether in one frame of reference, effectively grouping them into a more complex

3D object. For example, a Piece representing a pawn groups together a cone ob-

ject and a sphere object, which together form the shape of a pawn. 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 difference is a lower opacity. 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 ob-

jects, which show as white gridlines separating the positions on the board, and

the Piece objects on the board. 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.

4.3.2 How it Works Overview

When the program is started, a controller object is created. The Controller ob-

ject 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, which runs a TimeChessEngine ob-

ject, supplying it with commands it receives, and returning the results.

The Controller then enters a game loop, in which it handles mouse and key-

board 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. Creating Pieces

Because Piece objects have no behaviour determined by their type, it didn’t

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 Python’s 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 instruc-

tions to make a specific simple geometric object. This is best demonstrated with

examples. In figure 4.1, we can see that the pawn piece type (represented by the

character ‘p’) is made up of two pieces of geometry; The first is a cone positioned

geometries = {
("cone", {"pos":(0,0,0), "axis":(0,0,.5), "radius":.3}),
("sphere", {"pos":(0,0,.5), "radius":.15})


("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 figure 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 vari-

ables prim and args. In the case of a pawn, where ptype='p', the first iter-

ation 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 module’s

__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 dic-

tionary which is to be unpacked into keyword arguments. So for the first iteration

of the loop for a pawn, the line

visual.__dict__[prim](frame=self, color=col,**args)

is effectively translated into

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

This sort of dynamic introspection is one of the things that makes Python such a

powerful language. 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 first 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 effectively 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 configurations of pieces must

be analysed. This can become difficult 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 offset camera posi-

tions, and mapping the right one to the red channel and the left to the blue chan-

nel (figure 4.3), a stereoscopic 3D effect can be produced for users wearing red/blue

filter glasses (figure 4.4) (Konrad & Halle 2007).

Figure 4.2: Complex, densely layered scenes can be difficult 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 off with the ‘s’ key.

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

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

Chapter 5


5.1 Difficulty for Computers

5.1.1 Branching Factor

One of the factors that makes a game difficult for move-space searching AI algo-

rithms 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 (Laramée 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 don’t

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 figure 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, be-

cause 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 fu-

ture moves, while perfectly legal, are effectively suicide because there is no easy

way to ensure that the move remains legal until the piece reappears at its desti-



Branching Factor





00 20 40 60 80 100 120 140

Turn number

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


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 con-

sidered 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 (O’boyle, Tenderholt & Langner

2008). Unit tests were written for major features and edge cases, and used for

regression testing when new feature were implemented.

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 briefly 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 doesn’t

move ‘through’ any intermediate spaces, so there are no spaces which can be filled

by an opposing piece attempting to block it.

However, this thinking was incomplete. While it’s true that it’s impossible to

cause a King to become Lost in Time by blocking it, that’s 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 it’s 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,

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. There’s a lesson here about the benefits

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 wasn’t check-

mated, 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 game-

breaking loophole of the kind I decided not to allow in section

I examined several possible solutions.

1. Don’t allow the King to move to positions directly above pieces of the same


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 interven-

ing turn, making the King’s 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

2. Make the King capture any piece it lands on when reappearing from time

travel, even pieces of the same colour.

¹It’s 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.

This would be very simple to implement, and would fix the problem, but it

has a wider reach than just making the King never be lost in time. It intro-

duces a strange precedent of deliberately taking your own pieces, which is

inelegant and divergent from chess, going against section

3. State that if a King becomes lost in time, the game is lost by the owner of the


This is the solution I chose. It keeps options open, and doesn’t change the

rest of the game, but punishes players for deliberately causing their King to

be Lost in Time.

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 Meaning

1 Strongly Disagree

2 Disagree

3 Neither agree nor Disagree

4 Agree

5 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 different 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 didn’t crash or have many glitches)

12. The game was responsive

The results of the survey are shown in figure 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 effective than reading the docu-

mentation 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 different kind of thinking to regular


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 fine control over exactly which turns are viewed at any time, rather than just

seeing which turns can be affected by a piece’s 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 check-


Running cross correlations between the questions, we find a lot of things that

are fairly obvious; More skilled chess players are less likely to find Time Chess

confusing, more likely to say they understand it, and more likely to find 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.

There’s a very strong negative correlation between finding Time Chess confus-

ing and finding 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 experi-

ences as being confusing, because it is more likely to be remembered as a learning


It’s worth noting that the sample size of this survey is too small to make sta-

tistically significant claims, but as far as conclusions can be drawn from this data,

Time Chess seems to have broadly achieved its aims.

5.4 Requirements

The requirements for the project are specified 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 specified were met, and some extra features (like those mentioned

in section 4.4) we also added. From a requirements perspective, the project was a


Chapter 6


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 Artificial 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, Crâsmaru 1999). This docu-

ment touched briefly 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 game’s state-space and other complexity metrics.

6.1.3 Affective Analysis

Since one of the main stated aims of Time Chess as a game was to have a high cog-

nitive 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 affect information is known to be unreliable (Clark & Watson 1988),

and even if this data is accurate it is very simple and one dimensional.

The field of Affective Computing has a lot to offer here, in terms of the accu-

racy, detail, depth and volume of data that is achievable. One of the main fields of

focus for current AC research is education (Tao & Tan 2005), a field in which as-

sessing 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 affect of test subjects play-

ing educational games (Sykes 2006). Time Chess is not a particularly educational

game, but techniques for measuring affect in a gaming individual would be readily

transferable to the task of measuring cognitive load in the mind of a Time Chess


Information gathered from the interface, such as time taken for each move,

number of pieces selected and examined before move selection, time spent ad-

justing 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 affect of people playing variants of Time Chess, the game can be optimised

for mental challenge.

6.1.4 Personal Reflections

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 refined and fleshed out into a full specification, 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 finally 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 field of AI research.


Allis, L. (1994), Searching for solutions in games and artificial intelligence, Ponsen &


Cai, X., Langtangen, H. & Moe, H. (2005), ‘On the performance of the Python pro-

gramming language for serial and parallel scientific computations’, Scientific

Programming 13(1), 31–56.

Clark, L. & Watson, D. (1988), ‘Mood and the mundane: Relations between daily

life events and self-reported mood.’, Journal of Personality and Social Psychol-

ogy 54(2), 296.

Coles, L. S. (2002), ‘Computer chess: The drosophila of ai’.


Crâsmaru, M. (1999), ‘On the complexity of Tsume-Go’, Lecture notes in computer

science pp. 222–231.

GNU Project (n.d.), ‘GNU Chess SVN Repository’.


Hilborn, R. (2004), ‘Sea gulls, butterflies, and grasshoppers: A brief history of the

butterfly effect in nonlinear dynamics’, American Journal of Physics 72, 425.

Ikehara, C. & Crosby, M. (2005), ‘Assessing cognitive load with physiological sen-


Iqbal, A. (n.d.), ‘What Computer Chess Still Has to Teach Us’.

Konrad, J. & Halle, M. (2007), ‘3-D displays and signal processing’, Signal Processing

Magazine, IEEE 24(6), 97–111.

Laramée, F. D. (2000), ‘Chess Programming’.

Nahin, P. & Nahin, P. (1994), Time machines, AIP Press.

O’boyle, N., Tenderholt, A. & Langner, K. (2008), ‘cclib: A library for package-

independent computational chemistry algorithms’, Journal of computational

chemistry 29(5), 839–845.

Paas, F., Tuovinen, J., Tabbers, H. & Van Gerven, P. (2003), ‘Cognitive load mea-

surement as a means to advance cognitive load theory’, Educational psychol-

ogist 38(1), 63–71.

Pritchard, D. & Beasley, J. (2007), The Classified Encyclopedia of Chess Variants,


Scherer, D., Dubois, P. & Sherwood, B. (2000), ‘VPython: 3D interactive scientific

graphics for students’, Computing in Science & Engineering 2(5), 56–62.

Shaffstall, J. (n.d.), ‘Temporal Chess’.


Shannon, C. (1950), ‘XXII. Programming a computer for playing chess’, Philosoph-

ical Magazine (Series 7) 41(314), 256–275.

Stanford University (2008), ‘Stanford Encyclopedia of Philosophy on Time’.


Stone, R. (n.d.), ‘A Brief Study and Review of Chess and Go Artificial Intelligence’.

Storer, J. (1983), ‘On the complexity of chess’, Journal of Computer and System Sci-

ences 27(1), 77–100.

Syed, O. & Syed, A. (2003), ‘Arimaa-a new game designed to be difficult for com-

puters’, International Computer Games Association Journal 26, 138–139.

Sykes, J. (2006), ‘Affective gaming: advancing the argument for game-based learn-

ing’, Affective and emotional aspects of human-computer interaction pp. 3–7.

Tao, J. & Tan, T. (2005), ‘Affective computing: A review’, Affective Computing and

Intelligent Interaction pp. 981–995.

Van Gelder, A. (1987), ‘Efficient loop detection in Prolog using the tortoise-and-

hare technique’, The Journal of Logic Programming 4(1), 23–31.

Appendix A

The Rules of Time Chess

For the purposes of this document, it is assumed that the reader is generally fa-

miliar 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, sym-

bols, appearances, and much of their behaviour. If an aspect of a piece is not spec-

ified in this document, it may be assumed that it shares that aspect with its equiv-

alent 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 imprac-

tical. 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.

A.2 Objective

The objective of Time Chess is broadly the same as that of Chess - To place the

opponent’s 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. Pos-

itive 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 num-

ber of places in each of those directions, effectively 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.

. ×
. ×
. ×
.× .× .× .×
. ×
. ×
. ×
. .B ×
. ×
. ×
. ×
.× .× .× .×
. .× . ..× .× . . .×
.t − 2 .t − 1 .t .t + 1 .t + 2

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

higher dimension of time to provide the Time Knight movement shown in

Figure A.2

.× .× .× .×
.× .× .× .×
. ×
. ×
. ×
. .N ×
. ×
. ×
. ×
.× .× .× .×
. . ×
. . ×
. ×
. . ×
. .
.t − 2 .t − 1 .t .t + 1 .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 Queen’s possible

move set effectively 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.

. ×
. ×
. ×
. ×
.× .× .× .× .×
. ×
. ×
. ×
. ×. ×. ×
. ×. .Q ×
. ×. ×
. ×. ×. ×
. ×
. ×
.× .× .× .× .×
. .× . ..× .× .× . . .×
.t − 2 .t − 1 .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 orthog-

onal directions. The Time King’s movement is the same with possibility of

forwards and backwards in time as directions.

. ×
. ×
. ×
. ×
.× .× ×
. .× .K .× .× .× ×
. ×
. ×
. ×
. ×
. . .
.t − 1 .t .t + 1

Figure A.4: Movement of a Time King

• Time Pawn movement is show in figure A.5. The Time Pawn can move to

positions marked with
1 if they are unoccupied, and to positions marked

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 .× .

. . .
.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 oc-

cupied 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.


. . .
.t − 2 .t − 1 .t

Figure A.6: Blocking: The Bishop could normally move to point p, but can’t 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

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 first arrives first. This is generally only significant 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.

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.

Appendix B

Time Chess Engine

Communication Protocol

The Time Chess Engine Communication Protocol (TCECP) is a simple text proto-

col 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.

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


ping <NUMBER> Check the engine is connected and responding.

<POSITION> (e.g. a1t0) Request a list of moves possible for the piece at

<POSITION> (See section 3.2.3).

<MOVE> (e.g. a2t0a4t0) Attempt to make the move <MOVE> (See section 3.2.3).

getState t 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>

B.2 Messages from the Engine to the GUI

pong <NUMBER> (In reply to ping <NUMBER>) Confirm that the en-

gine is connected and responding by ponging the

same number you were pinged

moves (<POSITION>): (In reply to <POSITION>) [<LIST>] is a list of

[<LIST>] moves possible for the piece at <POSITION>, as

a valid JSON array of strings. (e.g. moves (a4t5):

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):

<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
each representing a piece. (e.g.

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. (e.g.
[["a1t5", "w", "r"]])

Appendix C

Time Chess 3D Interface: User


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 side’s turn to move. Clicking on

a Black piece when it is White’s 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 semitranspar-

ent red squares. Click one of the red squares to move the selected piece to that


C.4 Keyboard Controls

Key Effect

F Hide all layers representing the future

P Hide all layers representing the past

N Hide all layers representing either the future or the past, showing only now.

S Toggle red/blue stereoscopic 3D, viewable with red/blue filter glasses