Openings and Endgames
PSU CS410/510GAMES
Lecture 9
July 20, 2000
- Shape of game space
- Openings
- Sometimes a good-looking early move goes bad way later
- In clocked games, want to not waste clock on known
positions
- Human players have (often vast) opening books
- Computer opening book problems:
- Human-generated books have bugs: opening traps
or ``cooks'' [no learning = repeatable cooks]
- Human-generated books have commentary and analysis:
``sympathy'' problem of dumping program into
not-understood position
- Strictly ``by the book'' deals poorly with
transpositions, falling out of and back into
book, irrelevant moves, etc.
- Transposition table helps: implementation
technique is to store book positions irremovably
in t-table
- Would prefer position classes, but...
- Can explicitly indicate successor, or
try to "rig" things by giving bonus in
evaluation function for staying in book
- Sympathy problem means transition to middle game
not smooth (why am I here? What's in the t-table?)
- When are we in middle game?
- When out of book
- When significant event happens (e.g. castling,
material exchange)
- When eff. branching factor goes up
- Endgames
- When are we in the endgame?
- When material is small
- When branching factor becomes large
- When terminal nodes are reached
- Traditional endgame approach: programmed knowledge
- Trades human work for generality
- ``Theorem Proving'' approach
- Problem: pattern matching
- Which endgame positions are reachable? Who knows?
- Idea: if game is monotonic in material, work
backward = ``Retrograde analysis''
- Dynamic programming technique: explore until conversion
- Requires huge database (chess 5-piece = 150M positions)
- Can profitably be calculated in parallel
- Endgame oddities: chess
- Discoveries: certain endgames are nonintuitive.
Effective consequences?
- Transition from middle game not always smooth:
sacrifice to known (database or heuristic) win
Thanks to Dr. A.N. Walker of U. Nottingham for a web
page with some ideas on this topic.