Devlog of Leorik

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

User avatar
lithander
Posts: 881
Joined: Sun Dec 27, 2020 2:40 am
Location: Bremen, Germany
Full name: Thomas Jahn

Re: Devlog of Leorik

Post by lithander »

j.t. wrote: Sun Jan 30, 2022 12:19 am If I understand correctly, usually if you don't specify a license, people can basically only look at the code if you put it online. However, by using GitHub you might have to give up some rights. This stackexchange thread suggests that if you put your code publicly on GitHub, people are allowed to fork your code (but probably not allowed to edit it? Idk).

I mean, at the end you probably have to rely on people being honest and fair, because I guess that you won't start a legal battle because of this.
I wouldn't sue people and I can't prevent anything once the source is on github. That's precisely why I'd rather complete the work I have in mind and not publish unfinished stuff.

For now I think I'll just keep the repository private until I'm ready to release the first binary. Gives me a bit of time to think of whatever license I'm most comfortable with. In the meantime if anyone wants to review the current version's source or a binary just send me a PN. ;)
Minimal Chess (simple, open source, C#) - Youtube & Github
Leorik (competitive, in active development, C#) - Github & Lichess
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: Devlog of Leorik

Post by mvanthoor »

lithander wrote: Sun Jan 30, 2022 2:16 am For now I think I'll just keep the repository private until I'm ready to release the first binary. Gives me a bit of time to think of whatever license I'm most comfortable with. In the meantime if anyone wants to review the current version's source or a binary just send me a PN. ;)
Personally I chose the GPL. It is said to be viral, because anything derived from a GPL-project must be GPL-compatible. That is precisely the reason why I chose it. I don't mind anyone forking my engine and then building on top of it, but I want that work, and the changes it makes, to be open-source as well. I would mind if someone forks my engine, changes some stuff to make it twice as fast and then says: "These changes are private. Bye!" That's the reason for not choosing a super-permissive license.

Obviously someone could still download the engine as a zip-file from Github and then push it to another repository under a different name. I'd never know until I would somehow by accident discover that repository.
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL
Mike Sherwin
Posts: 871
Joined: Fri Aug 21, 2020 1:25 am
Location: Planet Earth, Sol system
Full name: Michael J Sherwin

Re: Devlog of Leorik - first impression

Post by Mike Sherwin »

Already an in your face engine. Just needs more depth. Suggest modifying the PSTs with specific knowledge before each search like, if there is a pawn on d2 discourage a piece from going to d3. Or if there is a pawn on d3 that is blocked encourage a bishop on f1 to go to g2. Encourage knights to go to an outpost square. Etc. It's unlimited at virtually no cost and the knowledge is position specific! Anyway, here is my first game against Leorik.
[pgn][Event "Computer chess game"]
[Site "DESKTOP-HFVHK2B"]
[Date "2022.01.30"]
[Round "?"]
[White "Leorik.Engine"]
[Black "Mike Sherwin"]
[Result "0-1"]
[BlackElo "2400"]
[ECO "B02"]
[Opening "Alekhine"]
[Time "10:59:12"]
[Variation "Two Pawns Attack, 5.Nc3"]
[WhiteElo "2000"]
[TimeControl "600+30"]
[Termination "normal"]
[PlyCount "70"]
[WhiteType "program"]
[BlackType "human"]

1. e4 {(e2-e4) +0.08/10 149} Nf6 2. e5 {(e4-e5) +0.60/9 26} Nd5 3. c4
{(c2-c4) +0.54/9 37} Nb6 4. c5 {(c4-c5) +0.17/9 43} Nd5 5. Nc3 {(Nb1-c3)
+0.28/9 43} e6 6. d4 {(d2-d4) -0.12/10 94} d6 7. cxd6 {(c5xd6) -0.39/10 82}
Nxc3 8. bxc3 {(b2xc3) +1.94/10 27} cxd6 9. Bf4 {(Bc1-f4) +0.11/9 31} d5 10.
Nf3 {(Ng1-f3) +0.29/9 122} Qa5 11. Qc2 {(Qd1-c2) -0.21/8 20} b5 12. O-O-O
{(O-O-O) -0.02/8 85} Ba3+ 13. Kb1 {(Kc1-b1) -0.19/9 31} Nd7 14. Bd3
{(Bf1-d3) -0.42/8 51} Rb8 15. Bxh7 {(Bd3xh7) -0.47/8 52} b4 16. c4 {(c3-c4)
-0.89/9 34} b3 17. axb3 {(a2xb3) -1.19/10 43} dxc4 18. Nd2 {(Nf3-d2)
-2.00/9 68} cxb3 19. Nxb3 {(Nd2xb3) -1.61/9 31} Qa4 20. Rd3 {(Rd1-d3)
-2.50/9 55} Bb7 21. Rc3 {(Rd3-c3) -2.07/8 68} Bd5 22. Rc8+ {(Rc3-c8+)
+0.46/8 11} Ke7 23. Bg5+ {(Bf4-g5+) -2.61/10 42} f6 24. Bxf6+ {(Bg5xf6+)
-5.08/10 22} gxf6 25. exf6+ {(e5xf6+) -5.67/10 26} Nxf6 26. Rxb8 {(Rc8xb8)
-6.33/10 43} Rxb8 27. Qc7+ {(Qc2-c7+) -6.31/8 11} Nd7 28. Qxb8 {(Qc7xb8)
-7.43/9 45} Nxb8 29. Kc2 {(Kb1-c2) -6.68/9 16} Qxb3+ 30. Kd2 {(Kc2-d2)
-M5/10 30} Bb4+ 31. Kc1 {(Kd2-c1) -M4/10 26} Qc3+ 32. Bc2 {(Bh7-c2) -M3/10
44} Qa1+ 33. Bb1 {(Bc2-b1) -M2/10 12} Be4 34. Kd1 {(Kc1-d1) -M2/10 17 White
resigns} Qxb1+ 35. Ke2 {(Kd1-e2) -M1/11 27 White resigns} Qd3# 0-1
[/pgn]
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: Devlog of Leorik - first impression

Post by mvanthoor »

Mike Sherwin wrote: Sun Jan 30, 2022 7:55 pm ...
Excellent attacking game Mike :)
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL
Mike Sherwin
Posts: 871
Joined: Fri Aug 21, 2020 1:25 am
Location: Planet Earth, Sol system
Full name: Michael J Sherwin

