My Open-Source Engine, Homura, is on GitHub :3

[RedBedHed]

Hello all,

Over the last year or so, I have been working on a Chess Engine. It is named Homura after one of my favorite anime characters.

I found inspiration in many papers and sources. Homura derives ideas from Stockfish, Leela, Drofa, Scorpio, Fruit, CPW-Engine, PeSTO, Blunder, and Leorik. It uses Ronald Friederich's piece square tables from PeSTO. It borrows some ideas from Blunder and Leorik.

Homura's strength seems to be somewhere in the ballpark of 2300-2550 based on cutechess-cli bullet matches with Leorik 1.0 and 2.0. My laptop is the only computer I own, and I ran out of time to implement the full UCI, so it is hard to know for sure.

As Homura was an undergrad project, I plan to leave the repository as-is and continue to work on Homura under a different name. (I might still clean a little since parts of it are messy)

Homura uses a slightly different algorithm-- Dr. Bojun Huang's Alpha-Beta rollout algorithm. However, it doesn't rely entirely on rollouts. Instead, it searches the candidate PV lines with rollouts and everything else with backtracking. It is a compromise between the novel and classical algorithms. The rollout part uses a leftmost tree policy and switches to a greedy policy when re-searches need to happen later in the list, past a certain margin. (This margin is very large near the root and shrinks to zero at the leaves.) The rollout part also probes the transposition table whenever it enters a node. Although I have no concrete explanation, it seems to outplay my backtracking algorithm. Admittedly, there may be flaws in that algorithm.

I am very insecure about the code, but nevertheless, here it is:

https://github.com/RedBedHed/Homura

[looa]

I am impressed, what else is there I can say?

[lithander]

I really like how much effort you've put into the Readme of your project. The name, logo, anime references, development history etc contribute a lot of personality and the discussion of alternative approaches to searching the game tree (including the failed experiments!) were an inspiring read!

I hope you continue working on this engine into the 3000 Elo range and continue to share your learnings. Specifically, it would be really interesting to me if you'd put additional time into measuring the strength of your engine in a Gauntlet and then compare the strength of different tree-search approaches you tried, empirically.

Your discussion of MCTS also reminded me of an idea I had when retuning Leorik's eval from scratch: The training data I use to tune Leorik's eval consists of labeled positions similar to what you'd use to train NNUE. But instead of using the eval of a top notch engine like Stockfish to label positions I'm just using the outcome of the selfplay games that I took the positions from. (So white won in the end? Then all positions I take from the game are labeled as "winning for white") Even when adding considerable noise to make the engine play less deterministic the quality of the training data set didn't suffer.

Now, the question is how much could you crank up the noise and speed of these games before the outcome of a match is no longer a good indicator of the quality of earlier positions? I was running games at 100ms increment per move. If you run your engine through a GUI you can't go much below that. But imagine you cut out the middleman (the GUI) and run the selfplay games internally to a depth of only a few plies then I think you could go much faster. Fast enough to do the rollouts of a UCT tree search?

[RedBedHed]

I really like how much effort you've put into the Readme of your project. The name, logo, anime references, development history etc contribute a lot of personality and the discussion of alternative approaches to searching the game tree (including the failed experiments!) were an inspiring read!

I hope you continue working on this engine into the 3000 Elo range and continue to share your learnings. Specifically, it would be really interesting to me if you'd put additional time into measuring the strength of your engine in a Gauntlet and then compare the strength of different tree-search approaches you tried, empirically.

Your discussion of MCTS also reminded me of an idea I had when retuning Leorik's eval from scratch: The training data I use to tune Leorik's eval consists of labeled positions similar to what you'd use to train NNUE. But instead of using the eval of a top notch engine like Stockfish to label positions I'm just using the outcome of the selfplay games that I took the positions from. (So white won in the end? Then all positions I take from the game are labeled as "winning for white") Even when adding considerable noise to make the engine play less deterministic the quality of the training data set didn't suffer.

Now, the question is how much could you crank up the noise and speed of these games before the outcome of a match is no longer a good indicator of the quality of earlier positions? I was running games at 100ms increment per move. If you run your engine through a GUI you can't go much below that. But imagine you cut out the middleman (the GUI) and run the selfplay games internally to a depth of only a few plies then I think you could go much faster. Fast enough to do the rollouts of a UCT tree search?

Thank you! I am very excited to keep working on the project! Now that I have graduated, I will have much more time (and money for better hardware lol).

I like that idea! I'm certainly no expert, but UCT-based MCTS seems to be the closest game-tree search framework to classical reinforcement learning algorithms like Q-learning. PUCT is also excellent for introducing noise from what I hear. I read that in Alpha-Zero, they introduced noise into their tree policy during self-play with a Dirichlet distribution. I'm going to research learning a little more in the coming months. Hopefully, I'll be able to contribute more to learning discussions by then!

[RedBedHed]

I am impressed, what else is there I can say?

Thank you!

[Guenther]

I compiled two win binaries (for old and new hardware) and filed two issues at github ;)

Thanks for the program!

Guenther