Dec 23, 2006

[Plan] Move notation

Before going into beta-testing with the move generation I need a way to easily see if all moves get generated correctly. So I am going to add a move-notation method to the Move-class.

Here are examples of all move types it needs to be able to generate:
Qe5       (ordinary move)
Rxc6 (capture)
e4 (pawn move)
cxb4 (pawn capture)
exd6 e.p. (en passant capture)
e8=Q (promotion to queen)
cxd1=R (capture and promotion to rook)
Red4 (rook on e to d4, two rooks on same row)
N4c5 (knight on 4 to d4, two knights on same rank)
0-0 (short castle)
0-0-0 (long castle)
The notation follows simple rules and is quite easy to extract in all areas but one; the check for two pieces being able to reach the same square. We can not extract this from the move-object alone.

I will not implement a check for the two pieces case right now. Mainly because I want to keep it simple and it is not really nescessary since we will be able to see the moves get generated correctly anyhow.

The reason I am going to use short notation here is because it is the easiest kind to read (atleast for me). If we were to use long notation we would not have to worry about the two pieces case since it holds the square the piece is moving from. But as said, this is done for easily getting an overview of the moves generated.

Later on when we are inputting moves into WinBoard (which I am going to use to let Mediocre play online) we will be using another notation, namely:
e4h8   (whatever piece is on e4, moves to h8
e1g1 (if king on e1 it turns into a castle)
c7c8=Q (promotion to queen)
In this notation we do not need to worry about captures or en passant or castling. WinBoard keeps track of what pieces are where, so when we enter this notation it makes the right move.

Edits:
2006-12-23 - Added a line about why using short notation instead of long.

No comments: