Lecture 14: Applications of Logic

# Artificial Intelligence

### Other Applications of Logic

---

# Satisfiability

---

# Satisfiability

* We will look at logical formulas `$\phi$` with free variables

* For example: `$x \vee (y \wedge z)$`

* Such a formula is called *satisfiable* if we can assign truth values to the free variables such that the formula is true

* There are solvers that can *find* such truth value assignments

---

# Logic-Based PCG

* We can use this idea to generate content, for example for games!

* We tell our system which properties a level/quest/story should have in terms of logical formulas

* Then we use a solver to find an assignment of truth values to the free variables

* We then interpret these assignments as a generated level/quest/story

---

# Example: Enemy Generation

* The enemy should have exactly one of 3 special abilities: a, b, and c

$$
(a \wedge \neg b \wedge \neg c) \vee (b \wedge \neg a \wedge \neg c) \vee (c \wedge \neg a \wedge \neg b)
$$

* The enemy can be a goblin, orc, or warg

$$
(g \wedge \neg o \wedge \neg w) \vee (o \wedge \neg g \wedge \neg w) \vee (w \wedge \neg g \wedge \neg o)
$$

* Wargs can not use special ability c

$$
(w \rightarrow \neg c)
$$

Any truth value assignment to g, o, w, a, b, c that satisfies these constraints will represents one possible enemy type and special attack we can generate.

---

# Challenges with Logic-Based PCG

* Checking if a formula is satisfiable is hard

