Comments/Ratings for a Single Item

Fergus started working on Metamachy but I don't know where that sits.  I have been planning on taking a stab at Symmetric but haven't started yet.  I will make a concerted attempt probably starting tomorrow.  Aside from the tournament, this is one of the most played games on Game Courier so it should have a rule-enforcing preset.  Whether or not I succeed will depend on how difficult I find it.  The Bishop Conversion Rule is a little tricky and I find game courier code pretty difficult to work with.

I now have a working preset for Metamachy at this URL:

https://www.chessvariants.com/play/pbm/play.php?game%3DMetamachy%26settings%3Ddefault

Just to make sure everything is working, it could use some beta-testing before it's used in the tournament.

New Metamachy rule-enforcing preset: After brief testing of en passant and initial king move...

I was unable to make any en passant captures using white pawns on ranks 6, 7, and 8. I was able to make normal en passant captures with white pawns on ranks 4 and 5. More interestingly, I was able to make illegal en passant captures with white pawns on ranks 4 and 5. By illegal, I mean that: a black pawn that can be captured normally by a white pawn makes a double-move; White on his next turn is allowed to take that pawn en passant illegally. I was able to make legal en passant captures with black pawns on all squares tested. I was also able to make the illegal en passant captures with black pawns on all squares.

The initial king 2-square move doesn't seem to work.

Will keep testing...

With en passant, the bpr variable for Black's Pawn Rank had the wrong value. For the King's two-space leap, it was checking whether the destination was empty, which works only for potential moves, rather than checking whether a capture had been made. I have fixed these now, and you can test whether anything is still not working.

I just made some more fixes to how the King's two-step leap is handled in the stalemated subroutine, so that only legal moves are displayed.

I made some more fixes to the King's two-space leap in the subroutines for moving the King. They now give informative messages about particular reasons why an illegal move is illegal. Since I used restore to check whether the King was in check, I went back to checking whether the destination space was empty.

King 2-space leap appears to be in order. All legal en passant captures can be made. However, one is still allowed to make incorrect en passant captures.

For example, if a white pawn is on c4 and a black pawn on d5, if White plays c4-c6, the preset still allows Black (incorrectly) to take d5-c4 en passant, removing the pawn on c6.

So, after two rounds of play, the current tournament results are:

[Pos) Name, Pts, #Wins, BS, SB, Black wins]                             

1. Kevin Pacey, 5.5, 5, 11, 13.25, 3; 
2. dax00, 5, 5, 11.5, 11.5, 2; 
3. Carlos Cetina, 4.5, 4, 8, 10.75, 2; 
4. Fergus Duniho, 4, 4, 9, 9, 3; 
5. Greg Strong, 4, 4, 6, 6, 1; 
6. Adam DeWitt, 3, 3, 3, 3, 1; 
7. Jarid Carlson, 1, 1, 1, 1, 1; 
8. Aurelian Florea & wdtr2 & John Davis, 1, 1, 1, 1, 0.

Nice, thank you.  I will get the third round assigned this weekend.  Hopefully I will be able to get a rule-enforcing Symmetric Chess preset working by then but we might have to do without.

Ok, I think we'll be in business for a rule-enforcing preset for Symmetric.  I made some real progress.  The display of legal moves doesn't work yet (the legal move display makes it look like the bishop is a dragon horse), but it terms of what it actually allows, it looks like it is doing the right thing in all cases:

/play/pbm/play.php?game%3DSymmetric+Chess%26settings%3Drules

Greg:

I appreciate very much the effort you make to reinforce the rules of the Symmetric Chess preset, however I wonder if using the preset you suggest will not be more confusing for some people than if we used the entirely uncoded one.

I don't know; it's just a presumption, a guess. In my personal case, I would play without problems with any of those two options.

Certainly, coding the Bishops Conversion Rule is a tremendous challenge.

Hi Carlos,

Sorry, I did not mean to convey that I was done.  Only that I had made progress.  I intend to work on fixing the legal moves display today.

Okay, Greg, sorry for the misunderstanding. Thousand thanks and good luck!

Well, I don't know.  I thought I was getting there but apparently not.  Nothing behaves the way I expect and after about 8 hours of screwing around I've reached my limit.

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.

