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


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments by FergusDuniho

LatestLater Reverse Order EarlierEarliest
Games on Game Courier. A listing of Chess variants for Game Courier, ranked by number of times played.[All Comments] [Add Comment or Rating]
🕸📝Fergus Duniho wrote on Sat, Nov 23, 2019 05:53 PM UTC:

We have had some very active non-programmers making presets. While this page won't tell you which are programmed, you can go to /play/pbm/settings.php to get some idea of that. If interested programmers want to program games that haven't been programmed yet, that would be very helpful.


Game Courier Tournament 2019. Chess Variant Tournament to be played on Game Courier.[All Comments] [Add Comment or Rating]
🕸Fergus Duniho wrote on Fri, Nov 22, 2019 05:09 PM UTC:

That it takes so much effort even by seasoned chess programmers to create a rule-checking preset for a variant as simple as Symmetric Chess firmly puts us in the category of 'backward websites'.

That's alarmist thinking. Greg may be seasoned in C and C#, but he's still less experienced with GAME Code, which happens to be a very different language.

We really should have some kind of wizard for this, where people that cannot program at all would have no trouble to create such a preset. E.g. something like the Design Wizard for Interactive Diagrams I put in the article on those.

Non-programmers can already create presets, and even with limited programming knowledge, someone can create a programmed preset for many games by copying code from others and making a few tweaks. Thanks to this, there are presets for over 1300 games.

Where you just have to take a minute or so to specify board dimensions and size of promotion zone, pick a preferred graphics theme, tick a number of pieces in a list of standard types (or, very rarely, pick an image and specify a non-standard move for it by hand), drag the pieces to their initial locations on an empty (a specified symmetry taking care of you having to do that for only one member of each type), and you are done.

None of that was anything Greg needed a wizard for. The hold-up was in programming the Bishops Conversion rule, and in trying to do that, he learned more about how the language works. I already knew how to program it myself, but I intentionally left Greg the exercise of figuring it out, because I trusted he could handle it, and doing it himself would help him learn the language better.

If the wizard produces the usual game code, (just as that for the Interactive Diagrams produces the HTML), it will remain possible to take care of any features not suported through the wizard by editing the automatically generated game code later. But this should be needed only very rarely.

Like, for example, in Symmetric Chess, because the Bishops Conversion rule wasn't already programmed.


Home page of The Chess Variant Pages. Homepage of The Chess Variant Pages.[All Comments] [Add Comment or Rating]
🕸📝Fergus Duniho wrote on Mon, Nov 18, 2019 07:01 PM UTC:

The old version was probably still cached. I have purged it from the cache for you.


Chess Variant Inventors. Find out which inventors have the most games listed here.[All Comments] [Add Comment or Rating]
🕸📝Fergus Duniho wrote on Mon, Nov 18, 2019 04:13 PM UTC:

BTW, it seems my productivity is overrated in the list above: it says I invented 13 variants, but it attributes Wa and Tenjiku Shogi to me, while these are just historic Japanese games for which I made a rule-description page. (I also made such pages for Chu, Dai, Dai Dai and Maka Dai Dai Shogi, Paco Shako and Metamachy, but these were (justly) not attributed to me.) It also counts my article on FairyGen as a game invention, while this is just a description of a piece of software for generating End-Game Tables involvng fairy pieces.

It's now down to ten. I took care of the two Shogi variants, and FairyGen already wasn't listed.


Game Courier Tournament 2019. Chess Variant Tournament to be played on Game Courier.[All Comments] [Add Comment or Rating]
🕸Fergus Duniho wrote on Mon, Nov 18, 2019 01:17 AM UTC:

Here are some optimized versions of the B and b functions:

def B 
== #0 c1 
and flag wccanconvert 
or and == #0 g1 flag wgcanconvert
and checkleap #0 #1 1 0
and empty #1 
or and checkride #0 #1 1 1 or color #0 nor flag wcmustconvert flag wgmustconvert;

def b
== #0 c8 
and flag bccanconvert 
or and == #0 g8 flag bgcanconvert
and checkleap #0 #1 1 0
and empty #1 
or and checkride #0 #1 1 1 or not color #0 nor flag bcmustconvert flag bgmustconvert;

