I have coded a chess engine in C# which has no sophisticated features.

I have just done with mate detection and some crude static evaluation.

I am trying to make it UCI compatible, but then I am facing a question as to why the protocol returns the list of moves rather than the fen of the new position.

I mean the list of moves will take more time to execute and the space required is also more than equivalent FEN string.

Can any one help me with this?

First of all, the protocol allows both possibilities. What Paradigm Shifter says is true, but after an irreversible move (i.e., a pawn move or a capture) is played, the GUI could send the FEN for the position after the last such move and then the list of moves from that point. However, many GUIs choose to send the whole list of moves every time. Presumably this is done for simplicity. Although it might be suboptimal, it's not a problem in practice.

Hi all, Thanks for replying.

I faced this question as I programmed by Engine to setup board via FEN and not by move input.

I don't really keep track of game specs like castling and enpassant squares on move by move basis, but rather break the fen and adjust all parameters accordingly.

I am using Arena as GUI. Is there any setting where in I can just tweak it to send me the FEN instead of moves, but then again I wouldn't be able to keep track of 3-repetition draws.

If I go with the move approach, then I have to convert the physical move to logical 64 bit-bit-board move, adjust all the flags and so on.

So is this worth or is there anything else which I am missing.

Converting the move in algebraic notation to whatever data structure you use for moves shouldn't be too hard and you should definitely do it. You should also be able to keep track of castling, the en-passant square and how many moves have happened since the last irreversible move, because otherwise you can't implement the rules of the game correctly.

Hi alvaro, thanks for replying.

I implemented the move logic without considering 3 move repetitions which is going to be my next priority.

Here is a game that it played at maxDepth 5 without any sophistication not even killers or anything of that sort, plain alpha beta with very crude static evaluation.

it took about 15 secs to make a move on an average.

There was a time when I actually thought that my program was pressing the game, but then as it is clear from the game, I have messed up with some move making issues which as of now I would be checking.

Look up "perft". It's the best way to find bugs in your move generation code and in your functions to make and undo moves.

Thanks for replying.

Can you comment on the speed of the engine when it take max 30 secs to play a move at 5 plys and further 5 plies at QSearch(Without MVV/LVA or any sorting).

I asked you this as I would like to know if I don't have anything terribly wrong going on.

I ran perft suite as my unit test suite, had no findings.

I think I have messed up some where in make moves that come from GUI through UCI protocol. May be its missing some checks and other feature.

I would check on those by printing some display boards.

30 seconds for depth 5 is absurdly slow these days, but I don't see much point in looking at the performance before you have implemented some very basic improvements. MVV/LVA in quiescence search is particularly critical.

How many nodes per second is your engine searching? Some people count calls to make_move, some people count calls to the recursive search functions; either one will do.

I think this is a hardware + programming efficiency issue.

Please comment as to how can I improvise this.