Maxwell Chess Engine

[eboatwright]

Hello TalkChess!

Over the past ~2 months I've been writing a Chess engine in Rust, and I'd like to get it out to the world!
It's not very strong right now (~2000 Lichess, 1830 CCRL Blitz), but I'm currently working on a complete re-write of the search & evaluation (version 3.1), so hopefully it doesn't stay that low for long

Links:
https://github.com/eboatwright/maxwell
https://lichess.org/@/MaxwellOnLC

[Carlos777]

Welcome to the forum!

I included your engine on my tournament, it did well for a newcomer. I hope you keep improving it.

Best regards,
Carlos

[eboatwright]

That's great! Thanks, I hope so too!

[mvanthoor]

Hello TalkChess!

Over the past ~2 months I've been writing a Chess engine in Rust, and I'd like to get it out to the world!
It's not very strong right now (~2000 Lichess, 1830 CCRL Blitz), but I'm currently working on a complete re-write of the search & evaluation (version 3.1), so hopefully it doesn't stay that low for long

Links:
https://github.com/eboatwright/maxwell
https://lichess.org/@/MaxwellOnLC

Hi I took a look at your engine, as a fellow Rust engine author.

(PS @ rating list maintainers: what happened to the ratings? Everyting seems to have dropped by some 120 points.)

Your engine is rated at ~1830 in CCRL, vs 1800 for the current version of my engine (Rustic Alpha 3), even though the feature-set of your engine is much greater. You have functionality in the engine that Rustic Alpha 3 doesn't implement (null move, futility pruning, LMR, to name a few), but the strength difference is minimal.

Therefore your engine seems underpowered for the feature-set it has. That means you either have lots of bugs, or the engine is slow. I have seen this with several other new engines (and provided the same comments), and after testing and bugfixing they improved a lot.

In case you are wondering about Rustic Alpha 3's feature set:

- The basics: magic bitboard move generator, a/b-search, q-search, check extensions, mvv-lva move ordering
- Evaluation: hand-written, non-tuned PSQT's (not tapered)
- Extra features: principal variation search, transposition table, move ordering on TT move, killer moves

That's it.

For the feature-set your engine has, I would have expected it to be in the 2200+ range.

Also: I can't get it to run properly from the command-line. Basically every command I give, except for 'uci' and 'isready', the engine crashes. If I try to do anything such as 'go' or 'go infinite', the engine crashes. It seems error-handling can use some improvement. (In my engine, you can just start it and type 'go' to make it analyze. You don't even have to follow the exact UCI-protocol. It's always ready to play. It's also impossible to crash it from the command-line... if you manage it, tell me how you did it, so I can fix it.) PS: There is no UCI-parameter to set the hash table size.

Hopefully you can take something away from this (well-meant) critique and improve the engine further.

[eboatwright]

Hey I've seen your website! I used your post about MVV-LVA as reference (speaking of which, forgot to add that to the references & resources list, it's fixed now )

Yeah I noticed that, that's the main reason I've been rewriting the search, evaluation and ordering pretty much from scratch over the past week or so. It's been slow going but I have a way better understanding of all the techniques

Most of my values are pretty much non-tuned as well, do you have any insight on how I could get started with that? I tried to write my own program that would run the engines (like Cutechess, but specially interfaced with the engine so I could have it play with different values) but I couldn't get it to read the "bestmove" commands after the engine would print it out

Yeah it has a very minimal interface, I really just have the bare minimum required to use Lichess and Cutechess.
I can definitely work on the CLI stuff for v3.1, I've really just been focused on trying to understand search pruning techniques haha

Thanks for the critiques! If you see anything wrong with my implementations please let me know

[eboatwright]

Also: I can't get it to run properly from the command-line. Basically every command I give, except for 'uci' and 'isready', the engine crashes. If I try to do anything such as 'go' or 'go infinite', the engine crashes. It seems error-handling can use some improvement. (In my engine, you can just start it and type 'go' to make it analyze. You don't even have to follow the exact UCI-protocol. It's always ready to play. It's also impossible to crash it from the command-line... if you manage it, tell me how you did it, so I can fix it.)

Yeah so I only have 3 ways to use the go command implemented:
"go movetime X"
"go wtime X btime Y"
"go depth X"

But for v3.1 I'll definitely expand on the CLI interface

PS: There is no UCI-parameter to set the hash table size.

Yeah, I've implemented a different way of restraining the TT size, should I switch to a "normal" implementation of doing something like: "zobrist_key % tt_size" for an index?
Currently I use an "aging" system because (I hope) it minimizes the amount of key collisions because I'm not doing the modulo method

Thanks again for checking out Maxwell!

[mvanthoor]

Hey I've seen your website! I used your post about MVV-LVA as reference (speaking of which, forgot to add that to the references & resources list, it's fixed now )

Thanks for the credits

Yeah I noticed that, that's the main reason I've been rewriting the search, evaluation and ordering pretty much from scratch over the past week or so. It's been slow going but I have a way better understanding of all the techniques