These do the regular Bishop move first, because that's what the Bishop will do most of the time. This can be done when neither mustconvert flag is set or when the Bishop is on the opposite color from the one it starts from. So, if a White Bishop is on a dark square (color = 1), or a Black Bishop is on a light square (color = 0), it can move as a Bishop. Testing for color #0 is quicker than testing for == color #0 1, and testing for not color #0 is faster than testing for == color #0 0, though they are a little bit more obfuscated. With regular Bishop moves out of the way, the function uses a series of breaking conditions to test whether a conversion move is possible. It first tests for conditions common to both conversion moves, testing for the less expensive one first. Also, given that these functions will frequently be used in testing whether a Bishop is attacking a King, including empty #1 as the first condition of the conversion move saves it from the trouble of checking for anything else when used for that purpose. It then tests whether it is legally converting from the g square, and if not, it uses a series of breaking conditions to test whether it is legally converting from the c square.


🕸Fergus Duniho wrote on Sun, Nov 17, 2019 03:43 AM UTC:

These look like they will work, but they could be optimized better. They repeat the same operations multiple times, and they don't evaluate the most common type of move first. Also, the first or in each, which is the one to be evaluated last, is unnecessary.


🕸Fergus Duniho wrote on Sun, Nov 17, 2019 01:36 AM UTC:

I don't know exactly what the issue is (and there could be more than one) but part of it seems to revolve around the fact that the rules for Bishop moves are complicated, and I've codified them nicely in subroutines "B" and "b", but the architecture seems to want the 1-line fn defs, which don't seem to support if-then-else, and my attempts to have a def B pass off to a gosub B doesn't seem to work either.

I tried out your Symmetric Chess preset. The conversion rule seems to be enforced correctly, but conversion moves are not displaying as legal moves, and when a Bishop must convert, it is incorrectly displaying illegal moves as legal. As you correctly surmise, this is because you do not have the b and B functions defined.

While functions do not support if-then-else, as such, they do support cond, which works like the ? and : operators. They can also use and, or, nand, nor, onlyif, and unless. You can look at the functions for other divergent pieces, such as the Pawn or the Cannon, for examples of how to handle this. Here are some examples from chess3. If you understand the logic behind these, you should be able to figure out how to handle the Bishops conversion rule.

def C cond cond empty #0 capture (not empty #1) (checkhop #0 #1 0 1) (checkride #0 #1 0 1) and #1;

def P
remove var ep
and < rankname #1 var bpr
and < rankname var ep rankname #1
and == filename var ep filename #1
and checkleap #0 #1 1 1
or and checkride #0 #1 0 1 == rankname #0 var wpr
or checkleap #0 #1 0 1
and empty #1
or and islower space #1 checkleap #0 #1 1 1
and <= distance #0 #1 var fps
and > rank #1 rank #0;

Remember that Game Courier evaluates functions from right to left, and many of the logical operators will work with either one or two operands. In the Pawn example, the logical operators are normally taking only one operand. When and receives a lone true value, it lets the function continue silently, but if it receives a false value, it returns a false value and exits. When or receives a lone false value, it lets the function continue silently, but if it receives a true value, it returns a true value and exits. If you still need more help, just ask.


Marseillais Chess. Move twice per turn. (8x8, Cells: 64) (Recognized!)[All Comments] [Add Comment or Rating]
🕸Fergus Duniho wrote on Sat, Nov 16, 2019 05:29 PM UTC:

Since you brought up the rule in Shogi against checkmating a King in Shogi with a Pawn drop, I checked how I handled it in Game Courier. I handled it similarly. After checking for checkmate in the Post-Game code, my code checks whether the checkmate was due to a Pawn drop, and if it was, it reports an illegal move instead of concluding the game.


Caïssa Britannia. British themed variant with Lions, Unicorns, Dragons, Anglican Bishops, and a royal Queen. (10x10, Cells: 100) [All Comments] [Add Comment or Rating]
🕸💡📝Fergus Duniho wrote on Sat, Nov 16, 2019 05:19 PM UTC:

Done, and I moved the ASCII diagram to the ALT text of the image.


Marseillais Chess. Move twice per turn. (8x8, Cells: 64) (Recognized!)[All Comments] [Add Comment or Rating]
🕸Fergus Duniho wrote on Fri, Nov 15, 2019 04:16 PM UTC:

Is there any French speaker here who can provide an accurate English translation of this? Google translate is not good enough to make it clear.

