Comments/Ratings for a Single Item

I have the shorter description of this variant.

“Captured piece swaps with its capturer and changes its color.”

I vaguely recall we identified that problem before: the ID would not be able to play this variant because it has no repetition detection, and recaptures to the same square can continue forever (e.g. a Rook both attacked and protected by a Rook). I am not sure it was ever solved.

I try to play on ID. I have whites:

1. d4 d5 2. e4 The computer says "thinking" and then nothing else occurs.

Conquer on Game Courier.
An invitation is here.

(A big thanks to H.G. and Fergus for the support).
 

Well, the main issue is that I am currently on a vacation, without access to any real computer. So posting comments through a mobile device is really all I can do.

@ H.G. I can understand that with all the other interesting topics you have lost the interest in 'Conquer'. I am also sure that avoiding permanent recaptures is programmatically very complex.

Apparently the idea is not particularly new in principle if you follow Jean-Louis, on the other hand the idea did not exist yet and seems to have certain advantages.

If the conquest strategy could not take root so far, because e.g. the variants 'Reinforcement Chess' or 'Chessgi' were not interesting enough, then the Conquer variant could be a new approach - conceivable, but not very likely I fear.

As far as there is a serious discussion about whether classical chess is the ultimate solution, then the question whether the strategy of banning captured pieces from the board or adding captured pieces to one's army could be an option. But there would have to be a playable way to do this ....

and limit my editorial activities here to providing old articles with Interactive Diagrams.

O.k., I got that and thanks for your comment.
In your interactive diagram for Conquer, you had noted that ...

The consequense of this is that in the search it will at somepoint quickly encounter a position where perpetual recapture is possible. And since recaptures are always searched, no matter how deep the search already went, this leads to an infinite regression that crashes the program.

Do you think that there can or will be a solution for the problem. If not, the approach gets stuck halfway and cannot be played or tested. I would like to help, but I don't know how.

@Gerd: I usually don't involve myself with publishing of submitted pages, and limit my editorial activities here to providing old articles with Interactive Diagrams. That doesn't stop me from commenting on things I read here, if it seems a useful contribution.

@Jean-Louis: Indeed, variants that recycle pieces have existed since the birth of modern Shogi several centuries ago. But the mechanism by which the captured pieces are re-introduced can make all the diffrence in the world. Dropping on an arbitrary empty square, even as a separate turn, makes for a highly aggressive game, where the most important tactics consists of attacking (usually the King) through piece drops. Restrictions on where a piece can be re-appear can meake such tactics impossible, even when theya re introduced immediately. The proposed introduction mechanism will in general not lead to very aggressive introduction of the captured piece.

I have seen other rules for re-introduction of pieces in a less aggressive way (e.g. on the back-rank only, or adjacent to the capturer or a special piece), but these are usually less elegant, because there is no guarantee that an empty square is available there, and additional rules are needed for handling the case when there is none.

The originality of Conquer seems (to me) the fact that the "re-introduction" square is the square where the capturer went from.

You are quite right there and as you have already said, the rule is new. And such a clear rule is, in my opinion, positive for the strategic orientation of a game.

The variants 'Reinforcement Chess' and 'Chessgi' quoted by you from Pritchard's CECV differ here.

For 'Reinforcement Chess' it reads:

A captured man changes sides and is immediately replaced by the
immediately replaced by the player who
replaces on any empty square, with 
two restrictions: ...

For 'Chessgi' it is to be read:

Like reinforcement chess, but it is not necessary to
to reinstate a captured man immediately; instead, the captor may
instead, the captor can hold him in his hand and then
place him on any vacant square, instead of making a
making a normal move. 

In my opinion, the above variants are hardly predictable for the opposing player with regard to the reinstatement of the captured piece. My variant/rule is more pragmatic and more calculable.

By the way: The variants 'Reinforcement Chess' and 'Chessgi' were not known to me during the development of 'Conquer'. And I think that the rule of 'Conquer' is original and new compared to 'Reinforcement Chess' and 'Chessgi'.

Am I wrong not to see a big difference with CVs like Chessgi, Reinforcement Chess, etc. Those can be seen in Pritchard's CECV as I wrote earlier. Look 5.2: http://www.jsbeasley.co.uk/encyc/052057.pdf

The originality of Conquer seems (to me) the fact that the "re-introduction" square is the square where the capturer went from.

