1. Game Description General Game Playing Lecture 2
Michael Genesereth Spring 2012

2. Games as State Machinesaa ab s2 s5 s8 aa bb ab aa aa ab bb ab ab ba s1 s3 s6 s9
s11 aa ab ba ba bb bb aa aa s4 s7
s10

3. Problem
Since all of the games that we are considering are finite, it is possible in principle to communicate game information in the form of transition graphs.
Problem:Size of description. Even though everything is finite, the graphs can be large.
Solution: Conceptualize as a propositional net and linearize as a logic program.
Chess, for example, has approximately 1030 states.

4. Tic-Tac-Toe init(cell(1,1,b)) init(cell(1,2,b)) init(cell(1,3,b))
init(control(x))
legal(P,mark(X,Y)) :-
true(cell(X,Y,b)) &
true(control(P))
legal(x,noop) :-
true(control(o))
legal(o,noop) :-
true(control(x))
next(cell(M,N,P)) :-
does(P,mark(M,N))
next(cell(M,N,Z)) :-
does(P,mark(M,N)) &
true(cell(M,N,Z)) & Z#b
next(cell(M,N,b)) :-
does(P,mark(J,K)) &
true(cell(M,N,b)) &
(M#J | N#K)
next(control(x)) :-
true(control(o))
next(control(o)) :-
true(control(x))
terminal :- line(P)
terminal :- ~open
goal(x,100) :- line(x)
goal(x,50) :- draw
goal(x,0) :- line(o)
goal(o,100) :- line(o)
goal(o,50) :- draw
goal(o,0) :- line(x)
row(M,P) :-
true(cell(M,1,P)) &
true(cell(M,2,P)) &
true(cell(M,3,P))
column(N,P) :-
true(cell(1,N,P)) &
true(cell(2,N,P)) &
true(cell(3,N,P))
diagonal(P) :-
true(cell(1,1,P)) &
true(cell(2,2,P)) &
true(cell(3,3,P))
true(cell(1,3,P)) &
true(cell(3,1,P))
line(P) :- row(M,P)
line(P) :- column(N,P)
line(P) :- diagonal(P)
open :- true(cell(M,N,b))
draw :- ~line(x) &
~line(o)
Given this structure for states, it is possible to encode games in a form that is more compact than direct representation by writing rules as axioms in computable a subset of first-order logic called GDL. Here we have the entire axiomatization for Tic-Tac-Toe. The rules for Chess take about 5 pages in this font. Smaller than the game tree of nodes.

5. Game Description Language

6. Vocabulary Components: Object Variables: X, Y, Z
Object Constants: a, b, c
Function Constants: f, g, h
Relation Constants: p, q, r
Logical Operators: ==, !=, ~, &, :-
Punctuation: (, ,, )
The arity of a function or relation is the number of arguments that can be supplied to the function or relation. NB: Variadic functions and relations are possible, but in our work here we fix the arity for each function and relation in advance.

7. Syntax Terms: Variables: X, Y, Z Object Constants: a, b, c
Functional Terms: f(a), g(X,b), h(X,f(Y),c)
Sentences:
Atoms: p(a,b), p(a,f(a)),
Equations and Inequalities: X==f(a), Y!=f(a)
Negations: ~p(a,b)
Rules: r(X,Y) :- p(X,Y,c) & ~q(Y)

8. ra(X,Y) :- a(X,Y) & ~p(X,Y)
Logic Programs
A logic program is a finite set of atoms and rules.
Example:
p(X,Y) :- f(X,Y)
p(X,Y) :- m(X,Y)
g(X,Z) :- p(X,Y) & p(Y,Z)
a(X,Z) :- p(X,Z)
a(X,Z) :- p(X,Y) & a(Y,Z)
ra(X,Y) :- a(X,Y) & ~p(X,Y)

9. Tme Out for an Example

10. Blocks World
The Blocks World is a popular application area for illustrating ideas in the field of Artificial Intelligence. A typical Blocks World scene is shown here. Most people looking at this figure interpret it as a configuration of five toy blocks. Some people conceptualize the table on which the blocks are resting as an object as well; but, for simplicity, we ignore it here.

11. Signature Object Constants: a, b, c, d, e Unary Relation Constants:
block - is a block
clear - blocks with no blocks on top
table - blocks on the table
Binary Relation Constants:
on - pairs of blocks in which first is on the second
almost - top and bottom of 3 block stack
above - pairs in which first block is above the second
Ternary Relation Constant:
stack - triples of blocks arranged in a stack
In order to describe this scene, we adopt a signature with five object constants - a, b, c, d, e - with one object constant for each of the five blocks in the scene. The intent here is for each of these object constants to represent the block marked with the corresponding capital letter in the scene.
In a spatial conceptualization of the Blocks World, there are numerous meaningful relations. For example, it makes sense to think about the the relation that holds between two blocks if and only if one is resting on the other. In what follows, we use the relation constant on to refer to this relation. We might also think about the relation that holds between two blocks if and only if one is anywhere above the other, i.e. the first is resting on the second or is resting on a block that is resting on the second, and so forth. In what follows, we use the relation constant above to talk about this relation. There is the relation that holds of three blocks that are stacked one on top of the other. We use the relation constant stack as a name for this relation. We use the unary relation constant clear to denote the relation that holds of a block if and only if there is no block on top of it. We use the unary relation constant table to denote the relation that holds of a block if and only if that block is resting on the table.

12. Data block(a) clear(a) table(c) block(b) clear(d) table(e) block(c)
block(d)
block(e)
on(a,b) almost(a,c) above(a,b)
on(b,c) above(a,c)
on(d,e) above(b,c)
above(d,e)
stack(a,b,c)
Given this signature, we can describe our Block World configuration by writing ground literals that state which relations hold of which objects or groups of objects. Let's start with on. The sentences here tell us directly for each ground relational sentence whether it is true or false.
We can do the same for the other relations. However, there is an easier way. Each of the remaining relations can be defined in terms of on. These definitions together with our facts about the on relation logically entail every other ground relational sentence or its negation. Hence, given these definitions, we do not need to write out any additional data.

13. stack(X,Y,Z) :- on(X,Y) & on(Y,Z)
Definition:
stack(X,Y,Z) :- on(X,Y) & on(Y,Z)
Input: Output:
on(a,b) stack(a,b,c)
on(b,c)
on(d,e)
A block satisfies the clear relation if and only if there is nothing on it.
A block satisfies the table relation if and only if it is not on some block.

14. almost(X,Z) :- on(X,Y) & on(Y,Z)
Definition:
almost(X,Z) :- on(X,Y) & on(Y,Z)
Input: Output:
on(a,b) almost(a,c)
on(b,c)
on(d,e)
A block satisfies the clear relation if and only if there is nothing on it.
A block satisfies the table relation if and only if it is not on some block.

15. above(X,Z) :- on(X,Y) & above(Y,Z)
Definition:
above(X,Z) :- on(X,Z)
above(X,Z) :- on(X,Y) & above(Y,Z)
Input: Output:
on(a,b) above(a,b)
on(b,c) above(b,c)
on(d,e) above(a,c)
above(d,e)
A block satisfies the clear relation if and only if there is nothing on it.
A block satisfies the table relation if and only if it is not on some block.

16. Failed Attempt to Define Clear
Definition:
clear(X) :- block(X) & block(Y) & ~on(X,Y)
Input: Output:
on(a,b) clear(a)
on(b,c) clear(b)
on(d,e) clear(c)
clear(d)
clear(e)
A block satisfies the clear relation if and only if there is nothing on it.
A block satisfies the table relation if and only if it is not on some block.

17. Clear Defined Correctly
Definition:
clear(X) :- block(X) & ~cluttered(X)
cluttered(Y) :- on(X,Y)
Input: Intermediate: Output:
on(a,b) cluttered( b) clear(a)
on(b,c) cluttered( c) clear(d)
on(d,e) cluttered( e)
A block satisfies the clear relation if and only if there is nothing on it.
A block satisfies the table relation if and only if it is not on some block.

18. Table Definition: Input: Intermediate: Output:
table(X) :- block(X) & ~supported(X)
supported(X) :- on(X,Y)
Input: Intermediate: Output:
on(a,b) supported( a) table(c)
on(b,c) supported( b) table(e)
on(d,e) supported( d)
A block satisfies the clear relation if and only if there is nothing on it.
A block satisfies the table relation if and only if it is not on some block.

19. Game Description Language (continued)

20. Terminology A literal is either an atom or a negation of an atom.
p(a,b), ~p(a,b)
Rules:
subgoal … subgoal
head body
An expression is ground if and only if it contains no variables.

21. r(X,Z) :- p(X,Y) & q(Y,Z) & ~r(X,Y)
Safety
A rule is safe if and only if every variable in the head appears in some positive subgoal in the body.
Safe Rule:
r(X,Z) :- p(X,Y) & q(Y,Z) & ~r(X,Y)
Unsafe Rule:
r(X,Z) :- p(X,Y) & q(Y,X)
r(X,Z) :- p(X,Y) & ~q(Y,Z)
In GDL, we require all rules to be safe.

22. Dependency Graph
The dependency graph for a set of rules is a directed graph in which (1) the nodes are the relations mentioned in the head and bodies of the rules and (2) there is an arc from a node p to a node q whenever p occurs with the body of a rule in which q is in the head.
r(X,Y) :- p(X,Y) & q(X,Y)
S(X,Y) :- r(X,Y)
S(X,Z) :- r(X,Y) & t(Y,Z)
t(X,Z) :- s(X,Y) & s(Y,X)
A set of rules is recursive if it contains a cycle. Otherwise, it is non-recursive. t s r p q

23. Stratified Negation
The negation in a set of rules is said to be stratified if and only if there is no recursive cycle in the dependency graph involving a negation.
Negation that is not stratified:
r(X,Z) :- p(X,Y,Z)
r(X,Z) :- p(X,Y,Z) & ~r(Y,Z)
Stratified Negation:
t(X,Y) :- q(X,Y) & ~r(X,Y)
r(X,Z) :- p(X,Y)
r(X,Z) :- r(X,Y) & r(Y,Z)
In GDL, we require that all negations be stratified.

24. r(X,Z) :- p(X,Y) & q(Z) & r(Y,Z)
Stratified Recursion
The recursion in a set of rules is said to be stratified if and only if every variable in a subgoal relation occurs in a subgoal with a relation at a lower stratum.
Stratified Recursion:
r(X,Z) :- p(X,Y) & q(Z) & r(Y,Z)
Recursion that is not stratified:
r(X,Z) :- r(X,Y) & r(Y,Z)
In GDL, we require that all recursions be stratified.

25. GDL

26. Relevance to GDL
A GDL description is an open logic program in which we treat does and true as inputs. For each choice of inputs, the description tells us init, legal, next, goal, and terminal.
Upshot is that each GDL program corresponds to one and only one state machine.
Initial state is the state in which all init facts are true.
Initial legal actions are defined in terms of this state.
Given initial facts and choice of legal actions, next tells us what is true in the next state.
And so forth.

27. Game-Independent Vocabulary
Object Constants:
0, 1, 2, 3, … , numbers
Relation Constants:
role(player)
proposition(proposition)
action(action)
init(proposition)
true(proposition)
next(proposition)
legal(player,action)
does(player,action)
goal(player,reward)
terminal

28. Game-Specific Vocabulary
Object constants:
white, black - players
x, o, b - marks
Function Constants:
mark(number,number) --> action
cell(number,number,mark) --> proposition
control(player) --> proposition
RelationConstants:
row(number,player)
column(number,player)
diagonal(player)
line(player)
open

29. No Built-in Assumptions
What we see:
next(cell(M,N,x)) :-
does(white,mark(M,N)) &
true(cell(M,N,b))
What the player sees:
next(welcoul(M,N,himenoing)) :-
does(himenoing,dukepse(M,N)) &
true(welcoul(M,N,lorenchise))

30. Knowledge Interchange Format
Knowledge Interchange Format is a standard for exchange of knowledge represented in relational logic.
Syntax is prefix version of standard syntax.
Operators are renamed.
Case-independent. Variables are prefixed with ?.
r(X,Y) :- p(X,Y) & X!=Y & ~q(Y)
(<= (r ?x ?y)
(and (p ?x ?y) (distinct ?x ?y) (not (q ?y))))
(p ?x ?y) (distinct ?x ?y) (not (q ?y)))
Semantics is the same.

31. Miscellaneous

32. Agent Communication Language
Start Message
(start id role (s1 … sn) startclock playclock)
Play Message
(play id (a1 ... ak))
Stop Message
(stop id (a1 ... ak))

33. Completeness
Of necessity, game descriptions are logically incomplete in that they do not uniquely specify the moves of the players.
Every game description contains complete definitions for legality, termination, goalhood, and update in terms of the primitive moves and the does relation.
The upshot is that in every state every player can determine legality, termination, goalhood and, given a joint move, can update the state.

34. Playability
A game is playable if and only if every player has at least one legal move in every non-terminal state.
Note that in chess, if a player cannot move, it is a stalemate. Fortunately, this is a terminal state.
In GGP, we guarantee that every game is playable.

35. Winnability
A game is strongly winnable if and only if, for some player, there is a sequence of individual moves of that player that leads to a terminating goal state for that player.
A game is weakly winnable if and only if, for every player, there is a sequence of joint moves of the players that leads to a terminating goal state for that player.
In GGP, every game is weakly winnable, and all single player games are strongly winnable.