Afterword

ABC started with a simple idea: build a chess engine that is small enough to understand, but complete enough to actually play chess. What you have seen throughout this book is the result of following that idea all the way from a 0x88 board to a working UCI engine.

We began with the basic structure of the project and gradually built the pieces that make a chess engine possible: board representation, piece encoding, move generation, attack detection, move making, position restoration, perft testing, hashing, evaluation, move ordering, quiescence search, negamax, iterative deepening, time management, and finally the UCI communication layer.

None of these components is particularly mysterious on its own. The interesting part is seeing how they fit together. A move generated by the move generator becomes an encoded integer. That integer can be played by make_move(), tested for legality, searched recursively, evaluated at the leaves, printed as UCI text, and eventually sent back to the GUI as the engine's best move.

This Is Not Really a Tutorial

I would not describe this book as a traditional chess-programming tutorial. It is closer to documentation written alongside the source code. The goal was not to take you through a perfectly planned curriculum or present the theoretically strongest way of implementing every algorithm. Instead, the goal was to open ABC and explain what the code is doing and, more importantly, why it is structured this way.

That distinction matters. ABC deliberately chooses simplicity in many places where a stronger engine would choose performance. The move generator is straightforward. Positions are copied rather than incrementally undone. Hashes are recalculated from scratch. Move sorting uses a simple algorithm. The evaluation function is intentionally modest. These choices are not accidents. They make the engine easier to understand, modify, break, fix, and learn from.

I wish I had a book like this when I started chess programming nearly ten years ago. Back then, there was plenty of information available, but connecting all those individual ideas into one complete engine was a very different challenge. You could learn what alpha-beta was, what a bitboard was, what perft was, or what a transposition table did—but understanding how an entire chess engine fits together is another matter entirely.

That is what I hope ABC provides: not necessarily the fastest path to a powerful engine, but a clear path toward understanding one.

Chess Programming Takes Time

There is another lesson that I think is worth emphasizing: chess programming takes patience.

It is easy to look at a finished engine and imagine that the author simply knew how everything worked. The reality is very different. Chess is full of small rules, edge cases, interactions, and bugs that can hide for a surprisingly long time. A single incorrect square index can break castling. A missing legality check can produce illegal moves. A small mistake in search can make the engine throw away a winning move. And sometimes the program simply crashes, leaving you staring at the debugger wondering what on earth happened.

My own path was certainly not quick. It took me three years back in the day to write my first bug-free move generator that could finally pass a complete perft test. Three years may sound ridiculous for something that can eventually fit into a relatively small amount of C code, but that is exactly the point: understanding chess programming deeply takes time.

There were bugs, rewrites, experiments, wrong ideas, and plenty of moments where something that seemed obvious turned out not to be obvious at all. Eventually, though, the pieces started fitting together.

So if your engine is currently producing illegal moves, crashing during search, failing perft, or playing moves that make absolutely no sense, don't assume you are incapable of doing this. Keep going. Debug the position. Print the board. Compare perft counts. Simplify the code. Test one component at a time. Chess programming rewards persistence.

If you keep working at it, eventually things start to become clear.

A Hobby Built in Free Time

Chess programming is also a rather unusual hobby. It requires a considerable amount of time and effort, but for most people it is not something that pays the bills. There is no commercial team behind ABC, no company funding the development, and no army of engineers working on the code.

So, yes—donations are very much appreciated, my PayPal is maksymkorzh@gmail.com.

However, I intentionally made this book free because I strongly believe that both knowledge and code should be freely available. In my view, what we are truly paid for is not the knowledge itself, but our ability to solve someone’s problem and turn that knowledge into something useful.

This book represents many hours of programming, debugging, testing, writing, explaining, and thinking about how to make complicated ideas understandable. The engine itself may be small, but getting from an empty project to a complete playable chess engine is a substantial undertaking.

If this book helped you understand something that previously seemed confusing, saved you hours of debugging, gave you the motivation to start your own engine, or simply provided an enjoyable way to learn how chess software works, consider supporting the project. Even a small donation is meaningful. It is a direct way of saying that the time spent building and documenting this project was worthwhile, and it helps make it possible to keep working on projects like this.

Where to Go From Here

ABC is not the end of the road. It is a starting point.

Once you understand the architecture presented here, there is an enormous amount left to explore. You can improve the evaluation function, experiment with more sophisticated move ordering, add transposition tables, implement principal variation search, late move reductions, null-move pruning, aspiration windows, better time management, opening books, endgame knowledge, NNUE evaluation, bitboards, parallel search, and countless other ideas.

But now those techniques have somewhere to go. They are no longer isolated concepts from a chess-programming article. You have a complete engine in front of you, and you know where each new idea belongs.

That is perhaps the most important thing I wanted this book to accomplish.

ABC is not intended to be the strongest chess engine. It is intended to be understandable. And if, after reading it, you feel ready to open your editor and start writing your own engine, then the project has already succeeded.

Thank you for reading, experimenting, debugging, and hopefully enjoying the journey.