Re: Devlog of Leorik - first impression

Post by Mike Sherwin »

mvanthoor wrote: Sun Jan 30, 2022 8:15 pm
Mike Sherwin wrote: Sun Jan 30, 2022 7:55 pm ...
Excellent attacking game Mike :)
Thanks! But, Leorik gave me a helping hand by castling queen side. I think it likes me! :lol:
User avatar
lithander
Posts: 881
Joined: Sun Dec 27, 2020 2:40 am
Location: Bremen, Germany
Full name: Thomas Jahn

Re: Devlog of Leorik

Post by lithander »

That was officially the first game Leorik ever played against a human. (I haven't played it yet) Bad luck for my baby engine that this human happened to be such a strong player! ;)

...and you're right Mike, at this low depth the shortcomings of the static PST-only evaluation is obvious. The PSTs just encourage castling and there's nothing to stop it even if the side it's going to castle to is already cracked wide open. Nothing - except deeper search depth of course, so that it would see the unwanted long-term results of the move.

Edit: Leorik's move Bxh7 a bit later also lacks situational awareness. But I'm sure it looked good in the eval at depth 7 or something. ;)
Minimal Chess (simple, open source, C#) - Youtube & Github
Leorik (competitive, in active development, C#) - Github & Lichess
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: Devlog of Leorik

Post by mvanthoor »

lithander wrote: Sun Jan 30, 2022 11:08 pm That was officially the first game Leorik ever played against a human. (I haven't played it yet) Bad luck for my baby engine that this human happened to be such a strong player! ;)

...and you're right Mike, at this low depth the shortcomings of the static PST-only evaluation is obvious. The PSTs just encourage castling and there's nothing to stop it even if the side it's going to castle to is already cracked wide open. Nothing - except deeper search depth of course, so that it would see the unwanted long-term results of the move.

Edit: Leorik's move Bxh7 a bit later also lacks situational awareness. But I'm sure it looked good in the eval at depth 7 or something. ;)
King Safety would also help obviously. Then the engine would see that castling into an open area is not a good idea. Also, if many pieces are pointed at the squares near the king, it would see that moving the bishop all the way to h7, which removes one of its own pieces from around that area, would be a bad idea, even if it wins a pawn. Also; the bishop can be shut out of the game by g7g6, and the only thing to do is to sacrifice it for all the three pawns. Because the black king is not castled there, and there are no other pieces around, that would be a bad thing to do. Winning three pawns on the other side of the board where no action is happening, is a bad idea if it means giving up a bishop that you could use on the other side of the board.

King Safety will fix most of that; therefore I would not spend too much attention to stuff like this before you get into the King Safety part of the engine. As that can gain you 50-100 points (especially if the engine does not have a lot of other features yet), then that feature would even warrant a complete release, IMHO.
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL
User avatar
lithander
Posts: 881
Joined: Sun Dec 27, 2020 2:40 am
Location: Bremen, Germany
Full name: Thomas Jahn

Re: Devlog of Leorik

Post by lithander »

mvanthoor wrote: Mon Jan 31, 2022 12:43 am King Safety will fix most of that; therefore I would not spend too much attention to stuff like this before you get into the King Safety part of the engine. As that can gain you 50-100 points (especially if the engine does not have a lot of other features yet), then that feature would even warrant a complete release, IMHO.
MinimalChess has no King Safety and still I doubt it would make these kind of blunders... in this position, instead of castling it would play Bd3. So even just adding features that increase the search depth will likely fix it.

I'm curious (and maybe some readers here, too) how much extra strength Leorik's speed will give him compared to MMC. Such a comparison requires that Leorik has the same features *and* evaluation as MMC at that some point. Before I reach that milestone I'm probably not going to invest time in a better evaluation or any features that MMC didn't have.

But after that I'm going to see how to move forward and then improving the evaluation with King Safety or more dynamic PSTs is likely a good idea.
Minimal Chess (simple, open source, C#) - Youtube & Github
Leorik (competitive, in active development, C#) - Github & Lichess
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: Devlog of Leorik

Post by mvanthoor »

lithander wrote: Mon Jan 31, 2022 1:24 am MinimalChess has no King Safety and still I doubt it would make these kind of blunders... in this position, instead of castling it would play Bd3. So even just adding features that increase the search depth will likely fix it.
Obviously. In the end, search depth will fix everything. If you go deep enough, you basically only need to check if the position is stalemate, mate, or draw 8-)
I'm curious (and maybe some readers here, too) how much extra strength Leorik's speed will give him compared to MMC. Such a comparison requires that Leorik has the same features *and* evaluation as MMC at that some point. Before I reach that milestone I'm probably not going to invest time in a better evaluation or any features that MMC didn't have.
Indeed. The feature set needs to be _exactly_ the same for this to work: so same number of stages in the move generation, exactly the same evaluation (but the one in Leorik can be incremental, because that will be faster, but not change the evaluation in itself), and the same search features.

If Leorik is 4 times as fast, you could expect it to be 100-120 Elo stronger with the same feature set. (A doubling of speed gets you 50-60 Elo. You can see this in the CCRL list. Lower end engines that search less deep gain more Elo with speed because they can actually reach the next depth. At some point the next depth becomes so big that you need more than double the speed to reach it, so you have diminishing returns.
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: Devlog of Leorik

Post by mvanthoor »

LOL. In the position where Leorik played 0-0-0, my current dev-version also plays 0-0-0 when searching to depth 8. That's logical because it's still using the MMC evaluation tables.

On the other hand, Rustic Alpha 1 (!) never considers anything else but Bf1-d3 after the first few depths and then it castles king-side. It seems to immediately decide that castling queen-side is a very bad idea, and it also correctly considers the black queen-side attack:

Code: Select all

go
info score cp 105 depth 1 seldepth 3 time 0 nodes 29 nps 0 pv e1c1
info score cp 85 depth 2 seldepth 5 time 0 nodes 840 nps 0 pv e1c1 c8d7
info score cp 80 depth 3 seldepth 5 time 8 nodes 8115 nps 1014375 pv f4d2 a5a4 e1c1 a4c2 c1c2
info score cp 75 depth 4 seldepth 7 time 29 nodes 133535 nps 4604655 pv f1d3 b5b4 f4d2 b4c3 d2c3
info score cp 75 depth 5 seldepth 7 time 168 nodes 763158 nps 4542607 pv f1d3 b5b4 f4d2 b4c3 d2c3
info score cp 80 depth 6 seldepth 7 time 1430 nodes 7758614 nps 5425604 pv f1d3 b5b4 c3b4 f8b4 f3d2 e8g8 d3h7
info score cp 95 depth 7 seldepth 9 time 7954 nodes 38009520 nps 4778667 pv f1d3 c8d7 f4d2 g7g6 a1d1 f8e7 e1g1
info score cp 75 depth 8 seldepth 9 time 72121 nodes 379265156 nps 5258734 pv f1d3 c8d7 f4d2 g7g6 e1g1 f8e7 c3c4 b5b4
It also briefly considers capturing on h7, but in the end decides to solidify on the queen-side and castle king-side.

It seems those handwritten PST's weren't that bad... but then again, I but a fair bit of chess knowledge into them. (I do probably have more knowledge about chess than I generally apply at the board, because I'm often a lazy SOB when playing...)
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL