1 / 98

Game Description

General Game Playing Lecture 3. Game Description. Michael Genesereth / Nat Love Spring 2006. Finite Synchronous Games. Finite environment Environment with finitely many states One initial state and one or more terminal states Finite Players

fritz-dale
Download Presentation

Game Description

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. General Game Playing Lecture 3 Game Description Michael Genesereth / Nat Love Spring 2006

  2. Finite Synchronous Games Finite environment Environment with finitely many states One initial state and one or more terminal states Finite Players Fixed finite number of players Each with finitely many “actions” Each with one or more goal states Synchronous Update All players move on all steps (some no ops) Environment changes only in response to moves

  3. Example aa ab s2 s5 s8 aa bb ab aa aa ab bb ab ab s1 s3 s6 s9 s11 ba aa ba ba ab bb bb aa aa s4 s7 s10

  4. Example Revisited S ={s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11} I1={a, b} I2={a, b} u(s1,a,a,s2) u(s4,a,a,s7) u(s7,a,a,s10) u(s10,b,a,s9) u(s1,a,b,s3) u(s4,a,b,s3)u(s8,a,b,s5) u(s10,b,b,s11) u(s1,b,a,s4) u(s6,a,a,s5) u(s8,b,b,s11) u(s11,a,a,s11) u(s1,b,b,s1) u(s6,a,b,s9) u(s9,a,a,s8) u(s2,a,a,s5) u(s6,b,a,s7) u(s9,a,b,s11) u(s2,a,b,s3) u(s6,b,b,s3) i=s1 T ={s3, s8, s11} G1={s8, s11}G2={s3, s7}

  5. Games as Mathematical Structures An n-player game is a structure with components: S - finite set of states I1, …, In - finite sets of actions, one for each player u  S  I1 ... In S - update relation i  S - initial game state T  S - the terminal states G1, ..., Gn - where Gi S - the goal relations

  6. Direct Description Good News: Since all of the games that we are considering are finite, it is possible in principle to communicate game information in the form of sets of objects and tuples of objects. Problem: Size of description. Even though everything is finite, these sets can be large.

  7. Relational Nets

  8. States versus Propositions In many cases, worlds are best thought of in terms of propositions, e.g. whether a particular light is on or off. Actions often affect a subset of propositions. States represent all possible ways the world can be. As such, the number of states is exponential in the number of such propositions, and the action tables are correspondingly large. Idea - represent propositions directly and describe actions in terms of their effects on indidvidual propositions rather than entire states.

  9. Tic-Tac-Toe X O X

  10. Relational States cell(1,1,x) cell(1,2,b) cell(1,3,b) cell(2,1,b) cell(2,2,o) cell(2,3,b) cell(3,1,b) cell(3,2,b) cell(3,3,x) control(black)

  11. Transitions cell(1,1,x) cell(1,1,x) cell(1,2,b) cell(1,2,b) cell(1,3,b)cell(1,3,o) cell(2,1,b) cell(2,1,b) cell(2,2,o) cell(2,2,o) cell(2,3,b) cell(2,3,b) cell(3,1,b) cell(3,1,b) cell(3,2,b) cell(3,2,b) cell(3,3,x) cell(3,3,x) control(black)control(white) noop mark(1,3)

  12. Logical Encoding init(cell(1,1,b)) init(cell(1,2,b)) init(cell(1,3,b)) init(cell(2,1,b)) init(cell(2,2,b)) init(cell(2,3,b)) init(cell(3,1,b)) init(cell(3,2,b)) init(cell(3,3,b)) init(control(x)) legal(W,mark(X,Y)) :- true(cell(X,Y,b)) & true(control(W)) legal(white,noop) :- true(cell(X,Y,b)) & true(control(black)) legal(black,noop) :- true(cell(X,Y,b)) & true(control(white)) …

  13. Syntax of Relational Logic

  14. Syntax of Relational Logic Vocabulary: Object Variables: X, Y, Z Object Constants: a, b, c Function Constants: f, g, h Relation Constants:p, q, r Logical Operators:~, &, |, :-, # Terms: Variables: X, Y, Z Object Constants: a, b, c Functional Terms: f(a), g(a,b), h(a,b,c) Sentences: Simple Sentences: p(a,g(a,b),c) Logical Sentences: r(X,Y) :- p(X,Y) & ~q(Y)

  15. Safety A rule is safe if and only if every variable in the head appears in some positive subgoal in the body. Safe Rule: Unsafe Rule: In GDL, we require all rules to be safe.

  16. 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. t s r p q A set of rules is recursive if it contains a cycle. Otherwise, it is non-recursive.

  17. Recursion A set of rules is recursive if it contains a cycle. Otherwise, it is non-recursive. t s r p q

  18. Stratified Negation The negation in a set of rules is said to be stratified if there is no recursive cycle in the dependency graph involving a negation. Stratified Negation: Negation that is not stratified: In GDL, we require that all negations be stratified.

  19. Extensional and Intensional Relations Database applications start with a partial database, i.e. sentences for some relations (extensional relations) and not others (intensional relations). Rules are then written to define the intensional relations in terms of the extensional relations. rules Extensional Intensional Given an extensional database and a set of rules, we can obtain the database’s closure as follows.

  20. Example Database applications start with a partial database, i.e. sentences for some relations (extensional relations) and not others (intensional relations). Rules are then written to define the intensional relations in terms of the extensional relations. Given an extensional database and a set of rules, we can obtain the database’s closure as follows.

  21. Single Rule The value of a single non-recursive rule on a database D is the set of all rule heads obtained by consistently substituting ground terms from D for variables in such a way that the substituted subgoals are all in D. Sample Rule: Database: Extension:

  22. Multiple Rules The value of a set ofrules with a common relation on a database D is the union of the values on the individual rules. Sample Rules: Sample Database: Value:

  23. Multiple Relations The value of a set of non-recursive rules with different head relations is obtained by evaluating rules in order in which their head relations appear in the corresponding dependency graph. Sample Rules: Value Computation:

  24. Recursion To compute the value of a recursive rule, start with the empty relation. Compute the value using multiple rule computation. Iterate till no new tuples are added. Sample Rules: Value Computation:

  25. Negation There are various ways to compute the value of negative rules. In classical negation, a negation is true only if the negated sentence is known to be false (i.e. there must be rules concluding negated sentences). This is the norm in computational logic systems. In GDL, we do not have such rules. In negation as failure, a negation is true if and only if the negated sentence is not known to be true. This is the norm in database systems.

  26. Negation as Failure Example Definition: Value Computation:

  27. Game Description Language

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

  29. Tic-Tac-Toe 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

  30. Extensional and Intensional Relations Extensional Relations: does(player,action) true(proposition) Intensional Relations: role(player) init(proposition) legal(player,action) next(proposition) goal(proposition,score) terminal

  31. Roles role(white) role(black)

  32. Initial State init(cell(1,1,b)) init(cell(1,2,b)) init(cell(1,3,b)) init(cell(2,1,b)) init(cell(2,2,b)) init(cell(2,3,b)) init(cell(3,1,b)) init(cell(3,2,b)) init(cell(3,3,b)) init(control(x))

  33. Legality legal(W,mark(X,Y)) :- true(cell(X,Y,b)) & true(control(W)) legal(white,noop) :- true(cell(X,Y,b)) & true(control(black)) legal(black,noop) :- true(cell(X,Y,b)) & true(control(white))

  34. Physics next(cell(M,N,x)) :- does(white,mark(M,N)) next(cell(M,N,o)) :- does(black,mark(M,N)) next(cell(M,N,Z)) :- does(W,mark(M,N)) & true(cell(M,N,Z)) & Z#b next(cell(M,N,b)) :- does(W,mark(J,K)) & true(cell(M,N,b)) & (M#J | N#K) next(control(white)) :- true(control(black)) next(control(black)) :- true(control(white))

  35. Supporting Concepts row(M,W) :- diagonal(W) :- true(cell(M,1,W)) & true(cell(1,1,W)) & true(cell(M,2,W)) & true(cell(2,2,W)) & true(cell(M,3,W)) true(cell(3,3,W)) column(N,W) :- diagonal(W) :- true(cell(1,N,W)) & true(cell(1,3,W)) & true(cell(2,N,W)) & true(cell(2,2,W)) & true(cell(3,N,W)) true(cell(3,1,W)) line(W) :- row(M,W) line(W) :- column(N,W) line(W) :- diagonal(W) open :-true(cell(M,N,b))

  36. Goals and Termination goal(white,100) :- line(x) goal(white,50) :- ~line(x) & ~line(o) & ~open goal(white,0) :- line(o) goal(black,100) :- line(o) goal(white,50) :- ~line(x) & ~line(o) & ~open goal(white,0) :- line(x) terminal:- line(W) terminal:- ~open

  37. More Tedious Details

  38. 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))

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

  40. Agent Communication Language Start Message (start idrole (s1 … sn) startclockplayclock) Play Message (play id (a1 ... ak)) Stop Message (stop id (a1 ... ak))

  41. Propositional Nets

  42. Buttons and Lights p q r a b c

  43. Relational States p p q r p q

  44. State Machine p p q r p q

  45. Logical Encoding init(q) legal(robot,a) legal(robot,b) legal(robot,c) next(p) :- does(robot,a) & -true(p) next(p) :- does(robot,b) & true(q) next(p) :- does(robot,c) & true(p) next(q) :- does(robot,a) & true(q) next(q) :- does(robot,b) & true(p) next(q) :- does(robot,c) & true(q) next(r) :- does(robot,a) & true(r) next(r) :- does(robot,b) & true(r) next(r) :- does(robot,c) & true(q) goal :- true(p) & -true(q) & true(r) term :- true(p) & -true(q) & true(r)

  46. Buttons and Lights Formalization S ={s1, s2, s3, s4, s5, s6, s7, s8} I = {a, b, c} u(s1,a,s5) u(s000,b,s010) u(s000,c,s001) u(s2,a,s2) u(s000,b,s010) u(s000,c,s001) u(s3,a,s3) u(s000,b,s010) u(s000,c,s001) u(s4,a,s4) u(s000,b,s010) u(s000,c,s001) I = s1 T = {s8} G = {s8}

  47. Buttons and Lights Formalization P ={p, q, r} I = {a, b, c} u(s1,a,s5) u(s000,b,s010) u(s000,c,s001) u(s2,a,s2) u(s000,b,s010) u(s000,c,s001) u(s3,a,s3) u(s000,b,s010) u(s000,c,s001) u(s4,a,s4) u(s000,b,s010) u(s000,c,s001) I = s1 T = {s8} G = {s8}

  48. Transitions cell(1,1,x) cell(1,1,x) cell(1,2,b) cell(1,2,b) cell(1,3,b) cell(1,3,o) cell(2,1,b) cell(2,1,b) cell(2,2,o) cell(2,2,o) cell(2,3,b) cell(2,3,b) cell(3,1,b) cell(3,1,b) cell(3,2,b) cell(3,2,b) cell(3,3,x) cell(3,3,x) control(black) control(white) noop mark(1,3)

  49. Buttons and Lights p q r s a b c d

More Related