Comments by FergusDuniho

There are a few problems with the name Popess:

1. Unless you're counting Pope Joan, there has been no such thing.
2. Presumably, there would be only one Popess if there were one, because it would be a female Pope, but your game gives each player two of them.
3. The word derives from a word meaning father. Presumably, the word for a female equivalent of a Pope should derive from a word for mother.

Here are some possible alternatives:

• Mother Superior - the highest rank reached by nuns in the Catholic Church.
• High Priestess - a common term for a high ranking female cleric, and it is used in the major arcana of the Tarot.
• Bokononess - a made-up word formed from the name of a fictional religion portrayed in Kurt Vonnegut's novel Cat's Cradle.

Judging by the diagram, this is the Korean version of the Leo, which combines the Cannon and Vao from Chinese Chess.

In modifying the form for customizing the appearance of the board for an ongoing game, all form elements were disabled, and it took me a while to figure out what to do. That clued me in that it wasn't working in an intuitive manner. So I changed how it works. Instead of expecting you to choose the Custom theme before you can change the appearance of the game, any change to a form element for changing the appearance automatically changes the theme to Custom. As long as your theme remains set to Custom, the changes you make will be accepted. If you change your theme after starting to make custom changes, it will go with the theme and ignore the other values you set for changing the appearance. I added fields for choosing the color of Black and White pieces. However, I have not integrated these into themes.

But the anti-aliasing causes pixels on the boundary of the black outline and the colored interior to be darker versions of the interior color, by mixing in the black. So simply looking for an exact match of the original color fails to replace the boundary pixels.

I already took that into consideration.

This problem can be solved, though: you could test every pixel for the value of the brightest RGB component, and deduce from that by which factor it is darkened compared to the interior color. And then darken the replacement color by the same factor.

Here's what I'm doing. I collect all the color indexes. For each color index with a non-zero alpha value, I make a determination of whether it belongs to the outline of a piece or to its coloring. I do that with this conditional:

