Ratings & Comments

Included in the sub-wiki below is a brief description of Duck Chess (not really sufficient):

https://en.wikipedia.org/wiki/List_of_chess_variants#Variant_(fairy)_pieces

Also, from Google here's a brief blurb:

Duck Chess is a chess variant invented by Dr. Tim Paulden in 2016. The game follows most regular chess rules but adds a dynamic component to the mix: a rubber duck that both players can move. Duck Chess introduces a rubber duck that acts as a blocker.

Another such blurb, again not quite sufficient:

Each player's turn has 2 steps: After moving a piece, the duck must be moved to a different and empty square. The duck does not move like a chess piece, you can move the duck to any open square on the board. There is no check or checkmate in Duck Chess! This means you can move into check, so be careful!

Here's a link Google gives from Chess.com about the rules of Duck Chess, again brief, but apparently this time sufficient:

https://support.chess.com/article/4578-what-is-duck-chess#:~:text=Each%20player%27s%20turn%20has%202,into%20check%2C%20so%20be%20careful!

https://www.google.com/search?client=ms-google-coop&q=Duck+Chess&cx=partner-pub-2787503004438672:4328536141#cobssid=s Please solve this)

While adding some tags here and there, I am thinking of tagging some more square boards and I need agreeable names for that tags.

Two are quite clear:

16x16 hexadecimal (from Greek)
20x20 vigesimal (from Latin)

But what about the other numbers 11, 13, 14, 15, and 18 (I leave out 17 and 19 just now, they are probably too odd)?

I'm thinking of

11x11 onzenal (from French)
13x13 treizenal (also from French)
14x14 quatorzenal (again from French)
15x15 femtenal (from the metric prefix "femto" 10^{-15}, ultimately from Danish 15)
18x18 attenal (from "atto" 10^{-18}, ultimately from Danish 18)

What do you think?

Why Horde chess exist on Lichess and aren't on Chessvariants? I tried to write Horde's rules but I met a page's number limit) Please write. Lichess is free chess site with billions of games and millions of players worldwide♡

I don't know what PGP has to do with Game Courier, but the problem is now fixed. Perhaps you meant PHP.

This is what I expected. Stockfish uses bitboards, and the standard algortithms for bitboards are very much specialized for sliding along diagonals and orthogonals. Fast algorithms for check detection also often assume that moves are reversible which is also not true for bent riders.

So it seems stockfish cannot do bent riders!

https://github.com/ianfab/Fairy-Stockfish/blob/master/src/variants.ini

It might be good to take a look at this. Variants created by individuals are implemented by this definition.

And I use Fairy Stockfish via WinBoard (XBoard), I'll give you the file if you need it.

Thanks, Daphne! Have you any idea about what fairy pieces it recognizes?

Aurelian Florea //

https://github.com/ianfab/Fairy-Stockfish/releases/tag/fairy_sf_14

I downloaded Fairy Stockfish from assets here.

https://discord.gg/aPs8RKr

It might be quicker to ask on this channel how to use Fairy Stockfish.

I have seen below a discussion involving stockfish and chess variants. I did not knew that there is a connection. Can someone explain me please what variants, stockfish can play!

A few months ago (perhaps a year or more), the code for shogi was modified. We now seem to have special variables like pawn-range etc.

The code I copied and modified many years ago does not seem to be working. Below is an error message below that I got using my old code where b is a black bishop, when I attempt to do a drop I seem to get the error message The move MOVE: b*9h ain't well-formed.

Any suggestions on how I should correct this?

Array ( [0] => MOVE: [1] => b [2] => * [3] => 9h )

ILLEGAL: b*9h on turn 8:

The move MOVE: b9h ain't well-formed. b is a coordinate. So should be a hyphen.

Go back with your browser's BACK button, reload the page, and try again.

For diagnostic purposes, here is the full movelist:

1. p 8g-8f 1... P 8c-8d
2. n 9i-8g 2... N 9a-8c
3. n 8g-7e 3... N 8c-9e
4. n 7e-8c; +n-dest 4... N 9e-8g; +N-dest
5. +n 8c-9b 5... +N 8g-9h // - bCapture- -
6. s 8i-9h 6... B*8g // - Check! -
7. s 9h-8g 7... P 4c-4d
8. b*9h

