Help with this chess statics
Author
/* Hello i just developed a chess engine, it can beat me on several games(but then you don''t know my strength do you!), however Gnuchess outclasses it on several games say 5 out of 6 games, i suspect the main problem is with this static values for the piece and their locations on the board, can''t anyone suggest better values or additions, like King_proximity an so on*/
DOUBLED_PAWN_PENALTY 10
ISOLATED_PAWN_PENALTY 20
BACKWARD_PAWN_PENALTY 8
PASSED_PAWN_BONUS 20
ROOK_SEMI_OPEN_FILE_BONUS 10
ROOK_OPEN_FILE_BONUS 15
ROOK_ON_SEVENTH_BONUS 20
/* the values of the pieces */
int piece_value[6] = {
100, 300, 300, 500, 900, 0
};
/* These are the values added to the material value of the piece based on the
location of the piece. */
int pawn_position_and_Squar[64] = {
0, 0, 0, 0, 0, 0, 0, 0,
5, 10, 15, 20, 20, 15, 10, 5,
4, 8, 12, 16, 16, 12, 8, 4,
3, 6, 9, 12, 12, 9, 6, 3,
2, 4, 6, 8, 8, 6, 4, 2,
1, 2, 3, -10, -10, 3, 2, 1,
0, 0, 0, -40, -40, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0
};
int knight_position_and_squar[64] = {
-10, -10, -10, -10, -10, -10, -10, -10,
-10, 0, 0, 0, 0, 0, 0, -10,
-10, 0, 5, 5, 5, 5, 0, -10,
-10, 0, 5, 10, 10, 5, 0, -10,
-10, 0, 5, 10, 10, 5, 0, -10,
-10, 0, 5, 5, 5, 5, 0, -10,
-10, 0, 0, 0, 0, 0, 0, -10,
-10, -30, -10, -10, -10, -10, -30, -10
};
int bishop_position_and_squar[64] = {
-10, -10, -10, -10, -10, -10, -10, -10,
-10, 0, 0, 0, 0, 0, 0, -10,
-10, 0, 5, 5, 5, 5, 0, -10,
-10, 0, 5, 10, 10, 5, 0, -10,
-10, 0, 5, 10, 10, 5, 0, -10,
-10, 0, 5, 5, 5, 5, 0, -10,
-10, 0, 0, 0, 0, 0, 0, -10,
-10, -10, -20, -10, -10, -20, -10, -10
};
int king_position_and_squar[64] = {
-40, -40, -40, -40, -40, -40, -40, -40,
-40, -40, -40, -40, -40, -40, -40, -40,
-40, -40, -40, -40, -40, -40, -40, -40,
-40, -40, -40, -40, -40, -40, -40, -40,
-40, -40, -40, -40, -40, -40, -40, -40,
-40, -40, -40, -40, -40, -40, -40, -40,
-20, -20, -20, -20, -20, -20, -20, -20,
0, 20, 40, -20, 0, -20, 40, 20
};
int king_endgame_position_and_squar[64] = {
0, 10, 20, 30, 30, 20, 10, 0,
10, 20, 30, 40, 40, 30, 20, 10,
20, 30, 40, 50, 50, 40, 30, 20,
30, 40, 50, 60, 60, 50, 40, 30,
30, 40, 50, 60, 60, 50, 40, 30,
20, 30, 40, 50, 50, 40, 30, 20,
10, 20, 30, 40, 40, 30, 20, 10,
0, 10, 20, 30, 30, 20, 10, 0
};
I think the problem you are having is that the values do not reflect the context of the game.
for example, a certain position may be considered ''prime'', but it''s no good if to the actual game in progress it''s not a useful move (has no strategic or operational value).
I think you need to consider a system that dynamically weights the board to reflect the context of the current game in progress.
for example, a certain position may be considered ''prime'', but it''s no good if to the actual game in progress it''s not a useful move (has no strategic or operational value).
I think you need to consider a system that dynamically weights the board to reflect the context of the current game in progress.
Hey there,
That looks like code from Tom Kerrigan''s chess engine :-). I developed my own chess engine using his code as a reference, so I can perhaps give you a couple of pointers (though I don''t think my program ever came close to beating GNUchess - that program is very strong)
First, the guy who posted about dynamic board evaluation is right - it''s a good thing, especially later in the game. Static evaluations can be good, since they are super-cheap to compute and usually accurate at the beginning of the game. As the game progresses, however, they can lose meaning (or context, I suppose you could say). One of the features I added to my engine was an evaluation for pawn chains - long chains of pawns generally lead to strong positions at any point of the game. Such an evaluation really helped my program compete, especially against computers, who have trouble evaluating long-term strategic assets (as opposed to tactical combinations).
Second, the Kerrigan engine is kind of slow. On any machine, Crafty manages to search 3-4 times as many positions in the same amount of time. With a good ab-pruning algorithm, this can result in an extra ply of search, roughly equal to 200 ELO points (according to Hsu, one of the Deep Blue guys). Crafty acheives most of this speed by using bitboards instead of an array-based board representation, like Kerrigan''s engine does. I''ve profiled the Kerrigan engine and it spends a huge amount of time in the move generation step (it''s something like 98%). This code can definately be optimized. You can also do things like remember where all the pieces are - Kerrigan''s engine will hunt for them by looking through all the board positions one by one - Look at the function that tests if a king is in check - it hunts through all 64 squares until it finds the king. Why not cache the kings position instead? Believe it or not, doing this results in an extra 8,000 moves searched per second on a 500 Mhz machine.
You might be interested in my chess programming webpage, where I outline the development of my chess engine as I add/remove features and document it''s play strength as a result of those changes (there is also source code).
My engine, Fimbulwinter, tops out at around 2300 ELO. It''s winboard compatible and I used to run it on ICC alot. So if you''re engine is already beating GNUchess, maybe it''s already better than mine and most of my advice was worthless :-)
http://www.stanford.edu/~jjshed/chess
Good luck!
----------------------------------------
Let be be finale of seem, seems to me.
----------------------------------------
Coding:
http://www.stanford.edu/~jjshed/coding
Miscellany:
http://www.stanford.edu/~jjshed
That looks like code from Tom Kerrigan''s chess engine :-). I developed my own chess engine using his code as a reference, so I can perhaps give you a couple of pointers (though I don''t think my program ever came close to beating GNUchess - that program is very strong)
First, the guy who posted about dynamic board evaluation is right - it''s a good thing, especially later in the game. Static evaluations can be good, since they are super-cheap to compute and usually accurate at the beginning of the game. As the game progresses, however, they can lose meaning (or context, I suppose you could say). One of the features I added to my engine was an evaluation for pawn chains - long chains of pawns generally lead to strong positions at any point of the game. Such an evaluation really helped my program compete, especially against computers, who have trouble evaluating long-term strategic assets (as opposed to tactical combinations).
Second, the Kerrigan engine is kind of slow. On any machine, Crafty manages to search 3-4 times as many positions in the same amount of time. With a good ab-pruning algorithm, this can result in an extra ply of search, roughly equal to 200 ELO points (according to Hsu, one of the Deep Blue guys). Crafty acheives most of this speed by using bitboards instead of an array-based board representation, like Kerrigan''s engine does. I''ve profiled the Kerrigan engine and it spends a huge amount of time in the move generation step (it''s something like 98%). This code can definately be optimized. You can also do things like remember where all the pieces are - Kerrigan''s engine will hunt for them by looking through all the board positions one by one - Look at the function that tests if a king is in check - it hunts through all 64 squares until it finds the king. Why not cache the kings position instead? Believe it or not, doing this results in an extra 8,000 moves searched per second on a 500 Mhz machine.
You might be interested in my chess programming webpage, where I outline the development of my chess engine as I add/remove features and document it''s play strength as a result of those changes (there is also source code).
My engine, Fimbulwinter, tops out at around 2300 ELO. It''s winboard compatible and I used to run it on ICC alot. So if you''re engine is already beating GNUchess, maybe it''s already better than mine and most of my advice was worthless :-)
http://www.stanford.edu/~jjshed/chess
Good luck!
----------------------------------------
Let be be finale of seem, seems to me.
----------------------------------------
Coding:
http://www.stanford.edu/~jjshed/coding
Miscellany:
http://www.stanford.edu/~jjshed
4 questions
How many nodes/second is your engine searching?
How many nodes/second is GNU Chess searching?
What depth is your engine typically searching to?
What depth is GNU Chess typically searching to?
The answer to these questions could indicate that your problem is within your evaluation, or they could suggest that your problem is not within your evaulation.
Assuming your move generator is not broken..
If you are searching more nodes/second than GNU Chess but are getting less depth, than your move ordering is inferior to GNU Chess''s.
It cannot be stressed enough that move ordering is quite possibly the most important part of an alphabeta chess engine - you need to find a move that causes a cuttoff as fast as possible. The ''worst case'' move ordering reduces alpha/beta to a regular min/max search. The ''best case'' move ordering is equivilent to a binary search and is the dream of every engine author.
- Rockoon
How many nodes/second is your engine searching?
How many nodes/second is GNU Chess searching?
What depth is your engine typically searching to?
What depth is GNU Chess typically searching to?
The answer to these questions could indicate that your problem is within your evaluation, or they could suggest that your problem is not within your evaulation.
Assuming your move generator is not broken..
If you are searching more nodes/second than GNU Chess but are getting less depth, than your move ordering is inferior to GNU Chess''s.
It cannot be stressed enough that move ordering is quite possibly the most important part of an alphabeta chess engine - you need to find a move that causes a cuttoff as fast as possible. The ''worst case'' move ordering reduces alpha/beta to a regular min/max search. The ''best case'' move ordering is equivilent to a binary search and is the dream of every engine author.
- Rockoon
Telamon's advice is very good. Speeding up your program (move generation / evaluation) is ALWAYS a smart thing for game trees.
A few comments:
Search depth. GNUChess could be searching deeper than your program. If you havn't already, look in to transposition tables. Just by having hash tables you open your game up to many new possibilites, not to mention potential speed boosts.
Game 'knowledge'. GNU Chess might be evaluating the board in a more sophisticated manner. I know in my own game I developed a rather lengthy set of rules based on testing against a human player. Some of these rules would become enabled / disabled as the game progressed. Smart pawn play can make a huge difference. The computer typically sucks at this.
End-game Tables. Your program probably doesn't support end-game tables. GNUChess probably does. What this means is that if there are 5 or less pieces on the board, GNUChess will have 'precomputed' paths it can take. This would almost certainly spell doom for your program.
This may be minor but I don't neccesarily agree with your pawn_position values, and I don't think your rules are dynamic enough.
1. A pawn chain near the left edge of the board is, IMHO, more valuable than maintaining one near the center, especially as the number of pieces on the board dwindle.
2. Later in the game an advanced pawn can be very valuable. You're program may not be able to look ahead far enough to realize that, so you should bias the evaluation as the game progresses.
3. I don't think your rewarding your pieces for putting pressure on the enemy king.
4. Worse than a two pawns on a file is three pawns on a file. If given the choice, the computer should be biased towards doubling up rather than tripling up.
5. Knights in the center only holds true during the beginning of the game IMHO. As the game progress you could take away the positive bias of this.
6. Do you award points for mainting castling rights?
7. Do you have an opening book?
Congrats on getting a chess engine running.
Good luck,
Will
[edited by - RPGeezus on March 29, 2004 4:13:24 PM]
A few comments:
Search depth. GNUChess could be searching deeper than your program. If you havn't already, look in to transposition tables. Just by having hash tables you open your game up to many new possibilites, not to mention potential speed boosts.
Game 'knowledge'. GNU Chess might be evaluating the board in a more sophisticated manner. I know in my own game I developed a rather lengthy set of rules based on testing against a human player. Some of these rules would become enabled / disabled as the game progressed. Smart pawn play can make a huge difference. The computer typically sucks at this.
End-game Tables. Your program probably doesn't support end-game tables. GNUChess probably does. What this means is that if there are 5 or less pieces on the board, GNUChess will have 'precomputed' paths it can take. This would almost certainly spell doom for your program.
This may be minor but I don't neccesarily agree with your pawn_position values, and I don't think your rules are dynamic enough.
1. A pawn chain near the left edge of the board is, IMHO, more valuable than maintaining one near the center, especially as the number of pieces on the board dwindle.
2. Later in the game an advanced pawn can be very valuable. You're program may not be able to look ahead far enough to realize that, so you should bias the evaluation as the game progresses.
3. I don't think your rewarding your pieces for putting pressure on the enemy king.
4. Worse than a two pawns on a file is three pawns on a file. If given the choice, the computer should be biased towards doubling up rather than tripling up.
5. Knights in the center only holds true during the beginning of the game IMHO. As the game progress you could take away the positive bias of this.
6. Do you award points for mainting castling rights?
7. Do you have an opening book?
Congrats on getting a chess engine running.
Good luck,
Will
[edited by - RPGeezus on March 29, 2004 4:13:24 PM]
To make your chess program play better, you have to make it more algorithmically efficient. Searching a game tree is an exponential problem. Constant speedups help, but they will not make the program significantly stronger. Don''t worry about how fast your move generator is, or how many nodes per second you get, at all. I mean it. You will waste tons of time messing with that stuff, and it really doesn''t help that much. Once your program plays very well, then you can go back and speed those up. If you want to have a program that plays well, you need to try and understand the problem of searching a game tree. In other words, you need to understand how alpha-beta works, and the enhancements to that algorithm. How well alpha-beta works is very dependent upon your move ordering. I would recommend the following:
1. Create a simple evaluation. Piece-square tables are fine.
2. Implement alpha-beta and get it working. This includes some kind of quiescence search.
3. Implement a transposition table (hash table). This will help move ordering tremendously. Experiment with killer and history heuristics, and with adding a SEE (static exchange evaluator). You might also experiment with aspiration search here.
4. Implement some kind of pruning to avoid spending most of your time looking at worthless moves. Probably null-move is the one most people use.
5. Upgrade your alpha-beta search to use PVS, or use MTD(f).
6. Add internal iterative deepening.
7. Try any other search enhancements.
8. Now go back and improve your evaluation.
It is important to take your time with a chess program. Don''t rush it. If you try to rush things, you will probably create bugs in your program that you will have a nightmare of a time trying to fix. You will end up saving tons of time by taking your time and getting it as correct as possible the first time.
I cannot stress the importance of understanding the problem enough. I wasted years trying to figure out how to make my program as fast as possible and I avoided learning about the subtleties of how alpha-beta works and how all of the enhancements to that algorithm work. You can create a pretty decent program with a very simple evaluation function if you work hard to understand game tree search and alpha-beta. Then you can go back and improve your evaluation, and you''ll have a monster. Remember, search is a form of knowledge itself. By improving the search you are improving the knowledge in the program.
1. Create a simple evaluation. Piece-square tables are fine.
2. Implement alpha-beta and get it working. This includes some kind of quiescence search.
3. Implement a transposition table (hash table). This will help move ordering tremendously. Experiment with killer and history heuristics, and with adding a SEE (static exchange evaluator). You might also experiment with aspiration search here.
4. Implement some kind of pruning to avoid spending most of your time looking at worthless moves. Probably null-move is the one most people use.
5. Upgrade your alpha-beta search to use PVS, or use MTD(f).
6. Add internal iterative deepening.
7. Try any other search enhancements.
8. Now go back and improve your evaluation.
It is important to take your time with a chess program. Don''t rush it. If you try to rush things, you will probably create bugs in your program that you will have a nightmare of a time trying to fix. You will end up saving tons of time by taking your time and getting it as correct as possible the first time.
I cannot stress the importance of understanding the problem enough. I wasted years trying to figure out how to make my program as fast as possible and I avoided learning about the subtleties of how alpha-beta works and how all of the enhancements to that algorithm work. You can create a pretty decent program with a very simple evaluation function if you work hard to understand game tree search and alpha-beta. Then you can go back and improve your evaluation, and you''ll have a monster. Remember, search is a form of knowledge itself. By improving the search you are improving the knowledge in the program.
<SPAN CLASS=smallfont>quote:Original post by Telamon
My engine, Fimbulwinter, tops out at around 2300 ELO. It's winboard compatible and I used to run it on ICC alot. So if you're engine is already beating GNUchess, maybe it's already better than mine and most of my advice was worthless :-)
http://www.stanford.edu/~jjshed/chess
</SPAN>
i have noticed your site.
but your last version is 6.00,
while in download section,
the latest version is 5.00,
why didnt u upload 6.00 ?!?!
just askin u kno !
[Edited by - zaidgs on August 26, 2004 7:13:05 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