Or I miss something in the rules.

Incidently, Conquer would benefit to be played with shogi-like pieces that are color-neutral and pointed toward the opponent.

@ H.G./Editorial staff
Are there any reasons left against the publishing of 'Conquer'?

@H.G.
Can 'Conquer' be published?

@H.G.
Thank you for your efforts.

Implementing the rules was as easy as I thought; it only required a custom script of 5 lines. (But I did not implement resurrection of an e.p. captured Pawn.)

Unfortunately that does not mean the AI can actually play it. The problem is that the AI does not truly recognize repetitions. It only discourage reversing your previous move. And it does not test for that on captures (which normally can never repeat a prior game state). Even if it did, it would test the wrong thing, as repetitions here repeat the previous move of the same player, rather than reversing it.

The consequense of this is that in the search it will at somepoint quickly encounter a position where perpetual recapture is possible. And since recaptures are always searched, no matter how deep the search already went, this leads to an infinite regression that crashes the program.

I will have to think whether there is an easy solution to this.

Don't overreact. Many variants see the light of day and are just re-inventing old ones, I have plenty of examples of 4-player chess, circular chess, hexagonal chess, 3-player chess, decimal chess with 3:1 hoppers (camels), etc. which already existed.

In the case of Conquer, I do not know another variant which is exactly identical. So, yes it may have its raison d'être. I just said that Conquer is only slightly different than several other variants where "The goal of the game is to conquer the opponent's army and to add it to your own army", your motto. Are you aware of them? If yes, you could have mentioned them. If no, now you know, Pritchard's book is available online.

If 'Conquer's' way of assimilating captured figures into your own figure set didn't exist before, then the variant has its raison d'être. Or do you disagree just because assimilation of captured figures has already been thought about elsewhere in a different way and the spirit is the same? Then many variants should not have seen the light of day.

Several chess variants of this sort have been reported by Pritchard. Where the captured piece is added to your own army. The empty square on which the captured/flipped piece is reintroduced is not as specified at Conquer, but the spirit is the same. Check Reinforcement Chess or Neo-Chess (Randolf) for example. Conquer is only slightly different.

A small detail. In the explanation it is given Qc2 Kf5, but here K notes a knight, not a King. Qc2 Nf5 would be more standard notation.

More than I expected.

Well, it is something I had not seen before. And the principle is quite generally applicable.

The new version of the Interactive Diagram script, which allows tinkering with the generated moves by a user-supplied JavaScript routine, should make it rather easy to implement this variant, even though it is not standard. I'll have a look at it.

@H.G.

This way of recycling pieces is a nice alternative to piece drops.

Do I understand you correctly that the variant can be considered quite interesting? The question of playability of the variant should not occur, since it is very similar to classical chess - with the exception that all pieces remain on the board during the game.

If that is the case, I would like to ask you if you see a possibility to program the variant and make it playable? With a little bit of luck, the variant could meet the interest of the comunity here and there. Thanks for your help.

I have now reduced the name and call the variant simply 'Conquer' - some other terms are occupied, e.g. 'Assimilation Chess', 'Fusion Chess', 'Take Over Chess'.

Following your recommendation I have not used the phrase 'starting position' in my description now.

Then thank you for pointing out that perpetual recaptures may become possible. In the description I have included a rule against perpetual recaptures.

Should I presume that in variant 1, a King may move to or stay on an attacked space, and in variant 2, a King may not move into or remain in check?

This is how it should be.
In variant 1, a captured king is assimilated by a king of the other side in the worst case, and the game continues until one side has captured all pieces.
In variant 2, the capture of the king ends the game.

Saying a captured piece returns to the 'starting position' is a bit confusing, as one could easily understand it to mean 'the square where it was in the initial setup'. Better just say that a captured piece is 'put on the square its capturer came from'.

The name of the variant seems a bit lengthy. Perhaps you should call it just 'Conquer'. (Or perhaps 'Abduct', 'Convert' or 'Bribe' would describe it better.) That you would be fighting the opponent's army is sort of self-evident.

This way of recycling pieces is a nice alternative to piece drops. It does seem to invite perpetual recapture, though. E.g. if a Rook is attacked as well as protected by a Rook, these Rooks could continue capturing to the same square forever, while not capturing could leave you down a Rook. Perhaps some rule against repetition is needed. Like that you cannot make the same move as the previous times the same position occurred.