• allow user to specify for both players:
  • evaluator
  • search
  • turn color (mutually exclusive ofc)
• maybe part of the binary for #29, or maybe not
• stretch incorporate 50-move rule
  • otherwise end game after 100 turns

Design

so, using these moves in a game just won't work

Add class- and method- level scaladoc for the code so far (and start doing it henceforth so this bug doesn't return).

Starting ideas:

• captures first
• lower values piece moves first

Just human vs bot is fine for now.

• Stalemate
• threefold repetition
• 75-move rule (claim-agnostic)
• impossible checkmate
  https://en.wikipedia.org/wiki/Draw_(chess)

https://www.baeldung.com/scala/play-rest-api

A general evaluator should compose other evaluators

Thoughts for low-level evaluators

• scores of remaining pieces
• pawns in the center
• king protection (castled or able to castle)
• developed (moved once) knight/bishop pieces

Right now there's no concept of pawn promotion in the system--the rules just aren't built in.

See official rules

• Allow user to choose the search and utility modules used
• Allow early termination via user input
• Print out the board after each move
• End when game is over
• stretch accept standard move notation (e.g. O-O, Rxb2)

The bot doesn't abide by the maxim "Castle early, and castle often". Rather, it frequently makes normal king moves in the early game, surrendering the ability to castle in favor of developing pieces (see #41)

Function should produce a set containing the respective next boards for all currently legal moves.

The bot currently doesn't seem to care about developing its minor pieces.

Rules:

• king must not have moved
• castling rook must not have moved
• king can't be in check
• nearest 2 spaces in castling rook's direction from king can't be controlled by opponent
• other pieces can't be in the way

Reference: chess.com

https://docs.github.com/en/free-pro-team@latest/actions/quickstart