I'm trying to accept a metamachy challenge but I am getting the following error:

"Your userid is catugo. This log is private. It may be viewed only by the players. If you are one of the players, please sign in first. You may use the menu for this."

Well, as a compromise I introduced a parameter fileOffset (default value 0), which determines how much the normal file labeling is shifted to the right (white POV). Where the alphabet is treated as a cyclic set a-w. This means that for fileOffset=1 the left edge gets labeled 'w', and the right edge just gets the next character in the normal sequence (so 'i' for Brouhaha. This was easy to do, and offers at least some improvement for the rare case one would want this.

This would not allow pasting of Game-Courier notation into the Diagram for Brouhaha (assuming the preset there uses the labels x and y), as GC always mentions the square of origin, and the Diagram would not recognize those labels. But I guess GC notation would not be accepted anyway, as it has a space between piece ID and the coordinate move. (This could probably be solved by making the parser ignore all strings of length 1, though, as the piece ID is redundant.) But relatively simple pre-processing of a GC game with a text editor (globally replacing 'y' -> 'i' and ' x' -> ' w') could solve that.

For Omega Chess the wizard squares would become w0, w11, k0 and k11. As the Wizards starting there are also color bound these are not very likely to appear in game notation, unless you would actually move something to those.

Probably best that I change the extra files to 'y' and 'z'.

Well, if it is important for backward compatibility you could keep the 'x' for Brouhaha, as I explained in the edit of my previous posting. I suppose there aren't many other variants where simple a-... file IDs would not be satisfactory. Perhaps Omega Chess.

I think that there is very little reason to ever use anything else than consecutive letters to indicate the files, so a general way to define arbitrary individual names seems like overdoing it. A satisfactory solution would be to define 'w' as the letter preceding 'a' (to avoid xyz), and count backwards through the alphabet when more-'negative' letters are needed. So for Brouhaha we would use 'w' and 'i', and could describe the system by specifying a simple offset (e.g. firstFile=w). Another possible system would be to define the number of 'extra files', which would be assumed added to the board proper both left and right, and would have their own system of letter assignment from near the end of the alphabet. The first file of the proper board would then always be 'a'.

But 'x' would not be acceptable, as it would make the SAN notation ambiguous: the is also used as a capture indicator.

This is an excellent point.  ChessV doesn't use SAN at all and I'm not really familiar with it so this didn't occur to me.  Probably best that I change the extra files to 'y' and 'z'.

That would be great, it its not too difficult.  Admittedly this is pretty unusual, but in the case of Brouhaha, I think it makes sense.  Games will often open with the usual moves and I like the fact that they are still "e4 e5 Nf3" ...

There is a problem, though: I see that you are using 'x' and 'z' for the edge files on your Brouhaha page. But 'x' would not be acceptable, as it would make the SAN notation ambiguous: the is also used as a capture indicator. There must be some restrictions on file labels to make notation work. If it was only a matter of choosing what to display in the margin of the board diagram it would not matter what labels you choose. (As long as they are not so large they would not fit in a cell the size of a square.) But the SAN generator and move parser must also be adapted to use those labels.

Regarding the array FEN, no, I am not asking the interactive diagram to generate it.  If I could add custom text under the list or under the board that would do it.  My appologies if this is already possible - it may well be.

Well, the Interactive Diagram is just an element in the HTML page you would submit as an article or comment. It would be entirely up to you to design the rest of the page. You just embed the Diagram and its 'satellites' in the page you design by inserting a HTML tag pair with the proper id (or, for the board element, with class="idiagram") in the place where you want those to appear. The board element will contain the Diagram's specification, which will be deleted by the script, and then all the recognized elements (board diagram, piece table, piece list, piece descriptions) will be filled with the proper content according to the specs.

There only would be a problem if you would want to have extra text embedded in the elements that are filled by the script, because anything you write there would be replaced by what the script generates for that element. The reason for having the script generate those elements, rather than have the user write them, is usually that they contain clickable items that must invoke functions of the script. It would not be very hard even for an HTML-ignorant user to supply a list of pieces and their starting squares (by using the WYSIWYG mode of the editor), but clicking the pieces would then not summon the move diagrams.

[Edit] Perhaps we get away with the 'x' in Brouhaha: there are only Brouhaha squares on that file. They can never be destinations, and SAN would never mention a square of origin unless there is a need to disambiguate. And since the piece starting on this square is color-bound, and its Brouhaha squares for the same player are of different color, disambiguation for a Cleric move would never be needed. So the 'x' would never appear as a square coordinate in the move notation, and the fact that the move parser assumes it will never be a square coordinate will not hurt.

the options to color the squares and use arbitrary sets of piece images has been there from the very beginning

Ok, sorry.  Not surprising that my memory is inaccurate ...

Anyway, it should be easy to implement an option 'fileLabels' that would override normal labeling.

That would be great, it its not too difficult.  Admittedly this is pretty unusual, but in the case of Brouhaha, I think it makes sense.  Games will often open with the usual moves and I like the fact that they are still "e4 e5 Nf3" ...

Regarding the array FEN, no, I am not asking the interactive diagram to generate it.  If I could add custom text under the list or under the board that would do it.  My appologies if this is already possible - it may well be.

There is something very strange with the title of your posting, which is not equal to the title of the subject thread.

Yes, my post was a standard reply.  Don't know what happened here, but probably another glitch of the site move.

The obvious remaining reason to favour static images over the interactive diagram is that the latter only works with Javascript enabled. I suppose the obvious(?) way around that would be to also have the design wizard generate a link to a Diagram‐Designer‐ or Scalable‐Diagram‐Editor‐generated (if the latter gets installed?) image and wrap it in <noscript> tags?

P.S. There is something very strange with the title of your posting, which is not equal to the title of the subject thread.

The same is true for the first two comments to be moved to this thread, when viewed through the main comments page (EDIT: and apparently this comment too; the comment editing form has the following warning above it: The ItemID 836609b4fd3c40eb no longer matches any item in the Item table.)

Now it has lots of options to set colors, etc., but if I remember correctly, it didn't originally let you set squares colors.  Now you can pick piece graphics, set square colors, and set border color.  I think that mostly addresses the concerns.  I can only think of two outstanding concerns (one is probably very easy to address, the other is probably not.)

Well, the options to color the squares and use arbitrary sets of piece images has been there from the very beginning. What is a relatively recent addition is that you can also enable a rim with coordinates around the board, and specify the color and letter color of that.

About the coordinates: there already is an option 'firstRank' which you can use to specify how ranks are counted. (And then enables the display of the coordinate rim.) I don't have something like that for the files, as I couldn't imagine this would ever be needed. Bfore 1 comes 0, and indeed some variants count 0-9. But what comes before 'a'? Anyway, it should be easy to implement an option 'fileLabels' that would override normal labeling.

I did not quite understand the other request. You are referring to the 'satellite' that can be embedded in the text to display the pieces as clickable items in an 'unnumbered list'? Would the FEN have to appear as the last item in that list? The list would only be added if you embed the HTML <ul> directive with the proper satellite id in your text. I could easily make it such that items you already specified in that list remain at the bottom of it after the Diagram scripped has filled the table with the piece items. If you want the FEN to appear below the table, you could write it there yourself in the HTML. Or do you expect the Diagram script to generate the FEN? Not all sets of piece IDs would allow a position to be encoded as FEN, though. (There could be multi-letter IDs, of some pieces might have the same ID.)

P.S. There is something very strange with the title of your posting, which is not equal to the title of the subject thread.

Very nice!  This has come a long way.  One small glitch I noticed is that if you click to move a piece and then right-click to reset, the banner still says "position after (half)move 0" rather than returning to its original state.

Sorry I didn't respond sooner to the question about why I don't use the interactive diagram as the main diagram.  I think it was primarily because I wanted complete control over how the board looked.  Now it has lots of options to set colors, etc., but if I remember correctly, it didn't originally let you set squares colors.  Now you can pick piece graphics, set square colors, and set border color.  I think that mostly addresses the concerns.  I can only think of two outstanding concerns (one is probably very easy to address, the other is probably not.)

First, I am assuming you cannot change the rank/file notations.  This is generally unimportant, but there are exceptions.  For example, in Brouhaha, the files have different names so that the main portion of the board still has the usual files a through h.

Second, to the right of the board, I was listing the pieces and locations using the long-standing format of the Chess Variant Pages.  I then started adding the array FEN (perhaps not useful to some, but very useful to others as the most compact descripton of all the pieces, their starting locations and notations.)  If it was possible to add text below the piece list for the optional specification of array FEN, or whatever the author wanted to write there, I think that would be sufficient.

I see two minor downsides to the interactive diagram as the main/first/only setup display: it takes a little longer to load, and after making use of the interactivity it is no longer a setup diagram (requires a refresh, or is there a button for reset now?).

I tried to better address these points now. The Diagram can be reset to its original position by right-clicking on an empty square in it. Right-clicking on a piece summons its move diagram. (The latter is a feature I always wanted to have, but it was spoiled by that pesky context menu that the browser would pop up on using the right mouse button. I finally figured out how to suppress that for right clicks on the board.)

I altered the initial message displayed above the board to announce this possibility to the unwary user. I hope this does not make the message too long for very small boards. Perhaps I should make the font side dependent on the board width.

I also shortened the timeout used for initializing the Diagram from 1 sec to 100msec. I hope this doesn't lead to problems.

My earliest post on that seems to have been ignored. I try to ask again the question, I don't understand being the only one feeling the need for that:

I would find useful to have "What's New" appearing directly on the "Explore" menu of the top bar.

If I'm not wrong, it only appear under "Topic Index" in the "Explore" menu, which is a bit burried.

What do you think? Is my suggestion stupid, maybe I've missed something?

I'm spinning off a discussion from Sac Chess around piece set images to a separate thread (moving the last two which didn't discuss Sac Chess at all, but leaving a couple that are split-subject).

