I had flu last weekend and I've looked for something to take advantage of the long stay at home. Eventually I took back some of my old work done on chess engines as I've been thinking recently about making some experiments on them again.
I've started downloading the source of my old smash (the page is in only in Italian, sorry!), a chess engine I wrote many years ago, then I've read it to figure out where to put my hands on: what a mess!
Smash's last changes were made to implement an unfortunate parallel search algorithm that affected negatively the codebase (that probably was not that clean from the begin).
What was lost and what wasn't
Reading old code (I think the last changes to smash were made 6 years ago) was an interesting activity, here are some of my thoughts about it:
- My English was quite poor at that time (well, it is not that better now) and some of the comments in the code look funny
- At that time Github and Bitbucket didn't exist or were not that popular like nowadays. Sourceforge existed and was quite popular, still I believe there was an higher friction for people to use it for hosting software made for hobby. The result is that the source repository is lost and I had to download the tarball snapshot, making it very hard to revert the parallel algo changes.
- Even if I was able to find the old repository, at that time my VCS of choice was either cvs or svn. Commits in centralized VCS are usually less frequent than commits in distributed VCS like git or mercurial, because require internet connection and are generally a slow operation. This would have made harder to revert the code isolating the changes I wanted to exclude and keeping the good stuff like bugfixes and improvements.
- The code compiles and works also on OSX!
- There is a function of over 400 lines... I'll never do it again, promise!
- I had lots of free time in 2004...
- I couldn't find some tools written in Python I used for testing and for a simple tuning of the engine.
From the point of view of the code architecture I couldn't ignore the hundreds of magic tables used for the heuristics. Chess engines usually come with many precomupted tables of numbers. As of a rule of thumb in software engineering we should separate generated code from written code. Unluckily in smash codebase magic tables are in the same sources were human written code is. I think that some of them were even tuned manually changing some entries by hand instead of changing the code used to generate the tables. This makes the tables and the numbers even more magic than they actually should be.
The README file format is totally ugly. I guess I had a lot of fun writing it and designing the structure and the decorations. reStructuredText and Markdown were not that popular at that time. (Please note both of them were existing for a long time when last version of smash was released).
The longer way
Even if I wasn't annoyed by reading the old .h and .cpp files, I've thought that for the experiments I wanted to make I didn't need a whole chess engine. I could write a simpler one from scratch.
So I've took back another shorter codebase written some weeks ago in the train that included a small Python class to represent a chess board, I've cleaned it up, written some tests and eventually added the features I needed.
Now I've got a skeleton of a library that could be used to develop a chess engine in Python. I've put the code on Github, be free to have a look at it.
What's the project behind this?
I've spent some years of my life studying chess engines, I've decided to dust my old shelves and write some posts of this blog about them while developing this new one.
I'll start with some basic posts about general chess engine architecture and then explain some of the most common algorithms, heuristics and tricks used in chess engine development. As I've said I also have planned to make some experiments, so I'll be happy to share the results here.
Stay tuned.