5

This may well be too broad of a question. I'm currently in the process of programming a chess engine, but this is difficult for me as I'm not actually that good of a chess player. I'm having trouble coming up with 'rules' that can analyze a board and give a positive/negative score. Currently I have the following:

  • penalty for knights on edge
  • bonus for further developed pieces
  • bonus for farther advanced pawns (closer to promotions)
  • different score for kings in the endgame
  • bonus if the player has the bishop pair
  • bonus if castled
  • assess layout as per these tables (some scrolling required)

I have access to all the information about a game; and functioning move validation. The part I'm getting stuck on is coming up with more of these 'rules' that make the analysis engine better.

3

I think the best way to get yourself acquainted with chess evaluation schemes, is just by looking up the documentations of some of open source (or GNU) chess engines out there, after all such questions have been asked/tackled for many years now, and there are many good answers out there that you need to explore before coming up with your own (hence all the variety of good engines today).

Of course as things stand today, most of chess engines rely on evaluation systems that are (for the most part) heuristics-based. What is important before getting into some of the possibilities is to note that, there's no one single evaluation function that would solve chess, so what we really need (all we can hope for really) is a well weighted combination of many different evaluations, some of the main (usually mentioned) ones:

  • Pawn structure: if your engine is capable of noticing connected pawns, doubled pawns, blocked pawns, isolated pawns etc, then you're already doing pretty good.

  • Material: Probably the easiest part to implement, just get a total piece count for both sides and compare. Then compare by piece-type (how many bishops vs. how many knights etc)

  • King safety: Again pretty easy to implement evaluators such as: open lines/diagonals heading towards the king, likelihood of checks (within next 2-3 moves for simplicity), rights to castle, and so on.

  • Individual piece evaluation: For each piece type, you should have a different evaluator, that measures its activity, e.g. by counting different possible moves the piece can make (total of 8 for the most active knight as example), openness of diagonals for bishops (also whether own-piece is blocking it or opponent piece, should be weighted differently), available squares for queen etc.

  • Mobility: A simpler version of the above if you will, i.e. just count the number possible moves each piece can make, and try to maximize it, i.e. the evaluator should add positively to the total evaluation function if from one move to next one (or more) of your pieces is gaining additional move possibilities.

  • Piece exposure: Just count how many of your pieces can be captured within a well defined ply (within next 2 moves e.g.). Such evaluators bring dynamics into your whole evaluation scheme, as based on them, you will then re-prioritize each of the previously mentioned evaluators (by re-distributing the weights initially assigned), you see it's a lot of fun implementing a chess engine ;)

  • Central control: Can be simple or very complex, the simple approach would be: defining a set squares that define what you call "center", then count how many pieces can potentially jump to those squares within next 1-2 moves, such approach should give you an estimate for central control.

  • More advanced features would be: Tempo considerations, to define such concepts in your engine, you need to have already covered all the basic evaluators. Connectivity or coordination of pieces come next, and so on.

Hope the few mentioned elements give you some rope already, of course there's a long way to go, but it's really important to first find out what's already been done and tried before you stumble on your own ideas. There's a must-check website for programming chess engines, have a look, you'll find tons of ideas and implementation suggestions: chessprogramming on wikispaces. If you need further clarifications, don't hesitate! Have fun implementing!

| improve this answer | |
  • 1
    Very clear explanations, +1. – user4266 Apr 20 '15 at 13:11
0

The basic problem with your evaluations is that they make very little allowance for the dynamic features of the position like where are the opponent's pieces, especially king, and what stage of the game - opening, middle game, end game - although you do mention this briefly it is much more important.

Here are some additional factors, although these are generalizations which are not 100% strict rules:

1) In the opening the queen and rooks should rarely venture out into the middle of the board. In the middle game they are best operating from behind their lines but on open files and diagonals or ones which will soon be opened, by pushing and / or exchanging a pawn for instance. In the endgame they are better attacking enemy pieces and pawns and especially the king rather than defending their own.