what do you see as a disadvantage for using Interactive Diagrams as the main diagram? -- H.G. Muller

I see two minor downsides to the interactive diagram as the main/first/only setup display: it takes a little longer to load, and after making use of the interactivity it is no longer a setup diagram (requires a refresh, or is there a button for reset now?).

The interactive diagram has the benefit of also supplementing the Piece descriptions (position-specific and interaction-specific piece rules are needed in addition, and for accessibility a text move description should always appear) and giving some Playability.

What I think would be nice is to have buttons over the graphic which switch all page graphics between the options. -- Greg Strong

A graphics selection button would be nice, although of course it wouldn't apply to pages requiring (or otherwise using) custom images. Perhaps even better, we could take to setting some more user-specific configurations, and let a logged-in user automatically use their favored piece set when possible?

Fergus requested I use [abstract diagrams] Kevin Pacey

If I found the comments you're referring to, I wouldn't characterize it as a request, and I'm sorry if it came across as an editorial request. You should feel free to use whatever graphics you want. (I guess I should caveat that: we do strongly encourage using the site's tools when possible for consistency, and using piece graphics that are traditionally used for corresponding pieces.)

Since the Hostslayer website remains down, I do not know whether the HostSlayer account will continue after today. It might auto-renew and automatically charge me like it did last year, or it might not. Since I have a backup server with RackNerd, I will backup everything there and switch the DNS for chessvariants.com to point to the same place as chessvariants.org. It may take a while before this fully propagates.

