Check out Symmetric Chess, our featured variant for March, 2024.

Enter Your Reply

The Comment You're Replying To
H. G. Muller wrote on Thu, Feb 28, 2013 09:08 PM UTC:
Fairy-Max would have no problem with some of these. Asymmetry is no problem per se, as the move in every direction has to be defined separately.Long-range leapers (bison) is also no problem; any board step is possible on 8x8 (a large lateral step could limit board width, to prevent the piece from jumping over the guard band, and wrapping around the side edges of the board, but 16-stepSize is still possible). Nightriders could lead to some instability, if the search encounters positions where mutual perpetual check is possible. (This means the program would occasionally hang, and lose on time.) I am not sure this is even possible in theory when there is only a single Nightrider present.

As to promotion: Fairy-Max is programmed to promote pieces number 1 and 2 when they reach last rank. It does not matter how these move. If that is not enough, a simple change in the code could make a different number of pieces promote. It would be a bit tricky to make them all promote into different types (but doable). It should hardly matter for the value of a piece to what exactly it promotes, however. Promoting to a piece of approximately the right value should be enough.

Bent riders is currently not possible, as are pieces with a minimum range. They are basically the same thing. It should be possible to patch the code to do those, though. The current system is based on toggling a given set of bits in the initial move step & rights to get secondary step & rights. For non-hoppers this happens after every step, but I just made a change to allow suppression of that for the first 1, 2 or 3 steps, to do the limited-range sliders. After that (as the range counter gets negative) it would toggle every step again. But the code can be trivially changed to only toggle when the counter is zero. This one-time toggle could then switch a primary step with neither capture nor non-capture rights after a certain number of steps to a secondary step with rights for both capture and non-capture. Or it could change the direction of the step. This patch would lose the possibility to do Crooked Bishop or Mao-Rider and such. (But who cares?)

Piece drops are out of the question. For those it would be easier to modify a Shogi program. I would think that also holds for 'swap pieces'. They would need move generation that does not fit at all in Fairy-Max' table-driven system of looping over directions and distance for every piece. You would have to loop over the board in stead, looking for friendly pieces, and to perform the move the occupant of the target square, which normally would be captured, would have to be moved back to the from square. (OK, perhaps this part can be made standard for 'capturing' own pieces.) 'Rifle Chess' pieces would also require a different MakeMove and UndoMove procedure, which now consists of clearing away the captured piece (which for e.p. capture could be somewhere else), clearing the from-square, and putting the moved piece on the target square (possibly promote it there). And for UndoMove clear the target square, put the original piece on the from-square, and put back the captured piece. I guess that when 'shooting' a piece, you would have to skip the second and third part of the MakeMove, based on some new (or redefined) move-rights flag. Or fool it by forcing the target square used during MakeMove to become the from-Square, so that it becomes sort of an e.p. null-move. This might be doable, after all. The challenge is how to preserve the info that this has to be done if the move is not generated from scratch, but the best move of a previous iteration (possibly passed through the hash table).

Capturing mid-move also seems hard. Perhaps this can be done by changing the hopper code (removing the platform, and only allow hops if it is an enemy. If you can do double captures this way, it requires even more code changes (to remember the secondary victim, but not impossible).

So I guess most of this can be done by making dedicated versions by modest patching. But it can't be done all at the same time. (But this is probably not really needed; as long as you don't want to implement complete games.)

Edit Form

Comment on the page Buypoint Chess

Quick Markdown Guide

By default, new comments may be entered as Markdown, simple markup syntax designed to be readable and not look like markup. Comments stored as Markdown will be converted to HTML by Parsedown before displaying them. This follows the Github Flavored Markdown Spec with support for Markdown Extra. For a good overview of Markdown in general, check out the Markdown Guide. Here is a quick comparison of some commonly used Markdown with the rendered result:

Top level header: <H1>

Block quote

Second paragraph in block quote

First Paragraph of response. Italics, bold, and bold italics.

Second Paragraph after blank line. Here is some HTML code mixed in with the Markdown, and here is the same <U>HTML code</U> enclosed by backticks.

Secondary Header: <H2>

  • Unordered list item
  • Second unordered list item
  • New unordered list
    • Nested list item

Third Level header <H3>

  1. An ordered list item.
  2. A second ordered list item with the same number.
  3. A third ordered list item.
Here is some preformatted text.
  This line begins with some indentation.
    This begins with even more indentation.
And this line has no indentation.

Alt text for a graphic image

A definition list
A list of terms, each with one or more definitions following it.
An HTML construct using the tags <DL>, <DT> and <DD>.
A term
Its definition after a colon.
A second definition.
A third definition.
Another term following a blank line
The definition of that term.