Tuesday, 24 April 2007

Vicki is crawling now...

Vicki is now out there, but I am not very happy with her performance. It plays terrible chess and the positional play is especially weak. Fortunately, there is still a great deal that I can do. I have started adding to the chess knowledge by tweaking and improving the static evaluation function to get a base to work from. The following is now considered:
  • Pieces on the board, P=100cp; R=495cp; N=280; B=290cp; Q=895cp (a bit less than the accepted values to encourage positional play).
  • The pawns positions on the board, giving a small bonus to pawns that have advanced further up the board.
  • Bonus for passed pawns; penalty for doubled & isolated pawns.
  • Knight position bonus (controlling central squares).
  • Mobility bonus (1 centipawn for each move), excluding the king.
  • Bonus for castling capability (retains bonus once castled).

I estimate Vicki at about 1100, having played against rated engines (she even won a few!). Some serious things are still missing and are next on my todo list:

  • Vicki does no move ordering whatsoever. I have a few ideas that I would like to implement, including SEE, sorting by the principal variation returned by the iterative deepening search (yes, all previous iterations are wasted!) and finally, a variation of killer moves.
  • Transposition table (Zobrist keys are working).

On a positive note, Vicki had an interesting game against Mediocre, where it was way behind in material and tried to sacrifice a rook (by attacking Mediocre's rook) to force a stale-mate. I was rather impressed by the strategy (which I first thought was a bug!) However, Mediocre is no pushover engine and didn’t fall for that trick and simply moved its rook away! Vicki was mated a few moves later, but at least the draw-detection is working well.

5 comments:

Jonatan Pettersson said...

Ordering captures before non-captures is easy (since you already can generate captures only judging by an earlier post) and might help a great deal. Of course it will work even better once you get SEE working to sort losing captures last.

For SEE take a look at Scorpio's or Glaurung's way of doing it (or Mediocre's :), they are all pretty much the same and very effective. Of course you have to adjust it for Vicki but the general principle is helpful. (I wrote a guide about it on March 26 in my blog)

If I had known how (fairly) easy it is to implement like that I would have done it alot earlier in Mediocre.

Anonymous said...

hello

its nice to try develop a chessengine

is it possible to do this
whitout knowing to programming?
i want to do myself but dont
know a thing about programming

otherwise good luck!

Sparky said...

I am currently refactoring the generation of captured and SEE. Instead of generating captures and then evaluating them with SEE (two separate functions), I iterate over the possible victims, counting the number (and value) of attackers and defenders. If I find a winning/break-even capture I add it to the capture list (and sort them at the end). I suspect this may be a bit faster than my current approach. I’m busy with this right now and should be finished by the end of this week. Thanks for the input, I appreciate it very much!

Sparky said...

Hi anonymous – unfortunately writing a chess engine without programming skills is like playing the violin without knowing Do-Re-Me-Fa-So-La-Ti-Do! I recommend you get your hands on an introduction book on “Java”, which, in my opinion, is one of the best languages for a beginner. Java is frighteningly powerful and flexible (and it well used in the industry!). Once you understand basic I/O, variables and control structures, you can try writing Tic-Tac-Toe and then move on to chess programming. Best of luck! (and enjoy the JOURNEY!)

Anonymous said...

I would stick with more "traditional" values P=100, N=B=325, R=500, Q=975 at least for the time being. Move ordering is extremely important and well worth spending a lot of time on. Take a look at Ed Schroeder pages on Rebel for an effective scheme.