Chess: generating moves
Generating Moves
Part of the How to Program a Chess Engine in Lisp series.
This post will cover basic game state and move generation.
Generating Moves
Part of the How to Program a Chess Engine in Lisp series.
This post will cover basic game state and move generation.
The Chess Move
Part of the How to Program a Chess Engine in Lisp series.
This post will cover the following tasks, in preparation for generating chess moves:
FEN - Forsyth-Edwards Notation
Part of the How to Program a Chess Engine in Lisp series.
Now that we have pieces and a board, we need a convenient way of setting pieces on the board in specific positions. We'll use this, not only for the initial position of a game, but also to configure a board with specific game scenarios for testing and debugging.
The standard way to do this is to use FEN, or Forsyth-Edwards Notation: [Wikipedia] [Chess Programming Wiki]
Here is the source for fen.rkt
The Chess Board
Part of the How to Program a Chess Engine in Lisp series.
One of the most significant design decisions for a chess engine is how to model the chess board. I think the most competitive engines use a bitboard representation; however, for our purposes, a mailbox representation is more intuitive and easy to visualize. In particular, we will use a 10 x 12 board.
Here is the source for board.rkt
The Chess Piece
Part of the How to Program a Chess Engine in Lisp series.
Donald Knuth is credited with the statement:
...We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
Chess programming is most assuredly in the 3%! Our challenge in this series will be to strike a reasonable balance between efficiency and clarity. Our first opportunity to that end is the chess piece.
Here is the source for piece.rkt
Last updated 2024-11-29 18:48
Table of Contents
Introduction
Programming a competent chess engine in lisp has been a goal of mine for some time. I finally did so in 2021, and it was a lot of fun! My new goal is to rewrite the code in a step by step way that emphasizes clarity, and to present it as a clear tutorial for writing a chess engine, and as a general Racket tutorial.
Day 8 involves navigating binary trees, and modular arithmetic, but I'm getting ahead of myself. Here is our test input:
RL
AAA = (BBB, CCC)
BBB = (DDD, EEE)
CCC = (ZZZ, GGG)
DDD = (DDD, DDD)
EEE = (EEE, EEE)
GGG = (GGG, GGG)
ZZZ = (ZZZ, ZZZ)
Day 7 involves simulating a card game. Our input looks like:
The left side is our card hand. The right side is our bid amount. As always, we begin with parsing. For our purposes of illustration, I'll skip the first 20 hands to get to a more interesting one with a J:
Day 5 involves a typical Advent of Code scenario where Part 1 is easy, and a naive modification to Part 1 to get Part 2 is easy; however, the naive Part 2 solution will take far too long to run! :)
After solving Part 1 to get a star, I re-implemented the code to solve Part 2, and then Part 1 was simply making the Part 1 input conform to what Part 2 needed, and call Part 2.
The "trick" for Part 2 was to process the seed ranges as ranges, and not attempt to convert the seed ranges into lists of individual seeds.
I always enjoy recursive list processing in Racket :) Here's our input today:
Card 1: 41 48 83 86 17 | 83 86 6 31 17 9 48 53
Card 2: 13 32 20 16 61 | 61 30 68 82 17 32 24 19
Card 3: 1 21 53 59 44 | 69 82 63 72 16 21 14 1
Card 4: 41 92 73 84 69 | 59 84 76 51 58 5 54 83
Card 5: 87 83 26 28 32 | 88 30 70 12 93 22 82 36
Card 6: 31 18 13 56 72 | 74 77 10 23 35 67 36 11