I have been trying to get email to work there without success. I can send and receive internal email, but I have been having lots of trouble with external email. Once we start using the new server, I may need to fix some things.

By the way, details about programming are not clear for most people. How to deal with it?

I don't think there is any "fix" to this issue.  I am not sure there is any issue at all.  Some conversations are going to involve things other people don't understand.  That said, the talkchess forums are the usual place for these kinds of discussions, but I am happy to have some discussion here as well.  Some people who are not chess programmers may still be interested in whether the new neural-network techniques being applied to orthodox chess can be applied to chess variants.

I did not meant the typo!

What is not understandable? Typo! What else.
By the way, details about programming are not clear for most people. How to deal with it?

I'm not sure I understand what you say, HG!

Indeed. Hard to avoid typos on these virtual keyboards of Android devices... I corrected it.

I do not understand "tgat". You probably meant that.

That describes the 'policy head' of the NN, which is used to bias the move choice (which is otherwise based  on the number of visits of the move and that of the total for the node, and the move scores) when walking the tree from root to leaf for finding the next  leaf to expand. But my understanding was that when the leaf is chosen and expanded, all daughters should receive a score from the 'evaluation head' of the NN in the position after the move, rather than just inheriting their policy weight from the position before the move. These scores are then back-propagated towards the root, by including them in the average score of all nodes in the path to the expanded leaf.

