The purpose of the site is to provide a “watch over the shoulder” view of creating a chess engine.  Hopefully, over time, we will see an engine develop (Maverick) which can rip the guts out of any human player!

The principles I’m adhering to are as follows:

  • Development Language: The engine will be developed in C.  This is not my “mother tongue” (which is Delphi – IMO still the best language for Win 32 / 64 development).  Nevertheless, the modern C compilers are the best at creating a fast executable.  C is also the most portable.
  • Bug Free: The #1 priority is to ensure Maverick is bug free. Monarch, my previous engine is extremely stable, and it’s something I’m proud of.  It really is no use having the world’s strongest engine if it’s always crashing.
  • Style of Play: In a word – aggressive!  In my experience people don’t want a dull boring engine which grinds out rook vs. knight tablebase wins in 153 moves.  The aim will be to create an engine which will play aggressive chess.
  • Strength:  Let’s face it, today’s best engines are far better than any human.  They are playing in the 3100+ ELO range.  At one stage I thought I may develop an engine with the aim of being the best.  I think that time has passed.  The emphasis has shifted to playing style.  So Maverick is aiming to be the most entertaining chess engine.  Having said that, I’d like Maverick to be at least 2500 ELO (i.e. Grandmaster level), and I’d be delighted if it reached the dizzy heights of 3000 ELO.
  • UCI Compatibility: I’m a big fan of the UCI protocol.  It’s a really well thought out protocol and one which I’d like to fully support.  My aim will be to eventually support all aspects the UCI protocol, including multi-pv and reduced strength.
  • Opening Book:  I’m not sure how easy it will be to implement, but I’m intending to make Maverick read Polyglot opening books
  • Cloning:  I really have no interest in clones (or discussing clones).  I get the idea of “standing-on-the-shoulders-of-giants” and all that, but for me writing a chess program is about creating something new, not tweaking someone else’s creation.  I know it’s more difficult but as I always say to my kids, “why do we do difficult things; answer – so we feel good about ourselves“!  So Maverick will not be a clone.  It will not contain any “copy & paste” code. Nevertheless, it will undoubtedly contain some *idea* from other sources (e.g. Wiki Chess Programming).
  • License:  Although I have nothing against it, I’m not a big fan of open source.  However, in today’s environment I think I really need to go open source if Maverick is to regarded as an original creation.  Also, with today’s super strong engines, I doubt I have any truly original ideas which are worth hiding (although I do some tricks I’d like to try out).  So Maverick’s code will be available, but it will not be GPL (or any other user license), and I will retain the copyright.
  • Coding Style: Maverick’s code will be as simple as possible but no simpler.  I marveled at Fabien Letouzey’s code and he has certainly influenced me.  I’ll try to be as defensive as possible and write test procedures wherever possible.  I have also learnt (the hard way) to minimize color dependent code.
  • Platforms: I’m aiming for Windows 32 / 64 as the main platforms for Maverick.  Others may follow later but quite frankly I don’t have the experience to make a Linux or Mac executable.

Best regards – Steve Maughan – March 2013

June 2013 Update:

Search:

I haven’t coded the search yet but here’s what I’m aiming for:

  • Maverick’s quiescent search will be have two stages.  The first stage will be all checks and all captures, followed by the second stage which will be SEE positive and neutral captures.  The idea is to make the QSearch as solid as reasonably possible.  Hopefully this will enable more risky pruning closer to the root (with any errors caught by the QSearch).
  • No futility pruning.  This did help Monarch but I’ve never really liked it.  The nodes which are pruned are would normally lead to a cutoff quite quickly anyway.
  • Very few extensions.  Ten years ago I was obsessed with extensions.  I now see reductions as the way to go.

Evaluation:

  • I’m aiming for the first version to have a reasonably good evaluation (e.g. mobility, king safety and passed pawn evaluation)

Testing:

  • I did do tests on Monarch, but not many by today’s standards.  For Maverick I’m planning to set up a dedicated testing environment.  I’ll then only add code when it definitely better than current version.