Ratings & Comments

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.

It's a pity that reasons for programming are decisive for my variant being downgraded. It is also a pity that the name I have chosen should give way to another name. Does that mean my variant is history? Or have I misunderstood something?

"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'm sorry, but I didn't understand that.

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. As a game in itself yours remains intact (and probably eventually publishable too if and when the Editorship approves), just more difficult to program given the primitives that Game Courier provides.

This game differs from yours only in that both a4 and 4, or both 5 and h5, can be occupied/passed through simultaneously. As such those spaces connect to the rest of the board in the same way they do already, they just stop being a ‘switch’ in the railway sense (aka a ‘set of points’ in my native British English, or German ‘Weiche’ as used in your original German page) and become just an unusual topological/geometrical feature of the board.

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?), but I'm not a programmer and I've never had a go at writing GAME Code, so…

One way to program it would be to have a single square 4/a4, and to introduce a number of extra piece types, each especially adapted to have the moves that the switches would allow. That is, you would have a special Rook for on a3, which would move forward both as a normal Rook, or with a move that switched file after one forward step. (And for a2 one that switched after 2 forward steps, etc.) When a piece of this Rook family would land on an edge file you make it automatically 'promote' to the kind of Rook that belongs on that square. When a Rook landed on a4 there would be a kind of promotion choice: it either stays/becomes a normal Rook, or one that replaces its forward move by a Left-Griffon move. Same idea for the other piece types.

I suppose that through this method I could even have the Interactive Diagram play Chess66. A user-supplied JavaScript function WeirdPromotion would take care of the 'promotions'.

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.

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.

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.

Here's are some guidelines to use in revising your description of the game.

1. The rules should be made entirely clear in the written text. Illustrations should be used to illustrate what the text has already said, not to provide additional information that is not written down.

2. The text should describe not only what can be done but how to do it.

I am very impressed, the changed look in Game Courier is a real enrichment. I am sure that many things can be better represented on this basis. I hope that I am not going too far out on a limb when I say that a variant such as Avatar Chess can be better conveyed. A very interesting upgrade.

I'm looking at the diagrams on my Likebook Mars at night, and on its monochrome e-ink screen, I cannot tell apart the red and blue pieces in the diagrams. At best, they are slightly different shades of black. In the diagram I made, the red pieces, which belong to White, appear even darker than the blue pieces, which belong to Black, which is opposite to how they should look in black and white. For the sake of accessibility for color-blind people and people using e-ink displays or black and white printouts, piece colors with more light/dark contrast would be more suitable.

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.

Does it also work for the anti-aliased piece sets?