The NN outputs a probability distribution over all the possible moves (illegal moves are set to 0 and the probabilities sum to 1). The MTCS call for this distribution, combine it with an exploration coefficient and Dirichlet noise, to form a score, and choses a move to expand until a certain number (in chess is 6000) of nodes have been visited. Nodes are expanded until leaf nodes are explored. This link explains it better than I:

https://joshvarty.github.io/AlphaZero/

I thought AlphaZero used the output of its NN for evaluating leaf nodes. That makes it different from 'normal' MCTS, which would randomly play out games until they satisfy a win or draw condition, and uses the statistics of such 'rollouts' as a measure for the winning probability in the leaf.

Thanks Greg, My conundrum comes from the definition of leaf nodes. In the traditional way you apply the evaluation function, but in the MCTS of Alpha zero are only when the endgame conditions apply.

A quick overview for those who are interested ... A traditional Chess program has 3 parts:

Move Generation - Given a position, find all legal moves for the side on the move.

Search - Recursively play out moves and counter-moves to find the best sequence (called the PV or Principal Variation.)

Evaluation - At the leaf nodes on the end of each search path, evaluate the position. This function returns a number - the more positive, the better for player 1, the more negative, the better for player 2.

Chess variants. To program a chess variant, you definitely need to change Move Generation. You probably also need to change the Evaluation function. If nothing else, at least give material values to the new piece types. This is the most pronounced of all the evaluation terms. But other things may need to be altered -- for example, pawn structure is important, but should not apply to Berolina Chess.

The Search is typically extended by something called a Quiescent Search. The Evaluation function cannot reliably detect pins, forks, hanging material, etc., which would all affect the evaluation a lot. So, the Evaluation function can only be used on "quiet" ("quiescent") positions. So after the search function searches all legal moves to the desired depth, it then hands off to Quiescent Search, which continues searching recursively, but searches only captures (and, in some programs, checking moves too, but this isn't common in chess variant engines.) This way, all exchanges in progress are played out and hanging pieces are captured before the position is evaluated.

So, with that background on Quiescent Search ... Remember how I said the Search function doesn't need to change for different variants? Well, that's not entirely true. For some variants, like Shogi (or other variants with drops), or double-move variants, there are no "quiet" positions. So traditional Quiescent Search doesn't work. Other approaches must be taken. ChessV doesn't modify the Search function for different variants at all. That's why it doesn't play Shogi. It does play Marseillais Chess, but I haven't modified the Search, I'm basically just sweeping the issues under the rug... I don't know how Zillions-of-Games works for certain, but I believe it has no Quiescent Search function at all. It modifies the Move Generator to support different games, but there is no variant-specific Search or Evaluation.

ChessV handles the Evaluation by building it from various elements that can be turned on, off, or configured. (Pawn structure, king safety, outposts, colorbinding, open file bonuses, castling rights, etc.) You can find out basically everything ChessV does for every game it plays by looking at the Game Reference: http://www.chessv.org/reference/games/

Well, it is a bit more subtle than that, because you would not know what line B leads to without searching it first. And after you have done that, it is too late to prune it. So what really happens if that after you have found the single reply to the first move of line B that leaves you stuck with the doubled Pawns, you consider the first move of B refuted, and you prune the remaining replies to it.

But you are right in the sense that positional characteristics can also be sufficient reason to reject a move. This is purely a matter of evaluation, though. Whatever search method you would use, it should in the end give you the line to the position with the best evaluation that you can force (the 'principle variation'). If there is no mate in view the evaluation of positions must be based on heuristics. Piece values are one such heuristic. In general one should base the evaluation only on features that are not easily changed. Otherwise it would be pretty meaningless, as you know the game must go on from there (even though it is beyond your capability to take into account what will happen then), and if the feature would in general not persist after the next move it is pointless to optimize it. But next to material composition pawn structure is definitely a persistent feature (with FIDE or Shatranj Pawns!). King safety as well, when the King is a slowly moving piece.

What you will have to consider in evaluation can indeed depend very much on the rules of the variant. Using a neural network for evaluation (as both AlphaZero and NNUE do) and training that on positions from games is a method to avoid having to think about that yourself; you hope the NN is clever enough to recognize the important features, and quantify their importance. Whether this leads to different pruning in alpha-beta search is of no importance; this kind of pruning is guaranteed to have no effect on the principal variation that will be found. With or without pruning this would be the same. The pruning is just an optimization to get that same result, which was fully specified by the evaluation of the tree leaves, without wasting time on lines that neither of the players would want to play.

From conventional chess engines it is known that pawns on the forelast rank, and king safety can have values comparable to the material value of a minor.

Hi H.G.

My memory/understanding may be off, but I thought if for a chess engine line A is at least = and line B results in doubled isolated pawns without compensation, then line B would be pruned out. It's not due to material loss (e.g. a pawn for nothing) but rather due to chess-specific knowledge (that doubled isolated pawns are bad if not compensated for). I could imagine a CV where the opposite might be true, depending on the rules of movement or topology of the board, i.e. where doubled pawns might be good (e.g. in a game of Berolina's Pawns).