If anyone else wants to look, feel free.  Boiled down, the Bishop Conversion Rule really isn't that hard.  I'm tracking things with 8 flags:

wccanconvert wgcanconvert bccanconvert bgcanconvert wcmustconvert wgmustconvert bcmustconvert bgmustconvert

The first letter, w or b, indicates the player.  The second letter, c or g, indicates the start file of the bishop.  Then there are flags for can convert (which begin the game set) and flags for must convert (which are not set until the other bishop moves without converting.)

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.

Thanks, Fergus.  Unless I'm missing something, it seems my B subroutine already has all the logic.  Is there some reason I can't delegate def B to gosub B?  Seems odd I should need to describe all the same logic again but in a different way.

Got it!

def B
or alltrue checkride #0 #1 1 1 !== #0 c1 !== #0 g1
or alltrue checkride #0 #1 1 1  == #0 c1 not flag wcmustconvert
or alltrue checkleap #0 #1 1 0  == #0 c1 flag wccanconvert
or alltrue checkride #0 #1 1 1  == #0 g1 not flag wgmustconvert
or alltrue checkleap #0 #1 1 0  == #0 g1 flag wgcanconvert;

def b
or alltrue checkride #0 #1 1 1 !== #0 c8 !== #0 g8
or alltrue checkride #0 #1 1 1  == #0 c8 not flag bcmustconvert
or alltrue checkleap #0 #1 1 0  == #0 c8 flag bccanconvert
or alltrue checkride #0 #1 1 1  == #0 g8 not flag bgmustconvert
or alltrue checkleap #0 #1 1 0  == #0 g8 flag bgcanconvert;

I'll give the whole thing another lookover in the morning to hopefully make sure I didn't miss anything but I think everything is set.

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.

The description of the Bishop conversion rule says this:

" for one of the bishops of the player, the first move made with this bishop must be of this special type. "

I take this sentence to mean that if one of the Bishops gets captured before it moves, the other cannot start with a normal move. This doesn't seem very sensible, though, so I am not sure whether my interpretation is correct.

Just to contribute my two cents: when you would keep one flag per Bishop to indicate whether it had been moved (or per square whether the original occupant is still there), which really should be considered a standard feature automatically kept track of in any chess variant, (considering how many variants endow pieces with virgin-only moves), the game state can be ancoded with only a single other flag per player, indicating whether a conversion has already taken place. The rule for a virgin Bishop is then merely that he cannot convert when a conversion was already done, and otherwise must convert when the other Bishops is not virgin (or, since the rule is only applied on a virgin Bishop, when not both Bishops are virgin). Note that the type of move (W or B) can be easily tested from the color of the square ((x ^ y) & 1 if you have separate x and y coordinates, nr*9 & 8 for 0-63 square numbering on an 8x8 board, nr & 1 on 0-71 square numbering on 9x8).

The description of the Bishop conversion rule says this:

" for one of the bishops of the player, the first move made with this bishop must be of this special type. "

I take this sentence to mean that if one of the Bishops gets captured before it moves, the other cannot start with a normal move. This doesn't seem very sensible, though, so I am not sure whether my interpretation is correct.

I have asked Carlos about this and, if one bishop is captured before either has moved, then the other bishop may convert but is not required to.  I'll edit this page to make it a little more clear.

That certainly makes more sense to me. One could still wonder about the case where the first-moved Bishop does not convert, but is captured before the second moves. The situation this gives rise to is not really any different from the one where it was captured before it moved. And you would need extra game state to distinguish the two.

I guess you need extra game state anyway, because a Bishop can move and return to his starting square without converting. The other Bishop must then convert, but from the board position you cannot see which of the two is the 'other' Bishop.

Possibly the cleanest solution to everything is to implement this by piece-type changing: start both Bishops as Dragon Horses. When a Dragon Horse moves, it 'promotes' to Bishop, and as a side effect, depending on how it moves, the other Dragon Horse (which must still be on its starting square in that case if not captured), promotes, either to Wazir or to Bishop. If a Wazir moves it always promotes to Bishop. All game state is then encoded in the board position.

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.

Thanks, Fergus and Carlos.  I have jury duty this morning, but I will try to get the preset updated after.  But I've been sick and I'm not sure how long I will be there today so we'll see.

