So at the end of last year, I started getting more interested in chess.
I began playing online, studying puzzles, watching videos, and generally getting engaged in the chess space. Because of this, my recommendations on YouTube started to feature quite a lot of chess related content. That’s how I stumbled upon a video by Sebastian Lague, in which he tries to make a “Chess AI” to play against.
I thought that it looked like a fun thing to try, and since I was looking for a coding side-project for a while now, I decided to give it a shot. And while I was at it, I also decided to document my journey!
Surveying the Landscape
Right, so we want to build a chess engine. But how does one actually go about doing it?
I began by searching for resources that already exist on the topic of chess programs. Early on, I found the Chess Programming Wiki which proved to be a great source of information, as it covered all the important principal topics, a lot of the different ways of optimizing Chess algorithms, as well as provided a great Getting Started jump-off point for anyone hoping to dive into chess programming. It also has a very extensive Recommended Reading section, which saved me a lot of time during this phase.
Chess Program vs. Chess Engine
The first practical hurdle I faced was when deciding how to go about actually implementing the program itself. My first naive approach was that I had to obviously make the whole thing from scratch as a standalone program. I contemplated what game engine or framework would be best, but I was a bit unsatisfied since none of the better maintained frameworks and engines supported any of the languages close to my heart, like Go, or at least Python.
Wanting to develop in my preferred language of choice, I came to the idea of decoupling the graphical interface and the engine which would be calculating the best moves, essentially splitting the single program into frontend and backend. I would write the interface in something like Unity (I still might do that in the future as a separate project) and the engine in Go.
Luckily (and probably obviously) I wasn’t the first person to come up with this idea.
Protocols & Interfaces
So turns out, people (as is more often than not the case) have already dealt with a similar issue and found a solution. There are already numerous options when it comes to Chess programs (or GUIs for our purposes) which support custom chess engines. (A nice list can be found on the wiki) They do so by utilizing a couple of standardized protocols to communicate with the engine code.
The two most commonly used protocols I found were Chess Engine Communication Protocol (CECP), often simply dubbed xboard after the program which introduced it, and the Universal Chess Interface (UCI).
After some time pondering this topic, I finally decided to only implement a chess engine for now, as opposed to a complete chess program (Which gives me the opportunity for a second project in the future maybe…), as it will likely be faster and will allow me to further my coding skills with my language of choice, Go.
I also decided to go with UCI as the communication protocol for this project, as it seemed like the more straight-forward to implement (smaller number of individual commands, using
stdout as its communication channels), as well as the better supported by a wider number of graphical interfaces (CECP slightly lacking in this regard).
So, after getting all of this “boring” pre-production out of the way, I feel confident getting to work on this project. By the time I will write up another chapter in this series, I would like to have the following done:
- Think of a name for the engine
- Setup a repository for the project
- Prepare (at least stub) handlers for all the UCI commands
- Implement the Board Representation part of the chess engine
Seems like I have my work cut out for me, and I can’t wait to roll up my sleeves and getting my hands dirty by actually starting to implement this project. Hopefully I’ll have something worth sharing again soon.
In the meantime, thank you for reading the first part in this series! I hope that you enjoyed it, or that it at least gave you a brief look into the problem space of chess programs and provided you with enough information and further reading to be able to start a similar project of your own!
Until the next chapter, thank you again for your time and take care!