An update on Blunder 1.0.0

[algerbrex]

A couple of weeks ago I started a thread on here where I announced the first version of my UCI chess engine Blunder. However, after further testing of the engine, I realized how many significant bugs and issues it had, and so I stripped away most of the features, spent some time refactoring and designing the engine, and created a more complete project release.

I'm much happier with what I have now, which I've released as Blunder 1.0.0, and replaced the original first version of my engine, and I feel like I now have a much better basis upon which to grow my engine. From personal testing, my estimate for my engine's current rating is ~1400, which is a bit low as I understand. I'm theorizing that this is mostly because I'm using my own, hand-written piece-square tables in this first version, and admittedly, I'm not the best chess player

As you'll see if you visit the project page linked above, I have many features which I'll be looking at adding in the coming weeks (hopefully quite a few before I start school again), so I have a pretty good idea of the direction I want to take the project for now.

With that being said, I'd love to have feedback on the structure and design of the code and the overall project. Additionally, I'm currently looking at getting my engine added to the CCRL rating lists, so any information shared concerning having that process go smoothly would be appreciated also.

[gflohr]

I think that every chess engine project should either have documentation on building the program from the sources or offer a download link to precompiled binaries for at least linux, macos, and ms-dos. In the case of Blunder, I first have to figure out from the source files (not the README because it doesn't mention the language) that the engine is written in Go, and then - if I'm not fluent in Go - I have to figure out how I can build applications written in Go. Just copy that information over from other Golang projects and you should be fine.

Your link to the ChangeLog is broken: docs/chanelog.md should read docs/changelog.md.

Cool that you have unit tests for your engine. But the test coverage doesn't look very impressive so far.

Your "main.go" looks a little bit problematic to me. What if "DEBUG" becomes true? And you seem to expect that the very first command you receive is one of "uci", "debug" (which is rather "interactive"), or "options" (which is rather "help"). I think that a lot of human users consider the initial "uci" command just noise and wouldn't bother sending it at all. And you can probably make do without switching to a particular mode and instead just mix UCI commands with your own extensions like everybody else seems to do. UCI is neither an interface nor a protocol after all but just a mess.

And slightly off-topic: Enter "blunder chess" or "blunder chess engine" into your favorite search engine and then try to estimate how much more ELO you have to code into your engine to have it show up on the first result page!? Or maybe just rename the project to "GoBlunder"?

In "engine/board.go" you have a string constant "FENKiwiPete". I'm pretty sure that this string constant should be in test code but not there.

If you want to make your engine faster, you could try a brute force approach for "undoMove": Instead of applying and reverting a move to a position, you can just make a copy of the position and apply the move to the copy. In C that seems to be slower than the bit fiddling but I would give the memcpy approach a try in Golang. If your undoMove() requires a lot of implicit array boundary checkings, just copying the memory could be faster.

Otherwise, I found the Blunder code a lot more pleasant to read than the code of other engines I have studied, especially my own one.

[AndrewGrant]

Your "main.go" looks a little bit problematic to me. What if "DEBUG" becomes true? And you seem to expect that the very first command you receive is one of "uci", "debug" (which is rather "interactive"), or "options" (which is rather "help"). I think that a lot of human users consider the initial "uci" command just noise and wouldn't bother sending it at all. And you can probably make do without switching to a particular mode and instead just mix UCI commands with your own extensions like everybody else seems to do. UCI is neither an interface nor a protocol after all but just a mess.

Ill disagree with this. I believe the UCI standard enforces that UCI is the first command to be received, and if you want a strict definition, this is okay in my view. -- but also strict definitions suck

[algerbrex]

I think that every chess engine project should either have documentation on building the program from the sources or offer a download link to precompiled binaries for at least linux, macos, and ms-dos. In the case of Blunder, I first have to figure out from the source files (not the README because it doesn't mention the language) that the engine is written in Go, and then - if I'm not fluent in Go - I have to figure out how I can build applications written in Go. Just copy that information over from other Golang projects and you should be fine.

Hi, and thanks for the feedback!

I'm a little confused about what you mean in this first part, however. I made sure in the README to mention the language Blunder is written in, and how to install the Go compiler and create your own executable. All of this should be in the "Installation" section. Granted the section could definitely longer and more in-depth, but I thought I mentioned the basics.

Your link to the ChangeLog is broken: docs/chanelog.md should read docs/changelog.md.

Thanks, fixed.

Cool that you have unit tests for your engine. But the test coverage doesn't look very impressive so far.

Haha, I see what you mean, but the tests I included weren't really supposed to be unit tests, more so just move generation testing. I also plan on adding some tests to make sure the search and evaluation parts of Blunder are working as well. Of course, I probably should still add unit tests

Your "main.go" looks a little bit problematic to me. What if "DEBUG" becomes true? And you seem to expect that the very first command you receive is one of "uci", "debug" (which is rather "interactive"), or "options" (which is rather "help"). I think that a lot of human users consider the initial "uci" command just noise and wouldn't bother sending it at all. And you can probably make do without switching to a particular mode and instead just mix UCI commands with your own extensions like everybody else seems to do. UCI is neither an interface nor a protocol after all but just a mess.

Well "DEBUG" should never be true, as that's only used in debugging the engine. It'll always be set to false in actual releases. Really "DEBUG" was just a convenient way for me to switch between testing and then debugging the engine.

And regarding the UCI command, Andrew Grant expressed my thinking.

And slightly off-topic: Enter "blunder chess" or "blunder chess engine" into your favorite search engine and then try to estimate how much more ELO you have to code into your engine to have it show up on the first result page!? Or maybe just rename the project to "GoBlunder"?

Thanks for pointing this out, I hadn't really considered the name too much, not since I came up with it 2-3 months ago.

In "engine/board.go" you have a string constant "FENKiwiPete". I'm pretty sure that this string constant should be in test code but not there.

Oh, it is (see "tests/perftsuite.txt" in the project), it's also a constant there however because it's a nice position to use in debugging and testing various aspects of the engine since the start position isn't usually varied enough.

If you want to make your engine faster, you could try a brute force approach for "undoMove": Instead of applying and reverting a move to a position, you can just make a copy of the position and apply the move to the copy. In C that seems to be slower than the bit fiddling but I would give the memcpy approach a try in Golang. If your undoMove() requires a lot of implicit array boundary checkings, just copying the memory could be faster.

That was an option I considered at the start of Blunder, but especially since Golang has a garbage collector, the performance would probably tank, being even worse than C, since potentially millions of board objects would be created in memory, and the garbage collector has to maintain these objects.

I remember my first approach of encoding moves used objects, but since I was creating millions of move objects, that slowed my code down enormously, and when I switched to encoding moves using 16 bit integers, I gained around a ~40 percent speed up.

Otherwise, I found the Blunder code a lot more pleasant to read than the code of other engines I have studied, especially my own one.

Thank you