Using Abstraction for Planning in Sokoban

1
Using Abstraction for Planning in Sokoban

• Adi Botea, Martin Müller, Jonathan Schaeffer
• University of Alberta
• CG 2002

2
Outline

• What is Sokoban

• Motivation
• Planning Abstraction in Sokoban
• Experimental Results
• Future Work
• Conclusion

3
What is Sokoban
4
Previous Work in Sokoban

• Rolling Stone
• Deepgreen
• Standard 90 problem suite

5
Motivation

• Heuristic Search is not Enough
• Why Planning?
• Why Abstraction?

6
Heuristic Search is not Enough

• Sokoban is hard
• Large branching factor (can be gt 100)
• Long solutions (can be gt 600)
• Deadlocks
• Expensive evaluation function
• Humans create hard problems

7
Why Planning?

• Humans not only search but also plan
• Significant progress in AI planning recently
• AIPS planning competition
• Few results published about planning in games
  (even fewer successful results!)

8
Why Abstraction?

• Non-abstracted planning in Sokoban is limited
• Abstraction can reduce branching factor, solution
  length, and likelihood of encountering a deadlock
• Actions ? atomic moves
• Humans also abstract problems

9
Maze Abstraction

• Maze Rooms Tunnels

10
Maze Preprocessing
11
Sokoban as a Planning Domain
BEFORE
AFTER
82
MOVE
81
80
Position(80) Position(81) Position(82) CanPush(82,
81, 80)
StoneAt(81) ManCanGoTo(82) !StoneAt(80)
!StoneAt(81) ManAt(81) StoneAt(80)
12
Planning Abstraction
TLPlan
13
Plain Sokoban

• TLPlan
• General purpose planner
• Supports domain-specific
• knowledge
• Domain-specific knowledge
• Distance heuristic Minmatching
• Deadlock database
• World equivalence
• 0 real problems solved

14
Tunnel Sokoban

• Abstracted tunnels
• Non-abstracted rooms
• Planning actions
• Simple push moves inside rooms
• Macro moves for tunnels
• Push a stone across a tunnel
• Park a stone to a tunnel
• Un-park a stone from a tunnel
• 1 real problem solved

Abstracted Rooms
Abstracted Tunnels
Domain Specific Knowledge
TLPlan
15
Abstract Sokoban

• Abstracted both rooms and tunnels
• Planning actions
• Move a stone from one
• room/tunnel to another room/tunnel
• Shuffle stones inside a room
• so that the man can walk
• between two entrances
• No simple push moves anymore
• 17 real problems solved

Abstracted Rooms
Abstracted Tunnels
Domain Specific Knowledge
TLPlan
16
Planning Move - Example
MOVE AT THE ABSTRACT LEVEL
WHAT ACTUALLY HAPPENS
17
Problem Decomposition

• One global abstract problem
• Several local abstract problems
• (one for each room)

T0
T3
R2
R0
R3
T1
R2
T2
R1
R0
GLOBAL PROBLEM
LOCAL PROBLEMS
R3
R1
R3
R0
R1
R2
18
Local Problems

• Two main goals
• Compute planning preconditions
• Detect local deadlocks
• Rooms
• Small ? complete knowledge
• Large ? on demand search

19
Local Abstraction
SAME ABSTRACT STATE OF A ROOM
SAME ABSTRACT STATE OF A TUNNEL
20
Experimental Results
SP stone pushes in RS solution
Solution length
Problem number
21
Experimental Results
Expanded nodes
Number of stones
22
Experimental Results

• Compare Abstract Sokoban (AS) to Tunnel Sokoban
  (TS) and Rolling Stone (RS)
• Abstract Sokoban
• 17/90 problems solved so far
• Each abstraction step reduces search complexity
  by orders of magnitude
• Promise to overcome limitations of heuristic
  search approaches

23
Future Work

• Solve more problems
• Maze decomposition
• Global deadlock detection
• Parallel Sokoban
• Automatic abstraction of planning domains
• Planning abstraction in other domains, such as
  Go

24
Conclusion

• Abstract Sokoban
• Highly abstracted representation as a planning
  domain
• Experimental Results
• Exponential reduction of initial search space
• Promise to overcome limitations of heuristic
  search approaches