if (color_diff(array($cv["red"], $cv["green"], $cv["blue"]), $original) 
<= color_diff(array($cv["red"], $cv["green"], $cv["blue"]), "black")*2) {

The color_diff function returns the greatest difference between one color's minimum component value and the other one's maximum component value. I added the *2 to prevent some errors, and that part now seems to be working well. If it belongs to its coloring, I recolor each RGB component with this function:

function recolor_component_as ($originalvalue, $currentvalue, $newvalue) {
    if ($originalvalue == 0)
        return $newvalue;
    return min(255,round($newvalue*($currentvalue/$originalvalue)));
}

One remaining problem is that when I try to color the Black pieces white, I get an aquamarine fringe around the Black Motif pieces. In this case, $originalvalue will be 255 for the red component and 0 for the green and blue components, and $newvalue will be 255 for all three components. So, it recolors some edge pixels with positive values for green and blue but with 0 for red, resulting in aquamarine. So, I might have to factor in the value of each component when deciding how to recolor each component. But when I tried that earlier, I got some undesirable results.

But the anti-aliasing causes pixels on the boundary of the black outline and the colored interior to be darker versions of the interior color, by mixing in the black. So simply looking for an exact match of the original color fails to replace the boundary pixels.

I already took that into consideration.

This problem can be solved, though: you could test every pixel for the value of the brightest RGB component, and deduce from that by which factor it is darkened compared to the interior color. And then darken the replacement color by the same factor.

Here's what I'm doing. I collect all the color indexes. For each color index with a non-zero alpha value, I make a determination of whether it belongs to the outline of a piece or to its coloring. I do that with this conditional:

if (color_diff(array($cv["red"], $cv["green"], $cv["blue"]), $original) 
<= color_diff(array($cv["red"], $cv["green"], $cv["blue"]), "black")*2) {

The color_diff function returns the greatest difference between one color's minimum component value and the other one's maximum component value. I added the *2 to prevent some errors, and that part now seems to be working well. If it belongs to its coloring, I recolor each RGB component with this function:

function recolor_component_as ($originalvalue, $currentvalue, $newvalue) {
    if ($originalvalue == 0)
        return $newvalue;
    return min(255,round($newvalue*($currentvalue/$originalvalue)));
}

One remaining problem is that when I try to color the Black pieces white, I get an aquamarine fringe around the Black Motif pieces. In this case, $originalvalue will be 255 for the red component and 0 for the green and blue components, and $newvalue will be 255 for all three components. So, it recolors some edge pixels with positive values for green and blue but with 0 for red, resulting in aquamarine. So, I might have to factor in the value of each component when deciding how to recolor each component. But when I tried that earlier, I got some undesirable results.

It works with the Alfaerie set. To work, it has to know the primary color of the piece. This is stored in the variable $originalwhite or $originalblack, and the value of each variable must match a color actually used in the image. I have set their values in the main body of the code for Abstract, Alfaerie, Magnetic, and Motif pieces, and I have set their values in individual set files for some other sets. I have thought about adding code that would identify the most common foreground color in each piece image, as it already goes through each image pixel by pixel to get the color indexes, but I'm not sure if this would be appropriate for some pieces, such as pieces with textured coloring from photographs.

I modified the showpiece.php script to change the color of the piece. This may later be used with the Table and CSS rendering methods to recolor the pieces, and I may modify the pc shortcode to include a color option. Here's a violet King.

I turned the code for recoloring pieces into a function, and I added the ability to recolor pieces to the circular and spherical boards and to the Diagram Designer. But I still need to do some work on the forms.

The recoloring of pieces is working very well now. Even with the Alfaerie pieces, it looks like they were originally the color they were recolored to. For some sets, there are some glitches when trying to recolor the black pieces as white, but that's usually something no one will want to do.

I have been working behind the scenes to get Game Courier and the drawdiagram.php script to display images better. They can now recolor loaded images for the grid shape, and they can display coordinates above selected boards, which is important for Chess66, because it helps dispell the illusion that a vertical line of movement begins and ends in the same file. Here is the closest it can now come to the diagram that appears in the article. I suppose I should work on options to recolor the pieces, since what I'm doing for this diagram is using a piece set with four colors of pieces and using different labels for all of the Red pieces.

From the questions and expressions of confusion you got regarding what the rules are, it should be evident that you have not described them clearly enough. Also, you seemed to change your mind about some details in the comments. So, you should rewrite your rules to reflect anything you have changed your mind on and to supply the details that someone would currently have to read the comments to find out about.

the main feature of a switch that I'll retain is that spaces in the switch share some routes to and away from them, and movement from the narrow end can go in either of two different directions."

I'm sorry, but I didn't understand that.

I mean I am retaining the geometrical properties of the switches, but I am discarding the other rules regarding them.

Does that mean my variant is history? Or have I misunderstood something?

No, it means I am working on my own variant instead of putting pressure on you to change yours. You're free to go with the rules you want for your game. I'll see what I can do about programming it once you have settled on the rules and have described them clearly.

As I understand it, Fergus has decided to program a variant based on yours, and given it a different name to signal that it's not the same game.

Exactly this.

This game differs from yours only in that both a4 and 4, or both 5 and h5, can be occupied/passed through simultaneously.

There are some other differences. Here's a link: Reroute66. The rules are described below the board. I'll add individual piece descriptions to the rules later.

I'll admit I find it a little odd that such conditionally untraversible squares should be so difficult to implement (couldn't it be done with uncapturable dummy pieces that appear and disappear as the other square is occupied and vacated?)

That's the solution I already proposed. But I also think these rules are not essential to the core concept of the game, and I wanted to start with a variant that does not include them.

During the night I changed my mind on one of my rule suggestions. I had proposed allowing capture of a piece on the occupied space of a switch when a piece moves to the unoccupied space of a switch. This was to fit in with rules regarding no double occupancy of switches and blocking any movement through the switch when one space in it is occupied. These happen to be the most difficult rules to program, and I don't think they're really essential to the concept of a switch. So, I'm going to program a stripped-down version of Chess66 that I'll call Reroute66. This will treat each space as a fully separate space, and the main feature of a switch that I'll retain is that spaces in the switch share some routes to and away from them, and movement from the narrow end can go in either of two different directions. I'll get to work on it later in the day.

"A switch is an overlapping pair of spaces that in some ways operate together as a single space."

From my point of view it looks different. The square a4 of a switch is an independent square and is completely identical to the square a4 in normal chess. 4 (A4) is a composite square consisting of a half and triangle part of a4 and the new triangle due to board geometry. The new square 4 (A4) gets the same play options as all squares of the game board - 4 (A4) is considered equal.

This means that the squares a4/4 (A4) must first be seen independently. These independent fields get an additional function when they work together and act as a switch, as described.

I didn't say anything different. We're in agreement that the spaces composing a switch are separate from each other. But since they cannot be simultaneously occupied, and occupation of one space blocks movement through the other, and they share a common edge and a common corner, they also function in some ways like the same space.

It is possible to agree on the sides from which the switch should be accessible. We have clarified access from below and from the side, access from above is also not a problem and is already part of my proposal. The only question is whether it is access to the switch as a unit or to the individual square of a switch. According to my intention, the second applies.

Agreed. Use of the switch as a switch is possible only from below. That is due to the nature of how it works. If a piece moves to a switch through a diagonal move or a Knight move, it will have to stop on the switch, which will prevent it from using the switch to alter the direction of its movement. The same is true if a Rook or Queen moves to a switch from the side. It will have to stop there, which will prevent its use as a switch. And if a Rook or Queen moves to a switch from above, it will have only one path through the switch. So, it won't be utilizing the switch as a switch. This shows that access to the spaces composing a switch is a completely different matter than using it as a switch.

"Allow pieces access to the spaces of a switch from any direction, and when a piece moves to a switch, allow capture of any piece on the switch even if the capturing piece moves to the other space. For example, if a bishop is on A4, and a Rook moves to a4, consider the Bishop on A4 to be captured."

As described, access to the switch from all sides is not a problem. It is possible to agree on the proposal, but it does not fit my intention. However, if the game becomes more playable and programmable - so what.

What I'm proposing fits with the rule that both spaces of a switch cannot be occupied at the same time and the rule that occupancy of either space blocks vertical movement through the switch even when that movement would technically be going through the other space in the switch.

To the Knight: I can't allow anything here, but I can say what my point of view is. If we stick to the fact that the squares of a switch should be seen separately, then knight moves ending on the same line are not possible. However, as the game becomes more playable and programmable, compromises should be possible.

We could just say that because of the way that switches affect the geometry of the board, some spaces may be reached by either a vertical move or a Knight move. This would also correct the injustice done to the Knight of making the weakest piece even weaker around a switch while it gives all other pieces greater mobility.

"One last rule change I would suggest is to let Rooks, Queens, and Kings use their ability to move horizontally to switch between the spaces constituting the switch. This would basically involve lifting one more restriction on movement to the spaces making up a switch. "

I have problems with that. I have emphasized that the squares of a switch represent independent squares. This would rather mean that moves between the squares of a switch are possible.

Precisely.

The independence of the squares on the one hand and the functionality of a switch on the other compete with each other. Regarding the direct change between the squares of a switch, I tend towards the superordinate function, so a direct change should not be possible.

Allowing a piece that can move horizontally to move from one space to the other in a switch as a normal move does not affect the functioning of the switch. While the piece is on either space, other pieces can't pass through the switch, and once the piece leaves the switch, pieces will be able to pass through it again.