2) Rooks are much stronger if they are connected (true in all phases of the game) and can be deadly if they are connected close to the opponent's king.

3) Established / supported knights and bishops close to the enemy king are very strong.

4) Doubled pawns are weak

5) Isolated pawns are weak

6) Two pawns standing side by side are generally stronger / more of a threat than where one pawn is supporting the other.

7) Pawns, in the middle game, which are close to the enemy king are much stronger than just the extra you give them for being advanced.

8) Knights are stronger than bishops if they have access to good center squares from which they can not be easily evicted.

9) Bishops are weak if the center is badly blocked and they have little freedom of movement (not many squares they can go to)

10) Weaker pieces, like bishops and rooks, are stronger if they point at stronger enemy pieces like king or queen even though there are pieces in the way. It makes it more dangerous for the enemy to move any of his pieces and you may be able to create threats to move your pieces out of the way.

I'm sure there are many more such general rules / guidelines which could be given, but you get the idea.

One crude way you could implement some of these ideas would be to have flags for these features which apply to the different pieces to which you give values if they are true.

| improve this answer | |
  • Actually - I do have access to all the information about a game (including the position of all the pieces, whose turn it is, and what 'phase' the game is in). The only problem I may have is that it's been very hard to decide how to classify a game to decide what phase it's in. Currently, I use a mixture of how much material is on the board (as soon as a piece is taken the opening is over) and how many moves have been made (>=6 fullmoves is the opening). – mishaturnbull Feb 27 '15 at 14:07
0

Have you considered the fundamental advantages such as force, time, space (material is the other but you have that covered)?

Force= more pieces in an area of the board (usually an attacking force on a weak king)

Time= measured in tempo (or tempi plural) think wasted moves i.e.: a poorly placed piece being kicked by pawns. etc. a loss of time which often in early stages means poor development.

Space= number of squares beyond the frontier line (the invisible line dividing your opponents side of the board from yours) that your pieces control. compare and contrast space count.

misc extra chess is a game of balance, a mismatch in control of a color of squares leads to a "complex" or weakness. i.e.: all of your pieces are attacking light squares, or your king is castled with the g pawn pushed but no fianchettoed bishop to cover the squares leaving a weakness.

also, open vs closed vs dynamic positions and the type of minor piece a side has...knights tend to prefer closed positions, bishops need open diagonals, just like rooks are happy on open files.

| improve this answer | |
  • How would you define 'force'? Keep in mind, programs can't just look at a board and say "Oh there's a lot of white pieces in the center, that's good!". For one it doesn't know what to define as the center (although this could be easily implemented with a good definition of the center). Totalling the number of black/white pieces within that area would be fairly simple. Regarding temp - so I should make the engine always put the piece where it wants it the first time and not sit around and get it there slowly or are there times when that's good? – mishaturnbull Feb 27 '15 at 21:50
  • Force is a material advantage in an area of the board. for example if your opponent is poorly developed and you have already engaged in an attack and sacrificed a piece. you may be behind in material but have an advantage because of piece activity. comparing the pieces, you can still have an advantage with fewer over all pieces if more pieces of your pieces are engaged in the attack. to picture tempo, think about how gambits work. they sacrifice a pawn or two to get an advantage in force and time. when the opponent captures, he moves the same piece twice in the opening, thus losing time – asdfqwert Feb 28 '15 at 4:05
  • so, moving a piece more than once in the opening before all of the pieces are developed results in a loss of time. – asdfqwert Feb 28 '15 at 4:09
  • another big one is space...in addition to space count, controlling more space when more pieces are on the board leaves the opponent with fewer safe squares to maneuver on and occupy. so, with more controlled squares, your program should favor avoiding trades and keeping pieces on the board. Likewise with less space it should look to trade. I think Brian makes a really good point in his answer. there are a lot of "dynamic features" in chess positions that aren't just hard fast rules. this is why humans can still beat computers, its not purely mathematical...there's art too. – asdfqwert Feb 28 '15 at 4:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.