What about the continuation of the tournament? Are there any other games going on?

No, the games are complete.  Was finishing the preset for Symmetric, and now I've been sick for almost a week so the preset is still unfinished and next round games are still unmade.  Hopefully soon.

Thanks for the info!... I hope your health improves!...

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'. 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. 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.

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.

To catch more variants through the wizard it could allow a general input screen for specifying castling rules: the location of the castling partner, where it and the King will end up after castling, which squares must be empty and which squares must not be attacked. (And allow that to be repeated as many times as possible.)

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.

Personally, I would recommend putting the breaks on this conversation as nothing productive will come from it.  Comments of the "your website is lame, you really need blah, blah, blah" variety are a dime a dozen and should be treated as such.

Yes, it could be better, but that describes everything in the world.  We're volunteers with limited time.

Well, perhaps I would be less alarmist when I knew how many of these 1300 presets are actually rule-enforcing. (Or more, as the case may be...) And if the result of a discussion could be that this number could easily be raised to 1300 I would consider that 'productive'. One should never set one's aim too low, nor give up too easily.

That we are volunteers with limited time is all the more reason not to scare people away that could improve something.

And the Bishop conversion rule is not so exotic. It is just an example of a special kind of 'initial move', which does not work per individual piece, but per piece type. Perhaps such a thing deserves to be a standard option offered by a wizard, whenever one defines an initial move on a piece type. Like "can be made by all / can be made only once / can be not made only once".

Any news on continuing the tournament?!

I guess everyone has probably noticed that the site is back, but I am not sure it is a good idea to start right before the Christmas break since people may be travelling or spending time with family.  Unless there is objection, I will plan to start the final games in one week on Saturday, Dec 28th (EST).

Great!

The Metamachy preset still allows illegal en passants. This shouldn't really be a problem, since it's doubtful that anyone would even attempt to play such a move, but still...

Can you show me a sample game that ends in a position in which an illegal en passant is allowed?

1. skip; 
1... k h7-g12; l e7-f12; g f7-g11; q g7-f11 
2. P f3-f5 
2... p g10-g8 
3. P f5-f7 
3... p g8-g6 
4. P f7-g8

That's now fixed. The original code was based on Chess, which didn't allow en passant from multiple ranks. I replaced the requirement that the capturing pawn cannot move into or beyond the enemy's pawn rank with the requirement that the capturing pawn must be moving from the same rank as the double-moved pawn just moved to.

It's not so much that it was based on code for Chess. Rather, it was based on code that had been adapted to handle en passant for initial pawn moves that are longer than two spaces. Since this game allows pawns unlimited double-moves instead, en passant had to be handled differently. Either way of handling en passant is compatible with Chess, but en passant has to be handled differently in Omega Chess than in Metamachy.

The games for round 3 have been assigned.  Enjoy!

The whites/blacks for Metamachy seem to have been incorrectly assigned.

Hmmm... The colors are backwards, but the first move is also backwards in this game.  (Black moves first.)  So the side that should have first move advantage does get to move first.  Unless you think that the "placing pieces" phase shouldn't count as a move, in which case the side that does not have first move advantage would actually get to play first anyway.  I'm surprised Game Courier assigned it the way it did, but it does kinda make sense.  I'm not inclined to delete and recreate them unless others feel strongly about it.

As long as White wins in Metamachy get credit towards the "Black wins" tiebreaker, I have no further objection.

That seems fair to me

My opponent Jarid Carlsson is not moving!...

I have sent Jared an email.

So far Adam has not moved in my game with him, either.

Ok, I have emailed him too.

I do not see any of the tournament games assigned to me. Make sure you used chessshogi instead of ChessShogi, otherwise I will not see the game. I'll put that in my about page for future reference.

I managed to find my games using an advanced search with my userID as ChessShogi and the tournament as GameCourier2019. For anyone that can't find their games, try using an advanced search, putting your ID exactly as it is (not all-lowercase) in the userID field and GameCourier2019 in the Tournament field. If any results pop up, make a move in each. After you have made your moves, the games will appear on your My Games on Game Courier page as normal.

Nice.  Thanks for tallying! And congratulations!

Congratilations for the winner and the medalists!...