The only moves that are pruned in an alpha-beta search are those whose score could not possibly affect the move choice at the root, because they are in a branch that has already been refuted. E.g. if you find that in a position that is at least equal (i.e. you have already searched a move that does not lose anything), and an alternative move has a reply that loses a pawn without compensation, you would consider that alternative move refuted. It would be a waste of time to continue searching other replies to the move, in order to determine whether these make you lose even more. Because losing a Pawn is already bad enough to dissuade you from playing that alternative move.

This is purely determined from the scores of the moves; you don't need any variant-specific knowledge for it.

Ok, HG, I could have misconstrued something. But from what I understand I'd have to cut some moves while doing the alpha beta search. For example, after a certain number of plies. And then do the classification learning. Have you said something else? Anyway, I was saying that I can use handcrafted features at input to the neural network.

What pruning? Alpha-beta search only prunes after a beta cutoff, and this does not require any knowledge about the variant.

I meant the pruning!

What do you mean? Alpha-beta search is always the same, no matter what variant it is used for. It does not even have to be a chess variant. As long as it is a deterministic 2-player game with perfect information it should work the same.

Actually, when programming a new game it is not easy to do alpha beta search. I was thinking to add some positional features (like moving the central pawns) to the input of the neural network. This should speed thinks up a bit.

A NNUE with an alpha-beta search is fine: Stockfish 15 is stronger than any other chess player in the world, either human or computer.

The main thing that is interesting with Alpha Zero is that it can play a super human game of chess with no human chess knowledge except the game's rules. So, for example, any opening or midgame strategy is has is not based on human play.

@HG, Thanks for not discouraging me. That matters a lot, thrust me. I'll then slowly train weak bots but stronger every time. Maybe in time hardware will become available. And also, who knows, better software ideas. Good luck!

Indeed such questions are more suitable for talkchess.com.

But the fact that the AlphaZero NN also has a 'policy head' next to the evaluation is not the largest difference. IIRC this is only a matter of the final layer, which calculates a preference for each possible move in the same way as the score of the position is calculated. (I.e. each move output is fully connected to the previous layer.)

The main difference is the size. The AlphaZero net is so large that even using a Google TPU or a fast GPU to calculate it slows down the engine by a factor 100-1000, in terms of positions/sec searched. The NNUE only slows the engine by a modest factor, even on a CPU, because it is so small.

@HG,

Yes, in my previous comment I was referring to the difference between neural net and the NNUE approach. Alpha Zero's neural net has 2 parts. A CNN feature extraction part and a fully connected classification part. In the NNUE, from what I understand, you keep only the second part. I have said that I did not fully understand how the CNN part works. I'm not sure what filters it uses. But I do not think this is a question for here anyway.

You will be already 5000 times slower by the fact alone that Google used 5000 servers, (if I recall correctly), and you only have a single PC. And each Google server contained 4 TPU boards, each capable of performing 256 (or was it 1024) multiplications per clock cycle, while a single core in a PC can do only 8. So I think you are way too optimistic.

