Coding Adventure: Chess AI

[Mike Sherwin]

Windows Build & Source Code available here:
https://github.com/lithander/SebLagueChessEngine

I checked out the UCIed engine. Thanks for doing that! Also your video series is awesome!! I never thought to do incremental building like that. Now that you have demonstrated it so well it seems extremely logical and intuitive. Okay, now some (meaningless) ramblings. Someone that uses C# should at least take a look at Beef and give an opinion or even make a video or two on it. https://www.beeflang.org/. About UCI, I don't get it. It is possible to have 500 ply games and over 1000 ply is not impossible. I heard it takes negligible time to read in and make all those moves.

Question, is the engine expected to unwind all previous moves or just remove the last move and play it? []

If the former then why does not UCI just send a fen instead? []

When I was looking for Beef language I stumbled upon Beef chess engine. Here is a quote. "Beef implements many features found in popular modern engines, built around an original legal-move-only move generation scheme which aims to make search as fast as possible — using this design, the startpos perft speed at one point reached 385 mnps (1 CPU, no hash)! Therefore, Beef mainly hopes to achieve its playing strength from search speed." 385 mnps? On a single thread (implied)? []

When I first started my engine Bricabrac my idea was to do legal move generation with a score by using a one ply pseudo legal search with Qsearch. Now assume 10 pseudo legal moves for three ply, 1000 Qsearch (ignoring beta cuts for sake of argument) need to be done. But in what is proposed 10 + 100 + 1000 only 1110 Qsearch are done. The extra price seems trivial to having a scored list of legal moves. And the benefits of better move ordering should result in less Qsearches, anyway? It was very slow. Did I do it wrong? Or, what am I not understanding?[]

One last question. Has anyone tried Qsearch with a depth of 1 (or maybe 2) so that it is like regular search except captures (promotions also) do not decrement the search depth? []

[mvanthoor]

Question, is the engine expected to unwind all previous moves or just remove the last move and play it? []

No; you just set up the position (fen or startpos), and then play all the moves the GUI sends with it, and then the engine starts thinking. After its done, it sends the best move, and if it wanted to, it could then forget everything except the stuff in the hash table. But most engines don't, I assume; at least, mine doesn't. That's the reason why the same engine can support both XBoard and UCI if needed.

You can, of course, find the last move in the list you've been sent and play only that, but in that case you can get into trouble if the GUI started a new game without sending "ucinewgame".

If the former then why does not UCI just send a fen instead? []

The reason is that the engine is "supposed" to be stateless (but most aren't, actually, so they can do things like ponder, if they wanted to). If you send only an FEN, you can't look backwards through the game for things such as first repetitions if you don't keep them yourself. The GUI _could_ send an FEN, _if_ the engine keeps some states remembered, but most GUI's expect the engine to be blank after it makes its move.

When running as a UCI engine, the program isn't really a "chess player"; it's a "move searcher" that starts at a given position, with a given amount of time for some count of moves. (This is also the main argument why some people like Xboard better.)

XBoard is written for smart engines and mostly not-so-smart GUI's.
UCI is written for mostly dumb engines and very smart GUI's.

385 mnps? On a single thread (implied)? []

385 MILLION nodes/second without a hash table? Can't really believe that.