Les échecs marseillais sont une variante du jeu d'échecs où chaque joueur joue deux coups à la suite. En plus des règles du jeu normales, les joueurs doivent respecter les règles suivantes :

  • Un joueur en situation d'échec doit parer l'échec au premier de ses deux coups.
  • Si un joueur fait échec au roi au premier coup, il perd la faculté de jouer son deuxième coup.
  • Si après avoir joué son premier coup, un joueur se trouve dans une situation où il lui est impossible de jouer un coup légal, il est déclaré pat.
  • La prise en passant doit être effectuée au premier coup sauf si deux prises en passant sont possibles. Dans ce dernier cas, les deux prises en passant peuvent être effectuées à chacun des deux coups.
  • L'avance de deux cases des pions depuis leur position initiale ne peut pas être considérée comme un coup double (avance de deux fois une case). Donc le joueur peut jouer ensuite son deuxième coup.

🕸Fergus Duniho wrote on Thu, Nov 14, 2019 09:20 PM UTC:

Aside from trying to reconstruct the original Marseillais Chess, I would like to propose a game I might call Simplified Marseillais Chess, which is designed with programming it in mind. It would follow the rule of Balanced Marseillais Chess of giving White only one move at the start of the game, it would allow en passant capture only of a Pawn moved on the last part of a player's turn, it would have a turn end with one move if there were no legal moves to follow it, and it would work with normal stalemate and checkmate on a player's first move. I think those are the main differences from regular Marseillais Chess. Is there anything I have overlooked?


🕸Fergus Duniho wrote on Thu, Nov 14, 2019 08:33 PM UTC:

One more question remains. While the rules seem to allow for second-order stalemate when the King is not in check, what about when the King is in check? Should this count as checkmate or stalemate? From the understanding that checkmate is check plus stalemate, we could argue that check plus second-order stalemate is also checkmate. Or, we might argue that the ability to escape check, even if no follow-up move is possible by any means of escaping check, constitutes only stalemate. Here's an example:



🕸Fergus Duniho wrote on Thu, Nov 14, 2019 08:27 PM UTC:

Here's an example of what I'm calling a second-order stalemate. Black is not in check but has only one legal move.



🕸Fergus Duniho wrote on Thu, Nov 14, 2019 05:59 PM UTC:

For the sake of testing some endgame positions as I write the code, here is a game where I played both sides just to get a stalemate position.



🕸Fergus Duniho wrote on Wed, Nov 13, 2019 08:10 PM UTC:

I think I figured out how to interpret the rule in a way that uses stalemate but avoids the problem of letting a player deliberately move into stalemate. This is the interpretation that if a player does not have any combination of two legal moves, the game ends in stalemate at the very beginning of his turn. I could do it like this. After checking for regular check and stalemate in the Post-Game sections, I could try out the available legal moves to see if any are followed by legal moves, stopping as soon as I find at least one. For this, I would use a subroutine that returns false as soon as one legal move is found and does not take the time to go through all possible moves and calculate a list of legal moves. Since there are plenty of legal moves when lots of pieces are on the board, and a position without any combination of two legal moves would be most likely in a position with few pieces left, there should not be a heavy computational load for doing this.


🕸Fergus Duniho wrote on Wed, Nov 13, 2019 04:50 PM UTC:

I don't know if the interface already commits the user to the first move after he entered it. If not, and he can still take it back, you don't really have to do anything.

This comment popped up while I was writing my last one. The interface does not commit a user to a move until it is complete.

Whatever he does for the second move will be rejected as illegal, so sooner or later he will decide to try another first move.

That's how it currently works. A player without any legal move on his second move is unable to proceed and must go back and make a different move to complete his move. The problem comes in when a player has only one legal move, and that puts him in a position without any more legal moves. In that case, the player is unable to move at all, and all he can do is resign or wait for the clock to time out. I would rather have something cleaner than that.


🕸Fergus Duniho wrote on Wed, Nov 13, 2019 04:44 PM UTC:

Using the Zillions-of-Games version of Marseillais Chess by Young-Hyun Joo, I moved pieces until I got a position where one side used the first move to move into a position with no second move. When I tried to move again, it declared the game a draw.

While I generally don't like the idea of a player being able to draw a game by stalemating himself, it is also a difficult thing to do until the endgame, and giving each player two moves should normally allow the player who is ahead to force checkmate all the more quickly. So, in this game, it may mitigate the greater advantage of the player who is ahead and give the player who is behind greater hope of being able to draw the game without really making the game too drawish.

