| |
Main
Date: 08 Oct 2008 20:58:32
From: Roland
Subject: How to program an FICS chess client
|
Hello,
I want to program an internet chess client. My objective is to keep
the code size as small as possible(small memory foot-print also).
Basically what I need is:
-Legal move detection(see which moves are allowed).
-Checkmate/Stalemate detection
-threefold repetition detection
-send commands to server and parse answers from server.
So where can I read the basic algorithms used to do this so I don't
need to reinvent the wheel?
I was reading about bitboards, but I guess this would be overkill
because I'm not making a chess engine, only a client.
How about interacting with the server? Is there any documentation on
how to handle this, how to parse server messages?
Thanks for any feedback!
Roland
PS: Please don't answer to the email. I rarely read it and it's full
of spam.
|
|
| |
Date: 18 Oct 2008 02:01:38
From: Simon Krahnke
Subject: Re: How to program an FICS chess client
|
* Roland <[email protected] > (20:03) schrieb:
>> Well, the simplest thing to test are: Is there a piece of your own color
>> on the destination square and is there a piece of your own color on the
>> source square?
>>
>> Everything else is way more complicated and nothing you should start
>> with. Get the client working and if tf there is a lag, work on that.
>
> No it's not that complicated, I've been a programmer for many years.
Then you probably heard about "do the simplest thing that can possibly
work".
> And I want to start collecting info now so that when I get to code the
> relevant parts I already have it. I mean, legal move detection is a
> basic for any chess program and I was assuming there are already well
> known and discussed algorithms for doing that. Am I wrong? Can anyone
> provide me with pointers or do I have to reinvent the wheel? Does
> every chess program author implement his own legal move detection?
That's normally not needed. All you need to have is pseudo legal move
generation (moving in the right direction and not jumping over pieces)
and a detection for illegal positions where the king is in check[1].
That's all you need for inside the search. If you need to test or parse
a move for legality you can generate a list of pseudo legal moves and
filter the illegal ones out by doing them and checking the result. Then
you can lookup the move to be tested/parsed in the list.
You can look for algorithms in the chess programming wiki. There are
also special tests that test moves inside the search, needed for killer
moves.
But chess engines and front ends have very different performance
requirements.
mfg, simon .... l
[1] Okay, castlings are a little more complicated.
|
| |
Date: 17 Oct 2008 11:03:42
From: Roland
Subject: Re: How to program an FICS chess client
|
>
> Well, the simplest thing to test are: Is there a piece of your own color
> on the destination square and is there a piece of your own color on the
> source square?
>
> Everything else is way more complicated and nothing you should start
> with. Get the client working and if tf there is a lag, work on that.
>
No it's not that complicated, I've been a programmer for many years.
And I want to start collecting info now so that when I get to code the
relevant parts I already have it. I mean, legal move detection is a
basic for any chess program and I was assuming there are already well
known and discussed algorithms for doing that. Am I wrong? Can anyone
provide me with pointers or do I have to reinvent the wheel? Does
every chess program author implement his own legal move detection?
|
| |
Date: 09 Oct 2008 20:56:19
From: Simon Krahnke
Subject: Re: How to program an FICS chess client
|
* Roland <[email protected] > (18:27) schrieb:
>> So I think you should be able to do this with almost no `chess
>> programming'. That said, it would probably be better to do legal move
>> checking yourself as letting the server do it adds lag if the player
>
> Exactly! So what is the best way to do legal move detection?
Well, the simplest thing to test are: Is there a piece of your own color
on the destination square and is there a piece of your own color on the
source square?
Everything else is way more complicated and nothing you should start
with. Get the client working and if tf there is a lag, work on that.
mfg, simon .... l
|
| |
Date: 09 Oct 2008 09:27:09
From: Roland
Subject: Re: How to program an FICS chess client
|
> So I think you should be able to do this with almost no `chess
> programming'. That said, it would probably be better to do legal move
> checking yourself as letting the server do it adds lag if the player
Exactly! So what is the best way to do legal move detection?
|
| |
Date: 09 Oct 2008 14:49:17
From: David Richerby
Subject: Re: How to program an FICS chess client
|
Roland <[email protected] > wrote:
> Basically what I need is:
>
> -Legal move detection(see which moves are allowed).
> -Checkmate/Stalemate detection
> -threefold repetition detection
> -send commands to server and parse answers from server.
I believe that threefold repetition detection would be illegal on
FICS, as it counts as assistance to the player. (Remember that
threefold repetition does not end the game -- it merely gives a player
the right to claim a draw.)
You don't need to detect checkmate or stalemate because the server
will tell you that the game is over and why. Also, I don't think you
actually need to do legal move detection, since the server won't let
you make an illegal move. If I recall correctly, the protocol sends
moves by quoting the source and destination square, so (I think) you
wouldn't even need to parse strings like `Nab3', just `a5b3'. But
you'll need to detect castling (the king just moved two squares so
shift the rook, too) and en passant (a pawn just captured to an empty
square so delete the pawn on the square behind it).
So I think you should be able to do this with almost no `chess
programming'. That said, it would probably be better to do legal move
checking yourself as letting the server do it adds lag if the player
does make an illegal move. (And I used to make illegal moves quite
often. If I picked up a piece with the mouse and decided not to move
it after all, I'd drop it on top of one of my own pieces. This is
guaranteed to be an illegal move so the piece returns to its original
square. Manually returning it to its square is risky because you
might put it on the wrong square and make a move by mistake.)
Dave.
--
David Richerby Hungry Cat (TM): it's like a cuddly
www.chiark.greenend.org.uk/~davidr/ pet but it'll eat you!
|
|
