hgm wrote: ↑Wed Nov 09, 2022 3:49 pm
I now included an improved version of the Quack engine in the Duck2.zip archive. It no longer plays the Duck randomly, but try to make use of it.[...]
The new version beats the old one with a 70% score, in Duck Chess.
Made a new test. Quack 2.0 did the first 11 moves much better than its predecessors and most time it had a nearly balanced game. In move #12, surprisingly it blundered its queen for nothing. After its lost queen and hopeless position, Quack's evaluation still considered the position to be nearly balanced, perhaps this should be the next point to be fixed. And another one: Quack had 10 minutes for 40 moves, but played all the moves in less than 1 second, something is wrong with its time management
Ah, thank you for discovering this bug. I tested in a wrong way how many attackers a piece had, so that Quack was thinking that h6 was only singly protected, (by Bf8), and thought it could safely take it after blocking that Bishop on g7 with the Duck. I now fixed that (and uploaded the new version). Now it plays 12. Qc1instead of Qxh6 in that position.
Quack does not have any time management. It always moves instantly (i.e. within a millisecond). It would not know what to do with any extra time, after it has assigned a score to each move.
As to the score: It does not use absolute scoring. The scores are not even relative to the current position, but relative to what would happen if it passed its turn. So if it has a hanging Queen it would score a non-capture that moves it to a safe square as +9.
[Edit] And it now scores 80% against the randomly Duck-moving version.
hgm wrote: ↑Wed Nov 09, 2022 6:48 pm
Ah, thank you for discovering this bug. [...] it now scores 80% against the randomly Duck-moving version.
You're welcome! That was a nice progress. In the following test Quack survived 35 moves, and in the opening until move #10 it had even the better position.
A pattern that I believe to recognize: Quack assumes sometimes, that in the next move one of its pieces will be defended by own pieces, and doesn't consider that the opponent can put the duck between the attacked piece and the defender, so that the defense is interrupted. Idk if this can be fixed without being necessary that the engine must look more than a single move ahead, so I am not sure if the mistakes that were made could be avoided by Quack
Comment: Since I did let in the Zillions startposition the duck be on h6, before you input the first move you have to right-click on h6, enter there an empty square, and again with a right click, place the duck on another empty square, say g6. With this new startpos, the game can start.
The last move of Zillions, Nxe4, e2, doesn't look like a healthy knight sacrifice. White can chose between 11.fxe4 and 11.Nxe4,c3, so that the queen cannot capture the bishop on b2. In both cases Black has not enough material to continue the attack
11. Nxe4,f1
Comment: White drops the duck on f1 instead of c3, and sacrifices its bishop. After Qxb2, can White put this queen in prison with c3? Obviously not, on the contrary, Qb2 threatens to capture also Ra1 and then to drop the duck somewhere between the queens, so the defense of Ra1 can be interrupted (the pattern described above, here we see this mistake first time in this game)
11... Qxb2,b1 12. c3,f6
Quack had still time to save the rook a1. But it considers this rook defended by the queen d1, and does not see that the duck between a1 and d1 can interrupt this defense. The rook a1 is lost!
Again the same mistake. Quack seems to assume that after 28...Bc2, c3, the bishop a4 can be defended with Rh1-a1. But again, the duck on a2 or a3 can interrupt this defense. The bishop a4 is lost!
Remaining weaknesses of Quack are that it doesn't detect soft-pinning and that it doesn't understand that protecting is a 4th method to defend against a threat. It has no idea what its moves protect, as it would require two moves in a row with the same piece to detect that. That it gives away Bb2 is because it has no idea Nc3 was pinned on it. That it continues to give away Ra1 is because it cannot imagine a way to save it at all. Its threat detection does see an unprotected Rook attacked by a Queen, but it can only move to a2, where the Queen would take it as well, it is a contact attack, so nothing can be interposed, and the Queen cannot be captured. It would not award any moves that would protect it; even if it would have been able to protect it through an unblockable move it would not have seen it.
The case with Ba4 arises mainly because it doesn't see it coming. After Bc2,b3 it does recognize Bc2xa4 as a threat (threats are not blocked by the Duck, because the Duck will have moved away by the time the opponent can execute them). But again it s clueless how to solve it; Ba4 has no safe square to flee to, there is no second square where the threat could be blocked, and Bc2 is not capturable. So it just writes off Ba4. It has no idea that Ra1 would protect it. In Duck Chess that is probably just as well, as protection is a very unreliable mode of defense, as it can be subverted by the Duck. Only protection through a contact move would help. But it would not see that either. The problem is really that Ba4 can be attacked and that there is no way to defend it from that attack. But to see that requires a multi-move sequence, which it cannot anticipate. I suppose that in Duck Chess pieces can be easily very trapped, by throwing the Duck in their path.
You just cannot expect too much from a non-searching engine. (Unless it has a neural net with millions of cells...)
Uploaded MayhemDuck 1.2 to latest Mayhem release. Windows / arrm / Linux binaries. Interested whether it works. It uses e2e4,e4e6 instead of too simple e2e4@e6 format
MayhemDuck searches all drops. But only the best drop is searched fully. Other drops are pruned very heavily.
Here MayhemDuck is able to find the only winning move really quickly:
JohnWoe wrote: ↑Thu Nov 10, 2022 1:52 am
Uploaded MayhemDuck 1.2 to latest Mayhem release.
Thx for MayhemDuck, have tested it vs Zillions.
MayhemDuck like Quack prefers in the first move to drop the Duck on h6. I had thought this square was unimportant and set in startpos the Duck here, but anyway, simply set in DuckChess.zrf the Duck in the startpos on an other square, let's say on a6
MayhemDuck survived longer than Quack, it could look ahead between 6 - 9 ply. Zillions with 8 - 12 ply did a bit better (although the ply is not a good measure, it says nothing about how the engines evaluate moves and/or prune them away), so Zillions could get slowly material advantage. Finally, while MayhemDuck had a bare King in a totally lost position, it could not handle the promotion of a pawn to a queen an crashed.
In move 8, White's en passant move had to be entered manually in Zillions. Here is obviously a weakness in my code that has to be improved
In move 36: after 0-0-0, the Winboard GUI did set the Duck automaticaly on e8, Zillions had preferred it on b8. I continued with the Winboard-forced change, but even after this, Zillions had no problem to win
Move 44: After the black pawn promoted to a Queen, MayhemDuck crashed. Through this crash I had no change to save the game, but could make a screenshot where the all the moves including Mayhem's evaluations can be seen:
JohnWoe wrote: ↑Thu Nov 10, 2022 1:52 am
Uploaded MayhemDuck 1.2 to latest Mayhem release.
Thx for MayhemDuck, have tested it vs Zillions.
MayhemDuck like Quack prefers in the first move to drop the Duck on h6. I had thought this square was unimportant and set in startpos the Duck here, but anyway, simply set in DuckChess.zrf the Duck in the startpos on an other square, let's say on a6
MayhemDuck survived longer than Quack, it could look ahead between 6 - 9 ply. Zillions with 8 - 12 ply did a bit better (although the ply is not a good measure, it says nothing about how the engines evaluate moves and/or prune them away), so Zillions could get slowly material advantage. Finally, while MayhemDuck had a bare King in a totally lost position, it could not handle the promotion of a pawn to a queen an crashed.
In move 8, White's en passant move had to be entered manually in Zillions. Here is obviously a weakness in my code that has to be improved
In move 36: after 0-0-0, the Winboard GUI did set the Duck automaticaly on e8, Zillions had preferred it on b8. I continued with the Winboard-forced change, but even after this, Zillions had no problem to win
Move 44: After the black pawn promoted to a Queen, MayhemDuck crashed. Through this crash I had no change to save the game, but could make a screenshot where the all the moves including Mayhem's evaluations can be seen:
Thanks for the report.
Yeah there was a bug in move handling. There were others bugs too. Also MayhemDuck expected different promotion format e2e1q,e1a2 not e2e1,e1a2q.
MayhemDuck is really fast 20MNPS (drops are fast to generate but branching factor grows ...) but not pruning enough to reach high depths. Basically 2 white moves in a row. It searches all drops. Drop to h6 is due to first move being different than others. The duck isn't on the board. It seems to solve puzzles fine now. I will upload MayhemDuck 1.3 at some point.
Testing v1.3:
MayhemDuck seems to play a good move as black "b8c6,c6e2" Develop a knight and block on e2.
Well done, Mayhem becomes better and better. This time it has a great attack, can be in the next version it will be able to beat Zillions. Since it has a fast search with 20 Mps, I tried to give Mayhem more time to see if it can outsearch its opponent, 30 moves to be done in 10 min
Mayhem perhaps considers its bishop c8 defended by rook a8. That's wrong, the duck can interrupt this defense. The bishop is lost, and since the capture comes with check, also the rook a8!
Zillions puts the rook on a2, it has no concept of positional play and is purely materialistic, while Mayhem despite it'S material disadvantage builds up pressure and attack
Together with the fact that Zillions doesn't "feel" the danger of Black's attack, my zrf has the known weakness that it cannot recognize en passant. Mayhem deserved this chance to strike back!
Not so good, the exchange of the queens gives up the attack, which had to be continued, because the material disadvantage and the triple pawn are bad conditions for the endgame
It seems my engine starts to work too. I had a lot of trouble with the check extension. Mutual perpetual check is very easy in Duck Chess; the players can just alternate the Duck between blocking the one and the other, and in the mean time play an entire game with their FIDE pieces (so that you would also not run into repetitions). So a check extension of a full ply led to a crash by infinite recursion.
I had to change the engine in more places than I thought; when the FIDE move generator finds King capture it cannot immediately return a +INF score, because that capture could be impossible for some of the Duck locations. Only when it is a contact capture you can do that. So distant captures of a King had to be put in the move list, with the highest sort key. Alpha-beta was also not trivial, and I am not sure I currently make the most of that. I also have no clear idea yet how to identify the PV.(Which is related to the alpha-beta problem.) And the hash table will have to be redesigned, so it can contain multiple moves that cannot all be blocked at the same time by the Duck. Currently the hash move is often useless, because there are Duck locations that block it.
Anyway, the engine played the following game against Quack that looked pretty nice:
What I especially liked is that it appears to recognize the checkmate 3 moves in advance; that means it must be doing something correctly.
BTW, the engine is called DuckSlayer (because it is a KingSlayer derivative). I will test it some more to see if I can expose any remaining bugs before I release it.
[fen]1k6/1p6/p1p5/8/8/4K3/5*2/6q1 b - - 0 49[/fen]
The engines are still blunder-prone. First Mayhem gives away a Knight, and then DuckSlayer his Queen. But with this enormous advantage Mayham allows its own Queen to be trapped, but can still get a Rook for it. And later an organized hunt of the Duck-assisted Bishop pair by DuckSlayer catches a Rook, and the chances turn. In the end there is a mishap which can probably be blamed on WinBoard not passing on the move correctly. (Notice that in the PGN on the previous move it puts the Duck on 'q1'; probably Duckslayer did put it on f2, and WinBoard got confused by promotion move so that Mayhem thought he was free to put the Duck there. Since I did not have WinBoard's -debug option on there is no way to know what happened here. (But perhaps I can reproduce it.)
Another bug in WinBoard is that it cannot read castlings from PGN. In the above game you would have to replace the O-O-O by e8c8 in order to load it into WinBoard. Enough things to fix, obviously...
[Edit] Oh, it is really DuckSlayer that messes up the promotion move. Fortunately it reproduces:
