Comments/Ratings for a Single Item

Greg, it is exactly such reflections that are valuable. My standpoint is the following. It is necessary to maintain the first move advantage in order to retain the  strategical tension. For a variant to compete with orthochess there must be  a gradient, or a flow, in play. The standard position in orthochess holds very good attacking prospects for white. The setup is an attacking position. In Relocation Chess we give black the chance to disrupt this ideal position. Hence I recompence white by giving him the last word in the setup of the pieces. I believe that this gives white a slight possibility to maintain an advantage. Of course, I am not certain, but I think that black can improve his defensive prospects if he relocates his king. It is immediately protected. Another important factor is that long castle will occur more often while the king can remain protected for a long time before deciding which side to castle on. The foremost reason why short castle is much more common in orthochess is because the players have to get the king out of the way. In Relocation Chess this problem can be avoided. 
There is a bug in my zrf, however. The pawn can capture by moving forward to the last rank, while promoting. I have fixed it but I cannot upload it while there is some problem with my FTP.
I have also invented relocation variants that are mirrored, etc. But I cannot upload them.
/Mats

I have now changed the link to a new webpage so that the bugfixed Relocation Chess program can be downloaded:
http://home7.swipnet.se/~w-73784/chess/relocationchess.htm

The following variants are variations on the theme:
http://home7.swipnet.se/~w-73784/chess/placementchess.htm
http://home7.swipnet.se/~w-73784/chess/arrangementchess.htm
http://home7.swipnet.se/~w-73784/chess/configurationchess.htm

An interesting project would be to test this for the Capablanca (8x10) setup. Maybe it's enough to allow relocation of the queen on that big board. But somebody else would have to do that.
/Mats

a) Your sentence: 'Note that the players can choose to keep the standard position by simply swapping bishops.' seems to be obscure to me.

b) When after such relocations the arrays will end in one of 20 possible Chess960/FRC starting positions, it still will result in a position with small advantage for White. Thus having the last relocation choice would enable White to maximize that advantage or in contrast Black to minimize that advantage. Thus it seems more natural to start any relocating by White as with the following playing.

c) Supposing that there would be a minimax optimization of the relocation process along with the coming lot of games, there soon would be a well known 'optimal' relocation procedure (for both sides). Thus this finally would raise a preferred 'standard' starting position, in extreme it would end up in a traditional chess game itself.

d) To provide a bunch of really used different opening positions therefore it seems to be unavoidable to demand an execution of any kind of a randomizing procedure like in Chess960/FRC. So maybe there might be an alternative to make a hidden choice among possible exchange piece types?

Reinhard,
Thanks for the comments.

a) I have clarified the 'swap bishops' statement. Swapping bishops in the Chess64 email preset is merely for technical reasons, in order to remain at the same positions whilst having performed a move. Chess64 is very different in that it produces positions that are not mirrored. In the following I discuss Chess20 and Placement Chess (simply because I mistakenly thought you meant this). Anyway, Placement Chess is perhaps what most chessplayers would regard as the more 'serious' variant since it is mirrored.
http://home7.swipnet.se/~w-73784/chess/placementchess.htm

b) My standpoint is that the standard position is advantageous to white while it is an ideal attacking position that is strategically ambiguous. (one doesn't know on which wing the bishops or the king will be placed, etc.). Therefore, it would generally be good for black to avoid this position. The least we can do is to let white have the final word about which position to choose. If the standard position hadn't given white a slight advantage, then grandmasters wouldn't bother to play against another grandmaster. So it is necessary that the initial position holds a slight advantage. I am concerned that the other positions among these 20 aren't advantageous enough, thus making it difficult to develop an initiative. So my concern is exactly the opposite of yours. I don't think that black needs to worry much.

c) I think that the standard position is optimal in a sense. Since all positions are mirrored they are equally good for both parties. So what counts is solely if you can develop an advantage from that very position. All the positions seem to be very stabile and promises no definitive advantage to any party. Some people would prefer to stash away the king at the g or b file, which obviously has some sense to it, while others would like to put it on the c file in order to have a bishop on the e file, from where it easily can be 'fianchettoed' on the c file. This could be a good defensive idea against a king pawn opening. I am very sceptical about the idea that black has an optimal relocation in the first move. I don't believe it. 

d) The point I had was to avoid a randomization procedure in order to allow the players some control. I believe that chessplayers aren't very keen on Fischer Random simply because they are always in for a surprise. Chessplayers aren't used to this. They are used to taking measures and try to predict the future. Anyway, a randomization is easy to achieve, and I wrote a preset for Chess20 here:
http://play.chessvariants.org/pbm/play.php?game%3DChess20%26settings%3Dchess20

Diagrams of the 20 possible positions can be viewed here:
http://home7.swipnet.se/~w-73784/chess/placementpos.htm

/Mats

to a): there seems to be no need for a special swap move. Instead move the King / Queen to the Bishop of opposite colour, which seems to be an impossible exchange, which should be skipped then. 

Initial exchange moves (of traditional sequence: White starts) could be integrated into traditional game notations by starting a game at a negative move count (here e.g. -2 half moves), supplied by an appropriate FEN. But I am not yet convinced that an intended relocation would be better than a randomized one.

Of course, PGN and FEN already account for Fischer Random positions. One needn't really describe the sequence of relocations, only the resultant position. The game below is a Placement Chess rapid game played by TascBase 2.1/The King. TascBase 2.1 can handle Fischer Random castling.

[Event 'Placement Chess, Rapid']
[Site '?']
[White 'Tascbase 2.1/The King']
[Black 'Tascbase 2.1/The King']
[Result '1/2']
[SetUp '2']
[FEN 'rnkbbqnr/pppppppp/8/8/8/8/PPPPPPPP/RNKBBQNR w KQkq - 0 1']
1. Nf3 f5 2. d4 e6 3. e3 Nf6 4. c4 c5 5. Nc3 Bh5 6. d5 Na6 
7. Qd3 Nb4 8. Qb1 Qd6 9. a3 Na6 10. Be2 Nc7 11. Qc2 Be7 
12. dxe6 dxe6 13. O-O-O Qc6 14. e4 O-O-O 15. exf5 exf5 
16. Qxf5+ Kb8 17. Bd2 Bg6 18. Qh3 Bd6 19. Nh4 Bf7 
20. Nf5 Be6 21. Rhe1 g6 22. Qh4 Bxf5 23. Bf3 Qa6 
24. Qxf6 Qxc4 25. Be3 Qa6 26. Rd2 Ne6 27. Bd5 Rhf8 
28. Qh4 Bc7 29. Bc4 Qc6 30. g4 g5 31. Rxd8+ Rxd8 
32. Bxg5 Nxg5 33. Qxg5 Bg6 34. Nd5 Qa4 35. Ne3 Re8 
36. Rd1 b6 37. Bd3 Bf4 38. Qf6 Rxe3 39. fxe3 Bxe3+ 
40. Rd2 Bxd2+ 41. Kxd2 Qxg4 42. Qd6+ Kb7 43. Qd5+ Kc7 
44. Qe5+ Kc6 45. Qf6+

Is '2' a legal value in the Setup tag? I thought this was a Boolean, limited to '0' and '1'. 

I think it is a bad idea to leave the actual swaps out of the PGN. They are part of the game. Especially in variants that allow several such swaps (e.g. Superchess), so the order cannot be deduced from the position after the swapping phase (as could be given by FEN).

So I propose the FEN tag should really be reserved for cases where the players get to play a non-standard position without having any say in it, i.e. in true shuffle variants. For variants like reocation Chess, we need to define a notation for swap moves.

I propose to write the swap moves in SAN as non-capture moves to an occupied square. E.g. 1. Kg8 would mean black swaps its King with the Knight on g8. In full algebraic notation this would be Ke8-g8. This could also work in Superchess, where swaps take place with pieces in the holdings: they could be written as drops to an occupied square. E.g. A@d1 would mean you swap the Queen for an Amazon, the Queen going back into the holdings. (Note that the way I implemented Superchess in WinBoard makes it a normal shuffle variant, where the players have no say in how they make swaps to create the initial position, so this does not apply there.)

Perhaps TascBase uses this tag internally because he needs to know that it is a Fischer Random game, so that castling will work. He can read Fischer Random PGN, so this must be the case, then.

My point was that, in my four relocation variants, it is easy to deduce which relocation moves were executed and it what order. The relocation rules are such. Therefore it is enough with FEN. But it could be worthwhile with an enhanced PGN.
/Mats

Hmm, this seems a non-standard way to recognize FRC games. When I load the game in WinBoard (after correcting the single quotes back to double quotes, orf course) it does not recognize it as FRC, and complains about the O-O-O. When I set WinBoard to FRC before loading the game it eats it, but when I then safe it again the tags look like:

[Event 'Placement Chess, Rapid']
[Site '?']
[Date '?']
[Round '-']
[White 'Tascbase 2.1/The King']
[Black 'Tascbase 2.1/The King']
[Result '*']
[Variant 'fischerandom']
[FEN 'rnkbbqnr/pppppppp/8/8/8/8/PPPPPPPP/RNKBBQNR w HAha - 0 1']
[SetUp '1']

The Variant tag is intended to indicate the variant and imply the castling rules. This seems a much more user-friendly way than encoding the variant as some obscure number. e.g. what number to use for Xiangqi?

Note that WinBoard would recognize many other names in the variant tag as FRC as well. Such as 'FRC' or 'Chess960' (or 'w/22', as it is called on ICC). Perhaps I should change the default name (which it prints) to 'Chess960', as this seems to be the name that is winning out amongst players of this variant, now that Bobby Fischer is not so popular anymore.

Well, TascBase 2.1 is from 1997 and it's a discontinued software. This should explain why it uses a 'non-standard' method. Obviously, this software was too good to succeed. Instead ChessBase won out, which has always been a pile of functionality thrown into a bucket. 
/Mats

That probably explains it; I don't think that at that time a standard for FRC had emerged.

Anyway, the following system seems a very satisfactory way to handle drops, substitutions and swaps in SAN, as SAN makes distinction between captures and non-captures:

non-capture to empty square (e.g. Kf1): normal move
capture to occupied square (e.g. Kxf1): normal capture, or capture of own pieces
non-capture to occupied square (e.g. Kf1): swap mentioned piece with whatever was on the to-square
drop to empty squuare (e.g. N@e4): drop from holdings
drop to occupied square (e.g. N@e4): substitution, whatever was on drop-square goes back into holdings
warp move (e.g. @@e4): whatever was on drop-square goes into holdings, leaving an empty square
suicide (e.g. @xe4): e4 is made empty, what was on it disappears.

I have describe all five of my relocation variants in the below link, with diagrams. In fact, regrouping is very natural in warfare, and that's why it belongs in chess, too. Julius Caesar regrouped behind his lines before the battle against Pompeius. This was essential as he could counter the cavalry attack on the right flank. So this was how he won the battle. The relocation method would, in a sense, resolve the eternal debate of which is the best of the Capablanca variants, if somebody cares to implement it. 
http://hem.passagen.se/melki9/relocationvariants.htm
/Mats

H.G. Muller,
Could the relocation variants be implemented in Fairy-Max?
http://home7.swipnet.se/~w-73784/chess/relocationvariants.htm
/Mats