* In fact, for first-order predicate logic it is undecidable :(

* What can we do? We restrict the kinds of formulas you can write

* Anyone remember Prolog?

---

# Answer-Set Programming

---

# Answer-Set Programming

* Answer-Set Programming (ASP) is a form of declarative programming

* Programs represent facts and rules

* A *solver* finds assignments to free variables that are consistent with the given facts and rules (i.e. that satisfy the corresponding formula)

* A common language for ASP is AnsProlog

---

# AnsProlog

* Facts: `p(x)`

* Rules: `p(x) :- q(x).`

* Choice: `{p(x), q(x), r(x)}`

* Restricted Choice: `1 {p(x), q(x), r(x)} 2`

* Range: `p(1..4)` is the same as `p(1). p(2). p(3). p(4).`

* Conditional literal: `p(X):q(X)` is the same as `p(x)` for all x for which `q(x)` holds

---

# AnsProlog

`c(1..n).`

`1 {color(X,I) : c(I)} 1 :- v(X).`

`:- color(X,I), color(Y,I), e(X,Y), c(I).`

What is this?

Graph coloring!

`c(1..n)` are n colors

`1 {color(X,I) : c(I)} 1 :- v(X).` Every vertex has exactly one color

`:- color(X,I), color(Y,I), e(X,Y), c(I).` Two neighbors can't have the same color

---

# A Maze

* Now let's generate some game content!

* How about mazes?

* We want our maze to be contained in a grid, with connections between adjacent grid cells

* Let's say there are no loops, and every location should be reachable from (1,1)

* Basically, we want to build a tree that is embedded in the grid

---

# A Tree in AnsProlog

```
#const width = 5.
dim(1..width).

1 { parent(X,Y, 0,-1),
    parent(X,Y, 1, 0),
    parent(X,Y,-1, 0),
    parent(X,Y, 0, 1) } 1 
    :-
    dim(X), dim(Y), (X,Y) != (1,1).
```

Each cell should have exactly one parent (up, down, left or right). What mazes do we get now?

---

# Generated Mazes

Oops, our mazes are not connected.

---

# A Solvable Maze

How do we define that our maze should be connected?

First, we say that (1,1) is connected. Then, every cell that has a parent that is connected is also connected.

Then we need to require that all cells are connected.

```
linked(1,1).
linked(X,Y) :- parent(X,Y,DX,DY), linked(X+DX,Y+DY).
:- dim(X), dim(Y), not linked(X,Y).
```

---

# Generated Mazes

If we leave the solver running, we will eventually get all possible solvable mazes in the 5x5 grid. There are many, but what if we have a way to define which ones we "prefer"?

---

# An "Interesting" Maze

* Say we want our mazes to have few vertical connections, in order to force the player to explore more horizontally

* AnsProlog actually allows you to specify an optimization constraint

```
vertical(X,Y) :- parent(X,Y,0, 1).
vertical(X,Y) :- parent(X,Y,0,-1).
#minimize { vertical(X,Y) }.
```

Typically, the solver will emit answers it finds on the way to the optimal solution, so we can actually choose how "good" of a solution we want, versus how long we want to run the solver.

---

# Generated Mazes

---

# A Dungeon

* Mazes are a bit boring, let's make a more complicated level

* Specificially, let's make a dungeon with an entrance, a gem, an altar and an exit

* The idea is that the player has to find the gem and socket it into the altar to open the exit

* Let's start with defining what such a dungeon actually is in our logical formulation

---

# A Dungeon

```
#const width=10.
param("width",width).
dim(1..width).
tile((X,Y)) :- dim(X), dim(Y).
adj((X1,Y1),(X2,Y2)) :-
         tile((X1,Y1)),
         tile((X2,Y2)),
         #abs(X1-X2)+#abs(Y1-Y2) == 1.

start((1,1)).
finish((width,width)).

% tiles have at most one named sprite
0 { sprite(T,wall), sprite(T,gem), sprite(T,altar) } 1 :- tile(T).

% there is exactly one altar and one gem in the whole level
:- not 1 { sprite(T,altar) } 1.
:- not 1 { sprite(T,gem) } 1.
```

---

# Generated Dungeons

---

# Making the Dungeon Nicer

```
% style : at least half of the map has wall sprites
:- not (width*width)/2 { sprite(T,wall) }.

% style : altars have no surrounding walls for two steps
0 { sprite(T3,wall):adj(T1,T2):adj(T2,T3) } 0 :- sprite(T1,altar).

% style : altars have four adjacent tiles (not up against edge of map)
:- sprite(T1,altar), not 4 { adj(T1,T2) }.

% style : every wall has at least two neighbouring walls 
%         (no isolated rocks and spurs )
2 { sprite(T2,wall):adj(T1,T2) } :- sprite(T1,wall).

% style : gems have at least three surrounding walls 
%         (they are stuck in a larger wall )
3 { sprite(T2,wall):adj(T1,T2) } :- sprite(T1,gem).
```

---

# Generated Dungeons

---

# A Playable Dungeon

* Similar to the maze example, we need to make sure our dungeon is actually solvable

* How? Let's simulate a player!

* Actually, we just encode what a player *could* do, and the solver will figure out how they can complete the dungeon

* Basically, we say a player touches the start, and on every step they can touch an adjacent tile if there's no wall

---

# A Playable Dungeon

```
% states:
% 1: initial
% 2: after picking up gem
% 3: after putting gem in altar

% you start in state 1
touch(T,1) :- start(T).

% possible navigation paths
{ touch(T2,2):adj(T1,T2) } :- touch(T1,1), sprite(T1,gem).
{ touch(T2,3):adj(T1,T2) } :- touch(T1,2), sprite(T1,altar).
{ touch(T2,S):adj(T1,T2) } :- touch(T1,S).

% you can’t touch a wall in any state
:- sprite(T,wall), touch(T,S).

% the finish tile must be touched in state 3
completed :- finish(T), touch(T,3).

:- not completed.
```

---

# Generated Dungeons

---

# Interesting Dungeons

* The dungeons we get may already be described as "reasonable"

* However, they may be a bit too easy to solve sometimes, because the gem is right next to the altar

* What if we could define that the player actually has to "do some work" to solve the level?

* Unfortunately, this is hard to do in standard AnsProlog

---

# Concepts and Level Designs

Consider that a generated dungeon consists of two parts:

* The level geometry

* The path a player uses to complete the level

What we want to describe is the fact that for a given **constant** level geometry, **all** possible paths have some interesting property.

Smith et al. describe an extension to AnsProlog that defines two new keywords:
`__level_design` is used to describe what is part of the level geometry, and `__concept` is used to define constraints on **all** possible assignments to something (the player's solution).

---

# Interesting Dungeons

```
% holding sprites constant , ensure every solution 
% touches at least width tiles in each state
__level_design(sprite(T,Name)) :- sprite(T,Name).

__concept :-
width { touch(T,1) },
width { touch(T,2) },
width { touch(T,3) }.
```

Now we can generate levels that are guaranteed to *require* at least `width` steps in each of the three states.

---

# Generated Dungeons

---

# ASP in practice

* One nice aspect of the ASP programs we discussed is that they are modular

* For example, we can use the check for interesting dungeons on human designed levels, too

* In practice, generating levels takes some time, and the ASP solver has to run as its own process, so levels may just be pre-generated when the game is developed

---

# CatSAT

* Ian Horswill developed CatSAT as a small, fast ASP solver as a Unity plugin

* It is specifically meant to be used at *run time*

* He also observed that for PCG the formulas typically have *many* satisfying variable assignments (because we want many different levels), so the challenge is not to find one, but to find several *different* ones

* CatSAT takes measures to ensure that subsequent runs produce substantially different results

---

# CatSAT Example

* Say we want to generate a quest 
  
  * There are 3 types of quests: Retrieve, deliver, and kill 
  
  * There are 4 types of enemies: Bandits, another kingdom, orcs, and wolves
  
  * There are some constraints on the possible quests:
       - You can't retrieve an item from the wolves
       - No more than 2 types of enemies should be present in any quest 
       - The bandits do not work together with the other kingdom 
       - etc.

---

# CatSAT Example

```C#
var p = new Problem("quest");
...
var retrieve = (Proposition)"retrieve";
...
var wolves = (Proposition)"wolves";
...
p.Inconsistent(wolves, retrieve);
...
p.AtMost(2, bandits, others, orcs, wolves);
...
p.Solve();

```

---

# Dynamic Epistemic Logic

---

---

# Dynamic Epistemic Logic

* Logic: A representation for what is true/false

* Epistemic: "from Greek ἐπιστήμη, epistēmē 'knowledge'" (or "belief")

* Dynamic: Things that change

The logic of changing knowledge/beliefs!

---

# Knowledge and Beliefs?

* Some people make a distinction between the beliefs and knowledge: Beliefs may be false, knowledge has to be true

* Other people require that knowledge not only be true, but be "justified" ("Knowledge is justified, true belief")

Example: A farmer looks from his farm house to the field, to check if his favorite cow is still there. He sees a black and white paper that got caught in the tree, and looks exactly like his cow from far away. In reality, the cow was sleeping in a hollow behind a bush on the field.

---

# Possible Worlds

* Agent beliefs are often represented using "possible worlds"

* There is an "actual world", with the things that are factually true

* Each agent then has a set of worlds that they consider possible, but they don't know which of these worlds is the actual one (if any)

* For example: I secretly flip a coin, and look at it. Now you consider two worlds possible: One in which the coin shows heads, and one in which it shows tails

---

# Theory of Mind

* Now consider my beliefs about your beliefs

* I know what the coin shows, so I only consider one world possible, but I know that you consider two worlds possible

* Likewise, for each of the worlds you consider possible, you know that I know what the coin shows, i.e. that I only consider one world possible

* We can draw such relationships in diagrams, with one node for each possible world, and arrows that show which worlds are considered possible by each agent

---

# A Diagram of the Coins Example

---

# A Joke
 
  * Three logicians walk into a bar
  
  * The barkeeper asks: "Three beers?"
  
  * The first logician says: "I don't know"
  
  * The second logician says: "I don't know"
  
  * The third logician says: "Yes!"
  
---

# Explaining the Joke

* Every logician knows if they themself want a beer or not

* Imagine if the first logician did not want a beer

- She would know about it 
  
  - Therefore, she would know that the order is not "three beers"
  
  - Therefore, she would have said "No"
  
* The second logician knows that the first logician knows if she wants a beer or not

* So, when the first logician says "I don't know", the second logician can conclude that she wants one (otherwise she'd say "No")

---

# An Epistemic View

* There are 8 possible worlds: Each logician may want a beer, or they may not

* The answer of a logician follows three rules:

- If they know that all three logicians want a beer, they say "yes"
   
   - If they know that at least one logician does not want a beer, they say "no"
   
   - Otherwise, they say "I don't know"
   
---

# One Night Ultimate Werewolf

---

# References

* Chapter 8 of [Procedural Content Generation](http://pcgbook.com/) by Noor Shaker, Julian Togelius, and Mark J. Nelson (free PDF available)

* [Clingo and Gringo ASP solvers](https://potassco.org/clingo/)
  
  * [Quantifying over play: Constraining undesirable solutions in puzzle design.](https://adamsmith.as/papers/fdg2013_shortcuts.pdf)
  
  * [CatSAT](https://github.com/ianhorswill/CatSAT)
  
  * [Intentional Agents for Doxastic Games](https://repository.lib.ncsu.edu/handle/1840.20/35747)
  
  * [A Logic For Suspicious Players](https://www.vub.ac.be/CLWF/SS/BER.pdf)

* [Dynamic Epistemic Logic](http://www.iep.utm.edu/wp-content/media/DynamicEpistemicLogic.pdf)