This rule comes from a reading of Pritchard, and given how he mangled all of my games that ended up in the revised version of his Encyclopedia, I don't trust him. But he is also the only source I have. I would like to find the article written by Fortis, but it may not be on the web. Since I don't have a serious objection to it, and since it is computationally less expensive than some other options, I'll probably go with it unless someone has a more authoritative historical source than Pritchard.

Checking how en passant works in the same Zillions script, it works as I have programmed it except that it allows the capture of two pieces when a piece has moved to the space a pawn just passed over with its double move. I suspect that if capturing two pieces at once were allowed, this would have been mentioned explicitly in the rules. My interpretation is that since en passant means "in passing," the idea is that an en passant capture happens during the pawn's move and not after another move. In that case, the new piece would not yet be on that space when the en passant capture actually happens, and a double capture would not be possible then. Given this, a pawn who captured by en passant on that space should itself be captured, leaving the piece that moved to that space still standing. But this would overcomplicate the game, and it is easier to say that moving the piece there caused the enemy pawn to lose its chance to capture by en passant but compensated for this by giving it another piece to capture. So, I don't support allowing double captures.


🕸Fergus Duniho wrote on Wed, Nov 13, 2019 03:02 PM UTC:

I hadn't thought of that interpretation, but it is more computationally complex than the ones I was considering. It would involve testing a position for legal moves, then trying out each legal move and testing it for legal moves until at least one legal move is found. Also, I normally handle checking for stalemate in the Post-Game sections to minimize its computational cost, but if a move were to be illegal if it had no follow-up move, the code would have to check for double levels of stalemate in the Post-Move sections, and that would significantly raise the computational load of the code.

The two interpretations I was considering were to allow only one move when no second move is legally available or to end the game in a draw when a second move is not available. Another alternative would be to end the game as a loss for the player who does not have a second move available. This would discourage players from deliberately stalemating themselves just as well as making it illegal would, and it could be done with far less computational complexity.


Game Courier History. History of the Chess Variants Game Courier PBM system.[All Comments] [Add Comment or Rating]
🕸💡📝Fergus Duniho wrote on Tue, Nov 12, 2019 10:17 PM UTC:

I have added an Advanced section to the Edit form. This includes a couple options that can be checkmarked. One of them was already included in the Edit form. The new one is the option "Do Not Include Moves in Code." For most games, this option should not be checked. And for unprogrammed games, it should never be checked. It's useful if you handle the execution of moves within your code. What this does is stop Game Courier from automatically adding the moves in a game to the code it generates for the game. If your game is not programmed, the result is that moving pieces will not work.

I added this option, because when I castled in Marseillais Chess and then tried to move the Rook that had just castled, it wouldn't let me, giving me the error message that the Rook was not on the space I was trying to move it from. I realized this was happening, because it would automatically execute all the moves before evaluating any of them. But I didn't need to include that in my code, because my code for Marseillais Chess would normally undo the latest moves, then replay them individually. Given that it was already doing that, I could just remove the moves it was undoing. So, I added the option to remove them.


Marseillais Chess. Move twice per turn. (8x8, Cells: 64) (Recognized!)[All Comments] [Add Comment or Rating]
🕸Fergus Duniho wrote on Tue, Nov 12, 2019 10:05 PM UTC:

One more issue has come up. Suppose that a player makes a first move that leaves him with no legal second move. Does this end his turn like a checking move would, or does it end the game in a draw? Pritchard says in Popular Chess Variants, "A player who is not in check and cannot complete his turn is stalemated." This suggests the latter, but he could have said it more explicitly if that is what he meant. Is there any consensus on how being unable to move on the second move should be handled?


🕸Fergus Duniho wrote on Tue, Nov 12, 2019 04:29 PM UTC:

What I cannot imagine is that the original inventor would have thought it reasonable to allow e.p. capture

  1. when the capturing Pawn has not seen the other one move past it
  2. when the Pawn that moved is no longer there
  3. when the e.p. square gets occupied

That's all reasonable, and what I've coded for Game Courier is in conformity with it. The first one is already handled by the rule that en passant is not allowed on the second move unless the player is making two en passant captures. This prevents a player from using his first move to move a Pawn into position to do an en passant capture. (Note that a Pawn that was already in the position to do this could just capture the double-moved Pawn normally and then use its second move to go to the space the now captured Pawn had passed over, reaching the same position without using en passant.)