I am not sure what your latest comment refers to. If it is the difference between AlphaZero and NNUE: the main point there is that the NNUE net uses 5 layers of 32 cells, plus an initial layer that can be calculated incrementally, (so that the size matters little). While the AlphaZero net typically has 32 layers of 8 x 8 x 256 cells.

I don't want to discourage you, but the task you want to tackle is gigantic, and not very suitable as an introductory exercise in chess programming. A faster approach would be to start with something simple (at the level of Fairy-Max or King Slayer, simple alpha-beta searchers with a hand-crafted evaluation) to get some experience with programming search, then replace its evaluation by NNUE, to get some experience programming neural nets. The experience you gain in the simpler preliminary tasks will speed up your progress on the more complex final goal by more than the simple tasks take. Also note that you will have the disadvantage compared to people who do this for orthodox chess of not having high-quality games available to train the networks.

@HG,

The alpha-beta search would have replaced the feature extraction part of the NN. That is from what I understand. That is the part I did not understood (especially what filters does the CNN use). Anyway even if it takes a huge amount of time the algorithm will still improve. So I could present a user with monthly updates. But I'm afraid it will take time until an challenging AI is outputed by the program.

Once again thanks a lot for your help!

Well hundreds of times slower it is not that but. 1000 times slower will be 4000 hours which is 167 days. That is doable. I have one computer for one game (2 in total, remakes of apothecary chess). But my games are 10x10 and have bent riders and an imitator which could itself make things much worse. There could be artifices in the beginning by inserting fake endgame conditions which will train things like "Do not exchange your queen for a knight!".

Anyway I'm doing this because it is the only thing that motivates me so far. With the new treatment (actually 3 years now), I am able to pay attention to stuff. I really enjoy doing this. And the programming is not that hard actually, although there are also NN things I do not understand.

@HG and @Greg Thanks for your advices!

It would be a few month when you had a few dozen computers with very powerful GPU boards as graphics cards. For orthodox chess.

But I should point out there is another approach called NNUE, which uses a far simpler neural net just for evaluation in a conventional alpha-beta search. This is far easier to train; for orthodox chess a few hundred-thousand positions from games with known outcome would be enough.

Pretty sure H. G. is correct. There is a reason I spend no effort on the neural network approach.

I'm aware of this fact, but I'm not sure about six years. Isn't it closer to a few months?

Also note that LeelaChess Zero, the imitation of Alpha Zero that can run on a PC, took about 6 months of computer time donated by a large collaboration of people with powerful computers to learn how to play Chess. For AlphaZero this only took 4 hours, but only by virtue of the fact that they used 5000 of their servers equiped with special hardware that calculated hundreds of times faster than an ordinary PC. On a single PC you would be lucky to achieve that in 6 years of non-stop computing.

Yes, Greg I'm sure you are correct. Moreover in this context it matters less. This is a training program. It can take more time to learn the game, but as HG has said, it is of little consequence.

A mistake most starting chess programmers make is trying to optomize these kinds of things. It is not a good use of your effort. Even if you double the computational speed of your program, that is only good for about 70-100 ELO. The important thing is being bug-free and the optimizaitons make things more complicated and introduce more bugs.

Thanks a lot, HG!

Virtually all chess programs generate moves completely from scratch in every new position they reach. So after 1. e4 (and the opponent's reply) they would generate all Knight moves again (and now Ng1-e2 would be amongst those), and would try to generate new Rook moves (again without getting any). What you mention would only be relevant if you wanted to generate moves incrementally, by deriving the new list of moves from one you already had, by adding some new moves, and deleting some old, but keeping most of them. This can be done, but for games with the complexity of orthodox chess is not very much faster than generating the moves from scratch. That is, it could be much faster, but it would be very complicated to achieve that. So no one does it. (I wrote a kind of blog about it on talkchess.com, though, under the title "The Mailbox Trials'.)

For larger variants (larger board, more pieces) the incremental method could become competitive, however. I used it in my Tenjiku Shogi engine ('Inferno'), and could reach a speed of 500k positions/sec, which is similar to what most engines for orthodox chess can do, despite the 4 times larger board and and 5 times as many pieces. One problem is that it would be quite hard to make it general enough to do many variants. The incremental method must figure out which slider moves are blocked and which discovered by the move that is searched. If all sliders move along orthogonals and diagonals (as they tend to do in Shogi variants, and certainly do in orthodox chess) it is still manageable, but if the variant also has bent sliders (like the Griffon) or hook movers (like in Maka Dai Dai Shogi) it becomes far more complex to figure that out. The area move of the Fire Demon and Vice General in Tenjiku Shogi is almost impossible to do incrementally, so Inferno generates that from scratch in every position.