It's important to get the engine to be bug-free. This can get you hundreds of points of playing strength. If I remember correctly, Drofa was a derivative of Shallow Blue, and after fixing the bugs without doing anything else, Drofa was about 250 points stronger than Shallow Blue.

Most of my values are pretty much non-tuned as well, do you have any insight on how I could get started with that? I tried to write my own program that would run the engines (like Cutechess, but specially interfaced with the engine so I could have it play with different values) but I couldn't get it to read the "bestmove" commands after the engine would print it out

I'm in the process of writing a tuner now. You can get a sneak peek in the repository; it's not done yet. I still have to convert the evaluation to a list of parameters (and back again), and write the tuning function itself. I also wrote a Rambling page on what I'm doing with the engine now.

After the tuner is finished, I'll obviously add a detailed section to the book / site.

Don't wait for it though; I'm basically only working on the engine a few hours per week in the weekends, so it's slow going.

Yeah it has a very minimal interface, I really just have the bare minimum required to use Lichess and Cutechess.
I can definitely work on the CLI stuff for v3.1, I've really just been focused on trying to understand search pruning techniques haha

Thanks for the critiques! If you see anything wrong with my implementations please let me know

Maybe I'll read through the code at some point. It would be best if you write the UCI interface as such that someone can just start the engine on the command-line and type "go" (my engine understands "go" as "go infinite") and the analysis starts. Also add a command such as "perft", or add a command-line option for it. Look into CLAP if you need a good, easy-to-use command-line parser. My engine includes it, so you can see how it can be done.

[mvanthoor]

Yeah so I only have 3 ways to use the go command implemented:
"go movetime X"
"go wtime X btime Y"
"go depth X"

But for v3.1 I'll definitely expand on the CLI interface

That explains why me trying didn't work. Still, if something is typed into the command-line the engine can't or shouldn't handle, it should either ignore it, or provide an "error string <message>"; crashing is... uh.... not optimal.

PS: There is no UCI-parameter to set the hash table size.

Yeah, I've implemented a different way of restraining the TT size, should I switch to a "normal" implementation of doing something like: "zobrist_key % tt_size" for an index?
Currently I use an "aging" system because (I hope) it minimizes the amount of key collisions because I'm not doing the modulo method

Thanks again for checking out Maxwell!
[/quote]

I'd go for the modulo method and remove aging, and see that you can be sure that the hash-table is bug-free. It should add somewhere between 130 and 160 Elo points in self-play. (A bit less in a gauntlet, because self-play always over-estimates.) Then add a UCI-option, so CuteChess can actually be used to set the hash size. It's not fair if your engine has a fixed size; if it has more hash table space than its opponents it has an advantage; if it has less, it has a disadvantage.

[mvanthoor]

Yeah so I only have 3 ways to use the go command implemented:
"go movetime X"
"go wtime X btime Y"
"go depth X"

But for v3.1 I'll definitely expand on the CLI interface

That explains why me trying didn't work. Still, if something is typed into the command-line the engine can't or shouldn't handle, it should either ignore it, or provide an "error string <message>"; crashing is... uh.... not optimal.

Yeah, I've implemented a different way of restraining the TT size, should I switch to a "normal" implementation of doing something like: "zobrist_key % tt_size" for an index?
Currently I use an "aging" system because (I hope) it minimizes the amount of key collisions because I'm not doing the modulo method

Thanks again for checking out Maxwell!

I'd go for the modulo method and remove aging, and see that you can be sure that the hash-table is bug-free. It should add somewhere between 130 and 160 Elo points in self-play. (A bit less in a gauntlet, because self-play always over-estimates.) Then add a UCI-option, so CuteChess can actually be used to set the hash size. It's not fair if your engine has a fixed size; if it has more hash table space than its opponents it has an advantage; if it has less, it has a disadvantage. You can obviously test the difference by adding the hash table as the only new feature and then self-playing against the previous version.

[eboatwright]

I'm in the process of writing a tuner now. You can get a sneak peek in the repository; it's not done yet. I still have to convert the evaluation to a list of parameters (and back again), and write the tuning function itself. I also wrote a Rambling page on what I'm doing with the engine now.

After the tuner is finished, I'll obviously add a detailed section to the book / site.

Don't wait for it though; I'm basically only working on the engine a few hours per week in the weekends, so it's slow going.

That's awesome! Tuning seems like a long and tedious process, I've been putting it off as long as possible and been optimizing the board, and tweaking the search function haha
But I definitely can't put it off forever, there's definitely a good 100 Elo to be gained from just tweaking it's current values (Especially in evaluation)

It would be best if you write the UCI interface as such that someone can just start the engine on the command-line and type "go" (my engine understands "go" as "go infinite") and the analysis starts.

Yeah that's probably a good idea.

Also add a command such as "perft"

The engine has "perft X" implemented, and the version on the "dev" branch even prints out the number of positions after each move from the initial position