Difference between revisions of "Getting Started"

From Chessprogramming wiki
Jump to: navigation, search
(delete mentions of CECP)
(UCI and Time Management: Add link to uci subset)
 
(2 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
Just '''getting started''' with a new engine? Congratulations! You are in for a lot of fun, but there is a considerable amount of work ahead of you.
 
Just '''getting started''' with a new engine? Congratulations! You are in for a lot of fun, but there is a considerable amount of work ahead of you.
  
The foundation of a chess engine is the [[Board Representation|board representation]]. This is the "back end" for the chess engine, which controls how it keeps track of the board and the rules of the game. The '''very first step''' to writing a chess engine is to write a complete, [[Engine Testing#bugs|bug]] free board representation that knows '''every''' rule of chess. While this can sometimes be a pain, especially implementing the more complicated rules such as [[Castling|castling]] and [[Repetitions|repetition draws]], it is the backbone of the chess engine, and your engine will not get far without it.
+
==Building the Foundations==
  
When writing an engine, it is '''extremely''' important to write bug free code. The best strategy when starting a new engine is to create a debugging framework under it so that every single piece of code gets tested, no matter how simple it looks. Many experienced engine authors have ended up rewriting their engines because they have become unmanageable due to bugs.
+
The foundation of a chess engine is the [[Board Representation|board representation]]. This is the "back end" for the chess engine, which controls how it keeps track of the board and the rules of the game. The '''very first step''' to writing a chess engine is to write a complete, [[Engine Testing#bugs|bug]] free board representation that knows '''every''' rule of chess. While this can sometimes be a pain, especially implementing the more complicated rules such as [[Castling|castling]] and [[Repetitions|repetition draws]], it is the backbone of the chess engine, and your engine will not get far without it. Debugging tests such as [[Perft]] can be useful in verifying correctness of move generation.
  
Once you have a nice solid foundation ready, you are ready to start learning about the fun stuff: [[Search]] and [[Evaluation]]. These are the "brains" behind a chess engine; what allows it to pick a good move. Note that it is also '''extremely''' important to test every one of your search features. The most common and scientific way is to do [[Sequential Probability Ratio Test|SPRT]] testing.
+
When writing an engine, it is important to write bug free code. The best strategy when starting a new engine is to create a debugging framework under it so that every single piece of code gets tested, no matter how simple it looks. Many experienced engine authors have ended up rewriting their engines because they have become unmanageable due to bugs.
  
You'll probably also want to connect your program to a [[GUI]] (Graphical User Interface). You are in luck, though; you don't have to write your own. It is only necessary to understand some basic text commands in order to communicate with the many available GUIs today. Most engines use the [[UCI|Universal Chess Interface]] for this communication.
+
==Search and Evaluation==
 +
 
 +
[[Search]] and [[Evaluation]] are the "brains" behind a chess engine: they are what allows it to pick a good move. A [[Negamax]] framework with [[Iterative Deepening]] and a pure material evaluation is a common starting place for a chess engine. But before you work further on Search and Evaluation, it is very important to prepare your engine for proper testing.
 +
 
 +
==UCI and Time Management==
 +
 
 +
A working [[Time Management]] is important in that it both enables you to test your engine and makes it possible for the engine to compete and play under time control. The simplest, and surprisingly effective, way to manage time is to cap the search time at remaining time/20 + increment/2, after which the search aborts.
 +
 
 +
[[UCI]] (Universal Chess Interface) is the standard protocol for engine communication. Not only does it allow you to connect your program to a [[GUI]] (Graphical User Interface), but it also enables proper and scientific testing of your engine using tools such as [[OpenBench]], [[cutechess-cli]] and [[fast-chess]]. Only a [[Sequential_Probability_Ratio_Test#Minimum_UCI_Requirements|small subset of UCI]] needs to be supported to facilitate these testing.
 +
 
 +
==Scientific Development==
 +
 
 +
No matter what your goals are in writing your engine, it is '''extremely''' important to test your engine in a scientific and rigorous way.
 +
 
 +
Most modern engines use self-play [[SPRT]] to determine the validity of a patch. SPRT is commonly regarded as the best and most efficient way to reach statistical certainty on whether a modification gains Elo or not. Many new engine developers get stuck at the lower end of rating lists due to no or improper testing.
 +
 
 +
==Useful Resources==
  
 
If you want ideas and see how other programmers have done things, take a look at [[Search Progression]] and some of the [[:Category:Open Source|Open Source Engines]]. These can be very helpful when translating rather vague algorithms into specific data structures and code. Just be careful, and don't copy the code and say it is your own! [[:Category:Clone|Clones]] are frowned upon by the computer chess community as a whole.
 
If you want ideas and see how other programmers have done things, take a look at [[Search Progression]] and some of the [[:Category:Open Source|Open Source Engines]]. These can be very helpful when translating rather vague algorithms into specific data structures and code. Just be careful, and don't copy the code and say it is your own! [[:Category:Clone|Clones]] are frowned upon by the computer chess community as a whole.
  
It is also a very good idea to join some of these [[Computer Chess Forums]]. The chess programming community is very friendly and will help you out with personalized advice. We are always happy to accept new members!
+
It is also a very good idea to join some of these [[Computer Chess Forums]] or [[Discord Channels]]. The chess programming community is very friendly and will help you out with personalized advice. We are always happy to accept new members!
  
 
Some other good computer chess references can be found in [[Recommended Reading]].
 
Some other good computer chess references can be found in [[Recommended Reading]].

Latest revision as of 23:47, 3 August 2024

Home * Getting Started

Just getting started with a new engine? Congratulations! You are in for a lot of fun, but there is a considerable amount of work ahead of you.

Building the Foundations

The foundation of a chess engine is the board representation. This is the "back end" for the chess engine, which controls how it keeps track of the board and the rules of the game. The very first step to writing a chess engine is to write a complete, bug free board representation that knows every rule of chess. While this can sometimes be a pain, especially implementing the more complicated rules such as castling and repetition draws, it is the backbone of the chess engine, and your engine will not get far without it. Debugging tests such as Perft can be useful in verifying correctness of move generation.

When writing an engine, it is important to write bug free code. The best strategy when starting a new engine is to create a debugging framework under it so that every single piece of code gets tested, no matter how simple it looks. Many experienced engine authors have ended up rewriting their engines because they have become unmanageable due to bugs.

Search and Evaluation

Search and Evaluation are the "brains" behind a chess engine: they are what allows it to pick a good move. A Negamax framework with Iterative Deepening and a pure material evaluation is a common starting place for a chess engine. But before you work further on Search and Evaluation, it is very important to prepare your engine for proper testing.

UCI and Time Management

A working Time Management is important in that it both enables you to test your engine and makes it possible for the engine to compete and play under time control. The simplest, and surprisingly effective, way to manage time is to cap the search time at remaining time/20 + increment/2, after which the search aborts.

UCI (Universal Chess Interface) is the standard protocol for engine communication. Not only does it allow you to connect your program to a GUI (Graphical User Interface), but it also enables proper and scientific testing of your engine using tools such as OpenBench, cutechess-cli and fast-chess. Only a small subset of UCI needs to be supported to facilitate these testing.

Scientific Development

No matter what your goals are in writing your engine, it is extremely important to test your engine in a scientific and rigorous way.

Most modern engines use self-play SPRT to determine the validity of a patch. SPRT is commonly regarded as the best and most efficient way to reach statistical certainty on whether a modification gains Elo or not. Many new engine developers get stuck at the lower end of rating lists due to no or improper testing.

Useful Resources

If you want ideas and see how other programmers have done things, take a look at Search Progression and some of the Open Source Engines. These can be very helpful when translating rather vague algorithms into specific data structures and code. Just be careful, and don't copy the code and say it is your own! Clones are frowned upon by the computer chess community as a whole.

It is also a very good idea to join some of these Computer Chess Forums or Discord Channels. The chess programming community is very friendly and will help you out with personalized advice. We are always happy to accept new members!

Some other good computer chess references can be found in Recommended Reading.


Up one level