Computer Programming for Noughts-and-Crosses:
New Frontiers
W.M. Beynon, M.S. Joy
Department of Computer Science, University of Warwick, CV4 7AL
ABSTRACT
We relate the development of computer programs that play
variants of noughts-and-crosses to an analysis of the perception
and action involved in human play. We outline the construction
of a computer model, expressed as a script of definitions, within
which the perceptions and actions of agents such as the players
and observers can be recorded. We briefly compare and
contrast our concept of agent-orientation with alternative
approaches to agent-oriented programming.
1. Introduction
This paper illustrates unusual principles of software development based on a
particular kind of real-world modelling. The abstract ideas behind our
method are discussed at length elsewhere [2], and the emphasis here is upon
investigating a particular application in detail. To this end, we develop a
model from which we can derive a class of computer programs for playing
various games with a family resemblance to noughts-and-crosses, or OXO-
games. For clarity, we shall refer to the computer model from which we
develop our programs as the OXO-model.
----------------------------------------------------------------------------
The Concept of the OXO-game
For convenience, we refer to the family of games we study as OXO-games.
Examples of commercial games in this family are:
o noughts-and-crosses
o 3-d dimensional noughts-and-crosses, as played on a 4?4?4 grid
o Go-moku
o Connect-5
o Othello
Each of these games is played by two players X and O, who in turn enter an
X or O symbol respectively into a grid structure with a view to achieving a
line of tokens of a certain length. In some case, there are special
constraints on the positions at which symbols can be entered. In Connect-5,
the X and O symbols are represented by black and white discs whose position
in a vertical grid is constrained by gravity so that discs support each
other. In Othello, the symbols are represented by discs, each of which has
one black and one white face, that can be turned over in the course of
play. In the context of this paper, we shall consider many other variants
of these traditional OXO-like games. For instance, we may introduce other
notions of grid and line, or modify the protocols and environment for play,
as in playing blindfold OXO, simultaneous OXO, postal OXO, OXO with a
time-limit on each play, OXO with cheating, etc.
----------------------------------------------------------------------------
1.1. Background to the approach
From a psychological perspective, the most interesting characteristic of our
approach is that it connects software development with the analysis of
processes of perception and action. In analysing the requirement, we uncover
hidden assumptions about the way in which real-world activity is
synchronised, or is deemed to be synchronised, and construct a partial model
that captures these assumptions. The primary activity in the modelling
process is the faithful representation of real-world states in terms of
relationships between observations that can be determined by experiment. It
is only when we have finally modelled the context for agent action that we
introduce agents into the OXO-model. Even at this stage, as in a real
experimental situation, there is scope to adapt system behaviour through
introducing additional factors, such as introducing a timer, or another agent
with the power to intervene in play.
1.1. Software Development as Engineering Design
In our development method, we regard computer programming as a special
case of constructing a physical agent with a particular capacity for autonomous
response. Viewed in this light, developing a program to play an OXO-game is
an exercise in engineering design. What we must do is to identify a physical
system (an OXO-game automaton) that can be observed in such a way that it
is seen to encode the state of an OXO-game, that can be set up to alternate
between two different kinds of state representing valid positions of an OXO-
game in which either the automaton itself or the user (as OXO-game player)
is responsible for initiating a state-transition that represents a valid play.
In designing a suitable physical system, we construct the OXO-model -- an
agent-oriented computer-based model that can represent both the OXO-game
automaton and the human player. The purpose of the OXO-model is to
specify the interaction between these two agents that are responsible for
initiating significant state-changes in the course of play. The characteristic
feature in our analysis is that we focus upon how each agent identifies
changes in the state of its environment and how it can itself effect such
changes. The results of this analysis are expressed in terms of observations that
define the interface between agents in much the same way that we would
account for the behaviour of a complex engineering system in terms of the
observed values of significant values that could in principle be identified
through scientific observation. By modelling the interaction between agents
in the system in these terms, we arrive, through a process of incremental
development and experiment, at a prescription for an OXO-game automaton
that can itself be interpreted as an executable OXO-game program (cf [8],
where we illustrate the application of similar principles in the context of
engineering design). The OXO-model includes information that would be
just as relevant to the design of an OXO-playing robot as a OXO-playing
program, but, in the context of this paper, the OXO-game automatons with
which we are primarily concerned are computers executing appropriate
programs.
2. Principles of the Analysis
Our approach to the modelling task described above can best be understood
by analysing perception and action in OXO-games between human players.
In the ordinary way, we take the observation and interpretation involved in
playing OXO-games for granted. This is to neglect implicit assumptions
underlying the interaction between players, concerned with what each player
can see, how each player can act, what each player knows and the nature of
their environment. To disclose the hidden assumptions that make it possible
to play an OXO-game, we shall consider the implications of perturbing the
context for a traditional OXO game -- in much the same spirit that a scientist
might perturb parameters in an experimental context.
In a traditional game of OXO, the two players interact via a diagram that
depicts the state of the OXO game, as in Figure 1:
X | O | X
---------------------------------------
| O | O
---------------------------------------
| X |
The players are the primary state-changing agents of interest in this
application. Following the principles set out above, we must consider how, in
the course of playing OXO, they identify changes in the state of their
environment and how they can effect such changes. There are two aspects to
this process: a relatively low-level aspect, concerned with the physical
capabilities of the players, and a higher-level aspect, concerned with
interpreting the situation in the OXO game. In appreciating the nature of this
activity, it is helpful to think in terms of skills that a young child
progressively acquires in becoming an OXO-game player, and of the
difficulties that would be encountered by adult players disadvantaged by the
loss of faculties through accident or illness.
The low-level activity of the two players involves identifying the locations of
Xs and Os in the diagram, over which they must be in agreement. They have
also to be capable of entering an X or an O in a space at an appropriate time.
The high-level activity depends upon abstract knowledge of rules of the
game. For instance, it concerns: Who is to play next? Which player is X and
which is O? What is a legitimate play? Is the game over? Has X or O won?
Issues that require yet more sophisticated interpretation of the position are
concerned with deciding the best play.
2.1. Synchronisation and action
Analysis of the relationships between observations made by OXO-games
players exposes subtle assumptions about the medium through which the
game is played and the way in which action and interpretation are
synchronised. The approach we adopt to detecting some of these
assumptions is illustrated in this section. The result of this analysis is to
identify features of the OXO-game context that have to be captured in our
computer model.
The process of writing an X or an O takes a finite time, during which the
interpretation of the OXO diagram is suspended -- there is no meaning
attached to a diagram in which part of an X has been entered into a square. A
variant of OXO might stipulate that player X must alternate between writing
an X as \ followed by / and as / followed by \, and that player O must
alternate between writing an O clockwise and anticlockwise -- a violation of
this rule to lead to an X being deemed an O and vice versa. This particular
OXO-game relies upon special characteristics of the playing medium, and the
modified rules could not be applied if the game were played by placing O
and X-shaped tokens on a 3 by 3 board.
Even when each play is regarded as an indivisible action, synchronisation of
play can be problematic. In a game of postal OXO with an inadequate
protocol for correspondence, it is conceivable that a player's moves might be
received in the wrong order.
Synchronisation is implicit in determining how a player's perception of an
OXO position relates to the actual position. We are accustomed to play OXO
whilst looking at the diagram, and take it for granted that there is no
discrepancy between the pattern of Xs and Os that is objectively seen on the
diagram and what we as players perceive it to be. Some deep issues lurk
behind this seemingly innocent presumption. What is the pattern objectively?
A blind person, placing Braille symbols on an OXO board, might not trust the
perception of a sighted person unfamiliar with the Braille alphabet;
conventional OXO players might not trust the perception of a blind referee.
The significant concern here is that there are typically several scientific
observations that relate to the same object, and that these can be interrelated
in very subtle ways. As a simple illustration, consider the variant of OXO in
which only O's are visible to player X, and vice versa, and a player who
selects an illegal play loses.
The characteristics of an OXO game are strongly affected by nature of the
communication that informs a player about the actual position. Contrast
looking at a diagram, reading a board with tokens bearing Braille symbols,
and interpreting the sensation of hot (X) and cold (O) tokens placed on the
palm of your hand. Inspection of a diagram provides a view that is
"continuously" (or at any rate very frequently) refreshed, whereas
interpreting a Braille board requires a tactile survey of each square. The
distinction would be relevant in a variant of an OXO-game in which a limited
form of cheating was deemed to be legal. The player with the move might be
allowed to interchange a pair of X and O tokens on an OXO-game board
prior to making a move, subject to the constraint that the game would be lost
if such cheating was correctly alleged by the opponent on the following
move. It would be exceedingly difficult for a blind player to play such a
variant of Go-moku, as the number of tokens can be exceptionally large.
Yet another kind of synchronisation is concerned with linking interpretation
of the OXO-game to the current state of the board. When a particular play
leads to the introduction of a line of 3 identical tokens, a physical event
(placing a token on the board) is synchronised with a conceptual event (the
winning of the game). In this context, synchronisation is linked with
knowledge of the rules of the game, and is subject to similar concern about
agreement over interpretation between players and an objective observer
(such as a referee) as was discussed above.
Interpretation of the board also operates at a simpler level, in the
apprehension of the geometry of the board. Playing an OXO-game depends
upon being able to perceive a line in the grid, and determine its length.
The purpose of our analysis of OXO-games and their derivatives is to express
the common knowledge of physical properties of real-world systems that is
required to appreciate what is happening in the process of playing the game.
This knowledge is expressed in terms of agents that are responsible for
changes of state (such as the players), the observations of the system that
account for the perceptions of agents (such as the position of the tokens, the
geometry of the board, the rules of the game), and the way in which changes
in these observations are synchronised in the process of playing the game.
The observations to which we refer need not of course be observable in the
colloquial sense. Observations are values that in general would have to be
determined by experiment, and their diverse nature reflects the range and
subtlety of phenomena to which agents in a real-world system can respond.
For instance, as the discussion of how players apprehend the board
illustrates, it may be appropriate to distinguish between visual inspection of
the board and other modes of identifying the location of tokens.
In analysing an OXO-game, synchronisation is relative to what agents are
acting, and how we decide to constrain, observe and interpret their actions.
In postal OXO, we do not normally consider the possibility of subversion
through third-party intervention. In the 2-person OXO games we have
considered, we are not concerned with how long a player takes to select a
square. The playing protocol prevents players from modifying the diagram
simultaneously, and from playing out of turn. It is on this basis that we can
regard the update of the board as synchronised with apprehension and
interpretation of the resulting position by a player; no action can intervene
between one play and the next. This assumption would not apply to
accelerating OXO, in which each play had to be made more rapidly than the
previous one.
3. Synthesising the model
Our method of developing an agent-oriented model for OXO-games is based
upon representing the significant relationships between observations
identified in the analysis above. The OXO-model (as outlined in Listing 1
below) contains such generic information about OXO-game playing that it
can be applied in a variety of ways. For instance, it can be used to study the
implications of varying the rules of OXO and the perceptions and capabilities
of the players in many different ways, and trivially adapted so that the role
of one or both players is automated. In particular, our OXO-model has been
implemented in the special-purpose programming language EDEN that we
have developed, and in this way serves as the source for a family of EDEN
programs to play OXO-games. Full details of the method are omitted from
this abstract, but the essential principles will be briefly outlined.
Our model is developed incrementally through a sequence of simple
modelling steps, each of which leads to the construction of a script of
definitions (or definitive script) that is to be interpreted with reference to a
protocol for redefinition. Each script captures assumptions about
synchronisation of observations such as we have identified above (cf [8]).
Each script can also be regarded as representing a particular aspect of the
design of an OXO-game playing program, associated with a highly
specialised view of the OXO-game playing process. The correspondence
between analysing perceptions and actions in OXO-game playing and
synthesising an OXO-game playing program is very precise. As an
illustration of this, in our approach, the natural way to develop an OXO-
game playing program is first to build the display interface (what does the
board look like?), then to express the relevant geometric structure of the
board (what are the lines in the grid?), then to apply the rules of OXO to
interpret static positions (is this position won or drawn?), then to consider
naive interpretation of positions in play (is it my turn? what is a valid play?),
then to consider matters of strategy (what is the best play in this position?).
This hierarchical organisation of the design reflects the hierarchy of
perceptions and actions underlying OXO-playing, ranging from low-level
capabilities to see the board and apprehend geometric patterns to high-level
abilities to interpret the position and devise a playing strategy.
The correspondence between aspects of perception of OXO-game playing
and different perspectives on the design of an OXO-game automaton is
illustrated by considering one of the definitive scripts that make up the OXO-
model -- the DISPLAY script. The observations referred to in this script are
concerned with how the appearance of the diagram (as a pattern of light rays
on the eye) is related to the location of Xs and Os on the OXO-diagram. The
display script comprises definitions that express the way in which the
appearance of the board is indivisibly linked to the disposition of Xs and Os
in a conventional OXO-game. In this context, definitions are used to express
conceptual indivisibility that is justified by the assumption that the speed of
light is orders of magnitude faster than the speed of OXO play. On the other
hand, the exact nature of these definitions reflects the faithfulness of a
player's image of the position -- we would choose a different set of definitions
to model OXO as played with a board and symbols so well-used that Xs and
Os could no longer be distinguished, and the players had to remember where
they had played.
Viewed from the perspective of OXO-playing program design, the DISPLAY
script connects an abstract internal model of an OXO position to its
visualisation (cf [1]), and can be written in different notations to reflect
different visualisation requirements. During the development process, we
can use the DISPLAY script in conjunction with the internal representation
alone to investigate the appearance of the board on the display. Notice that
the issues we are concerned with in this aspect of the design correspond
closely to the low-level issues of perception in OXO-game playing, as when I
ask my opponent "can you see the diagram?". In this context, it doesn't matter
whether the board we depict represents a valid position in an OXO-game: a
designer interested in the visual effect is free to experiment by realising the
board in many different configurations, whether legal or not.
The other scripts constructing in developing the OXO-model are
o STATUS
relating the board state to the game status;
o GEOMETRY
recording the incidence relations between the squares and lines;
o SQVALS
relating a square location to the advisability of playing there;
o PLAY
selecting the best square in which to play;
o GAMESTATE
relating the state of a board in play to player privileges.
Each such script represents a particular perspective on OXO-game playing, so
that for instance someone unfamiliar with the rules of OXO might
nonetheless be able to identify the incidence relations in the GEOMETRY script,
and a player involved in an OXO-game would take turns according to
observations recorded in the GAMESTATE script.
The complete OXO-model, as specified in outline in Listing 1 below, is
synthesised from the family of definitive scripts developed from our analysis
of perception and action in OXO-games. This involves integrating scripts that
represent many such views into a single script. The OXO-model can be
turned into a computer program by supplying the automonous actions and
view management operations that are required to transform the resulting
script into an OXO-game playing program. The integrated family of scripts
may be regarded as supplying a model of the environment for interaction
between the players; a model that is then complemented by the introduction
of actions associated with (one of) the player agents. The most significant
features of the design method are:
o the development of each script is a relatively simple programming
process, resembling the specification of a spreadsheet through
introducing defining formulae for cells and experimental redefinition
of values;
o it is easy to reconstruct the environments encountered during the
design process, and adapt scripts incrementally and retrospectively for
debugging, in re-use, or to meet a new requirement;
o the final step of animating is trivial in as much as it involves
delegating (to the computer) privileges to change the system state that
the programmer can already exercise.
At present, the methods we use to represent the evolving script -- based on
the EDEN programming language -- are relatively informal (cf [8]). This is
often convenient, in as much as the program developer enjoys very strong
privileges to modify scripts at every stage of the design process, but the
method has limitations. An important technical issue concerns the proper
representation of the synthesis of views that make up a final specification
-- a
task for which the Abstract Definitive Machine is our chosen model [3].
4. Agent-orientation vs object-orientation
The relationship between our approach and other methods of software
development is subtle. There are several ways in which our approach can be
compared with varieties of object-oriented development (cf [5]) -- these are
the subject of current collaborative work with the Software Development
Laboratory at IBM Warwick. Some key points of comparison are considered
here.
We adopt a philosophy of programming as modelling that was the primary
motivation for object-oriented methods [4], but our emphasis is upon
modelling observations of an entire system of interacting agents rather than
constructing models of objects in isolation and integrating these within a
message passing framework. An important advantage of this emphasis is that
we can specify synchronised changes in observations that propagate across
object boundaries. Even more significant is the fact that in the process of
developing our models we are concerned with formulating relationships
between observations that are provisional, in the same sense that the
expectations generated through scientific experiment can be confounded.
This means in particular that our model can be viewed as a formal
specification of an object or program only after an appropriate commitment
to faith in the validity and reliability of the relevant observations.
In practice, the problems of distributing the work of building large software
systems have influenced the development of object-oriented techniques quite
as much as concern as the programming as modelling perspective. In its modern
usage, object-orientation is centrally linked with synthesising software
systems from modules that can be independently developed. The agent-
oriented method we use exhibits some of the virtues claimed for modular
development in an object-oriented idiom. For instance, the explicit
specification of dependencies makes it possible to carry out independent
development of scripts that make up the OXO-model. It is also easy to re-use
fragments of script, or to revise or replace components of the model to suit a
new requirement. To illustrate this, we set up an environment in which the
script that specifies the GEOMETRY component of the OXO-model can
represent 3-d OXO and OXO over a classical finite projective plane. We also
replaced the representation of the board as a character string in Listing 1 by a
more sophisticated graphical display taken from another source -- a
substitution that involved no change to the other constituents of the model.
In the construction of large-scale software, the division into independent
modules is recognised to be one of the most difficult tasks [6]. From an
object-oriented perspective, minimising the dependency between modules is
essential, because of the problems of maintaining the consistency of
distributed data. Careful examination of Listing 1 reveals complex data
dependencies between the constituent scripts even in such a relatively simple
model. In simulation from the OXO-model, synchronised updating of
variables via definitions plays an essential role in managing this complexity.
On the other hand, the rich data dependencies established by definitive
scripts can make it hard to grasp the model conceptually. More work is
needed to determine whether there are better ways to organise a definitive
script such as Listing 1 so as to localise dependencies. Such concern is
directly relevant to the issue of effective object-oriented modularisation, and
also echoes concerns that have been widely expressed about tracing
dependencies in large spreadsheets.
Our concept of agent-orientation has been developed quite independently of
the large body of AI research referenced by Shoham in [9], and reflects an
fundamentally different perspective. (In particular, we do not consider it
appropriate to regard our concept of agent-oriented programming as a
specialization of object-oriented programming [9], despite the superficial
similarities.) In our framework, the concept of agent action is complementary
to the notion of indivisible change of system state as expressed in definitive
scripts. The development of agent-oriented modelling over definitive scripts
originated with the design of the agent-oriented specification language LSD
in 1986. As our discussion of the OXO-model illustrates, our work relates
interaction between agents in the first instance to basic perceptions and only
subsequently to more sophisticated issues of knowledge and belief. Recent
unpublished work of Lam [7] strongly suggests that our approach provides
an appropriate foundation for more sophisticated agent models of the kind
referenced by Shoham, and leads us to propose the Abstract Definitive
Machine as an appropriate computational model for an Agent-Oriented
Programming paradigm [10].
References
1. Beynon, W.M., Yung, Y.P. Definitive Interfaces as a Visualisation Mechanism, Proc. GI'90,
Canadian Info. Proc. Soc., 1990, 285-292
2. Beynon, W.M., Russ, S.B. The Interpretation of States: a New Foundation for Computation,
Proc. PPIG'4, Loughborough Univ., 1992
3. Beynon, W.M., Slade, M.D., Yung, Y.W. Parallel Computation in Definitive Models, Proc.
CONPAR'88, BCS Workshop Series, CUP 1989, 359-367
4. Birtwistle, G.M. et al, Simula Begin Lund, Studentlitteratur, 1979
5. Booch, G. Object-Oriented Development IEEE Trans. S.E. 12(2), 1986, 285-292
6. Brooks, F.P., Jr. No Silver Bullet: Essence and Accidents of Software Engineering IEEE
Computer 20:4, 1987, 10-19
7. Lam, N.S. Agent-oriented Modelling and Societies of Agents, unpublished MSc project
report, University of Warwick, Sept. 1993
8. Ness, P.E., Beynon, W.M., Yung, Y.P. Agent-oriented Modelling for a Sailboat Simulation,
(submitted to ESDA'94, London July 1994)
9. Shoham, Y., Agent-Oriented Programming Report #STAN CS 90 1335, Dept of
Computer Science, Stanford University, October 1990
10. Torrance, M., Viola, P., The AGENT0 Manual Report #STAN CS 91 1389, Dept of
Computer Science, Stanford University, April 1991
Listing 1: An outline of the OXO-model
The variables and definitions that make up the OXO-model are as follows:
DISPLAY
o is -1 // values to indicate what token is on the square
u is 0 // u means that a square is unoccupied
x is 1
board is concatxo(allsquares)
// concatxo converts -1,0,1 into chars 'O','.','X' and concatenates
// with appropriately specified newlines to create a board display
// display models the visual image associated with a physical disposition of tokens
GEOMETRY
allsquares is [s1,s2,s3,s4,s5,s6,s7,s8,s9] // list of all squares on the board
nofsquares is allsquares# // # denotes the length of a list
lin1 is [s1,s2,s3] // explicit enumeration of triples
lin2 is [s4,s5,s6] // that define the lines
.....
alllines is [lin1, lin2, lin3, lin4, lin5, lin6, lin7, lin8]
noflines is alllines#
linesthru1 is [lin1, lin4, lin7] // explicit enumeration of lines through a square
linesthru2 is [lin1, lin5]
......
linesthru is [linesthru1, linesthru2, ..., linesthru9]
//geometry describes the relationships between squares that determine oxo lines
STATUS
nofx is nofpieces(allsquares, x)
nofo is nofpieces(allsquares, o)
full is (nofo + nofx == nofsquares)
xwon is checkxwon(alllines)
owon is checkowon(alllines)
draw is !xwon && !owon && full
status is (xwon ? "X wins " : "") || (owon ? "O wins " : "") || (draw ? "Draw " : "") || ""
// status explains how a particular position is interpreted by an oxo watcher
SQVALS
square is .... // possible values are s1 / s2 / s3 / s4 /s5 / s6 / s7 /s8 / s9
availsquare is allsquares[square]==u
cursqval is sqval(linesthru[square])
// sqval() associates a value with a particular square in a particular oxo position
// sqvals evaluates squares (without lookahead) from the perspective of an oxo player
PLAY
maxindex is findmaxindex(allsquares)
// findmaxindex determines the square with the highest evaluation in a given position
// play is derived from sqvals by "contemplating each square in turn"
GAMESTATE
startplayer is .... // possible values are o / x
x_to_play is (!end_of_game) && (startplayer==x && nofo==nofx) || nofo > nofx
o_to_play is (!end_of_game) && (startplayer==o && nofo==nofx) || nofx > nofo
end_of_game is xwon || owon || draw
// gamestate determines who (if anyone) is to move in the current position