The second is handled by setting the ep1 variable to false whenever a player moves the same Pawn again. Since ep1 would store the position of the previously moved Pawn if the last move were a Pawn move, it checks whether the second move is from that location.

The third is handled by checking for a normal capture before checking for other types of Pawn moves. If the move is a normal capture, it never gets to the code for en passant. If it's not a normal Pawn capture, then the move was to an empty space. By the time it reaches the elseif clause for en passant, it has already been determined that the space is empty.

 


🕸Fergus Duniho wrote on Tue, Nov 12, 2019 02:54 AM UTC:

So if the player moved a pawn two spaces and the placed a piece on the square passed over you would allow capture of both with a single move? 

The way it is coded, that would not happen. The first thing it checks for is an ordinary diagonal capture. If the move involves one, that's what it does, and it doesn't get around to checking for an en passant move.

I have started to look at the thread you provided a link to, and I will continue to look at it tomorrow.


🕸Fergus Duniho wrote on Mon, Nov 11, 2019 08:26 PM UTC:

The earliest source I can find is Pritchard's 1997 Encyclopedia, which is the source Hans originally used to write this page. It says "En passant is legal if the opponent moved a pawn two squares on either of his moves but the capture must be made at once. However, if the opponent made two two-square pawn moves, both pawns can be taken e.p. This last rule is credited to Alekhine by F. Palatz in an article on the subject (LEC Sep 1928)." LEC refers to L'Echiquier. Notably, Alekhine is not one of the inventors, and how the game should handle en passant might be something that the original inventors didn't think of. It is also unknown whether the game was invented by Fortis or by de Queylar. It has been attributed to each one, but its origins are murky.

Regarding one of the alternative rules, it says "The game was sometimes played with alternative rules: a check on the first move was illegal and a player could not capture e.p. if the pawn had been moved in the first part of the player's turn." It's very possible that Fortis and de Queylar invented similar games with slightly different rules that eventually got conflated together.

The rule that Greg Strong and H. G. Muller propose has the advantage of being the simplest to program. It works with code that has already been written for Chess. Of course, the original inventor of the game would not have had this in mind, since programming games was not an option when it was invented. However, the rules as initially described above can be programmed, and that's what I have done in Game Courier. The only issue with them is that they need emendation for a Pawn that moves twice on the same turn. If we keep those rules, then en passant capture should be impossible in this instance, or it should be allowed for the Pawn on its new space. I have the former programmed right now, whereas the latter would be trickier to program.


🕸Fergus Duniho wrote on Mon, Nov 11, 2019 04:37 PM UTC:

I changed it to allow en passant only when the Pawn's double move is a player's second move, and I confirmed that this change did not break any past game. But as I was rewriting the rules, one more thing occurred to me. Suppose a Pawn's double move done on the first move puts a King in check, thereby ending the turn without a second move. If this check could not be ended with an en passant capture, this could allow a King to be checkmated in a position that would not be checkmate in Chess, and this would violate the intention behind the game.

So, I think we have to exclude the rule that en passant is allowed only when a Pawn makes a double move on the second move of the turn. This could be replaced with the rule that en passant is allowed only when the double move was the opponent's last move, or it could be replaced with the rule that en passant is allowed only when the Pawn that made a double move didn't make another move after it. For the meantime, I'll change it back to the latter.


🕸Fergus Duniho wrote on Mon, Nov 11, 2019 02:28 AM UTC:

While fixing a bug in the Game Courier code, I came across a situation that is not clearly covered by the rules. Suppose a Pawn makes its usual first-move double move, then it moves forward one more space on the same turn, so that it moves a total of three spaces forward. Can it be captured by en passant if the opponent has a Pawn in the usual position? On the one hand, it has made a double move, and a Pawn that makes a double move can normally be captured by en passant. On the other hand, it is no longer on the space it moved to when making its double move, and if the player had wanted to, he could have moved the Pawn forward one space, then captured the Pawn that was in a position to capture it by en passant if it had made a double move.

For now, I have written the code to forbid en passant capture in this situation. Does anyone know if there is any precedent for allowing en passant capture in this situation?


25 comments displayed

LatestLater Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.