Alpha Zero relies on an enormously large neural network for evaluating a position, and suggesting moves to search. This takes so much time to compute that the time to generate moves is completely negligible to it, no matter how inefficiently you do it.

@HG or @Greg

I'm writing my own chess variant program (I'm finally making progress) alpha zero style. When generating moves I can't help wondering about loss time due to regenerating the same moves after a move was made.

For example in orthodox chess after 1.e4 there appear a few more queen moves, but you shouldn't try again to check for rook moves. As of now my algorithm works this way an it is probably slow.

I would expect it to be weaker against more different pieces of roughly the same value. Because it allows the opponent more opportunities to do a move that makes the Imitator harmless in its current location.

While playing my 12x12 variants I have noticed that besides the material type owned by the opposite side, the imitator's power is also greatly affected by the number of different types the opponent has. What is your guys take on this?

Thanks for the reply Jean-Louis!

Hi Aurelian. I belong to those who are not at ease with NN. Same with DD or AA and all their compounds. I had tested once a FDD to finally give it up. But I agree that they can be used if the game is designed for, like yours. It also requires a certain anticipation from the players who are not used to, and this is precisely what I'm missing from my side.

This is probably because Vultures can easily be blocked. A Falcon, which also has 16 targets, empirically tested as about equal to a Rook. Th Vulture has 4 paths rather than 3, but each path can be blocked in 3 places rather than 2. The 4 non-capturing leaps add comparatively little.

The value estimate of the Diagram takes this into account by measuring the average number of moves in randomly generated positions where 25% of the squares are occupied.

@HG, By the way. The interactive diagram evaluates vultures less than 12 directions leapers such as the champion. Isn't this weird?

Thanks for the comments guys! Hopefully there are more to come.

@HG,

The awkwardness of nightrider I expect it goes away with sufficient play. Anyway computers don't "feel" it. But if the game is badly designed computer play will yield very biased results. At a practical level you need not have all heavier pieces 2 ranks behind a pawn and GAC A,C & M proves that. Just most of them. I guess there is reason for experimenting. Because this way you don't need to go all in with the theoretical approach.

I find nightriders difficult to visualize, even with the three-colored board, but despite that they seem to work well in the grand apothecary games since there are enough pawns and weaker pieces to block them.

In my opinion riders based on a leap other than a king step are very awkward to play with. That holds for NN, but also DD and AA. It is never intuitively clear whether the path between such a rider and a distant target is blocked, especially when the blocker is far from both. For me that makes them annoying pieces.

I guess the problems with tactically non-quiet opening positions can be avoided by putting all pieces more valuable than a Nightrider two ranks behind the Pawns. Then the Pawns will block any Nightrider attacks on them. And of course make sure all Pawns and pieces directly behind them start protected.

In my three games described below I have nightriders and even their compounds the unicorn and the varan.

https://www.chessvariants.com/rules/grand-apothecary-chess-alert

https://www.chessvariants.com/rules/grand-apothecary-chess-classic

https://www.chessvariants.com/rules/grand-apothecary-chess-modern

I have previously observed that games with nightriders are hard to design as their long jumpy forks are very difficult to stop. I remember seeing people over here thinking also along these lines but I can't remember who. I'm sorry.

For this exact reason I though that the nightriders are game breaking in my 3 games mentioned above. I have put them there because I have though them to be natural fairy pieces to be used. When first confronted with the final versions of the games I have feared that the black heavy pieces will be easily forked by white and in doing so creating an unhealthy advantage for black.

But last night I have played a few openings, in each of the games, by myself intentionally testing for this. I seems black can always defend somehow, by blocking or running, and then counter by attacking the advanced nightriders and gaining tempi on them. The games are thick enough so that early on nightriders are not such troublemakers anymore. Careful maneuvering of the nightriders should still be an important late opening- middlegame theme, but it does not seem to be that dangerously unfair then.

What do you guys think about games with nightriders in general?