chessjoker

[Evert]

Not very well, of course, because I would have to give the Joker a fixed piece value. While its value should be expected to depend on the opponent's material. I guess I would set the Joker value to 4.

That's not the only problem, of course: your move options now depend on what the last moved piece of the opponent was, which means transpositions do not lead to identical positions in general, which should then be recorded in the transposition table.

[hgm]

Indeed, but that is easy to fix. I plan to set the e.p. square equal to the last moved piece. That would automatically be hashed. So the idea is that when it wants to generate moves for the Joker it does not use the move table of the piece type itself, but of the piece on that to-square. So basically change the statement

direction = firstDirection[pieceType];

into

direction = firstDirection[pieceType == JOKER ? board[epSquare]&15 : pieceType];

Might need some correction for Pawns, though: I have not studied the rules very carefully, but I guess the intention is that a white Joker would move as a white Pawn after the opponent moved a black Pawn.

[Greg Strong]

Indeed, but that is easy to fix. I plan to set the e.p. square equal to the last moved piece. That would automatically be hashed.

I don't think that quite does it. That does prevent different positions being hashed the same, but it allows the possibility of the same position being hashed differently. Consider two positions with two knights. They are identical except for which knight was the last piece moved. They would have two different ep squares, but they should be considered the same - the only important piece of information is that the Joker can move as a knight...

[lucasart]

Hello to all,

I devised a new chess variant with one joker for each opponent (named Chessjoker). It was born on febrary 2014.
In the paper that you can download free here, you should find all,

http://www.bubok.es/libros/231097/Chess ... n-giullare

but it is in italian. Anyway - while I am traslating the paper - I can tell you that the new rules is practically just one: the joker moves like the last piece moved by the adversary. [I discovered that this interesting idea also came in head, some years ago, to T. R. Dawson javascript:emoticon(':evil:'); anyway my game is new and original: in the Dawson game "Jester chess", Joker's basic movement suffers various complications and moreover there are many other new pieces].
However, my game aims to be as conservative as possible: I want to keep the traditional chess experience as possible.
Something more:
- Joker just copy movement: if it copy the King, does not suffer check, castling,... If it copy a pawn, does not promote at last row.
- Joker it isn't obbligated to eat if opponent has eaten: can move or eat freely.
- if a pawn promotes, joker copy the promoted piece.
- the board is 9x9 with a disposition very similar to the standard one.

Although this semplicity, the joker is able to introduce peculiar situations, those may strongly inhibit the movement of important pieces (and promotion too) of adversary; and so to determine the match. In the paper, I describe various situation of this kind and other peculiar game condition.
In principle, I was hoping that the joker introdution should be able to reassign superiority to man against the machine; but now, after talking with some expert (Ubaldo Andrea Farina, Harm Muller... ), I am not so sure javascript:emoticon(':?').
Anyway, many people told me that the idea is quite interesting.

I'd like to see Chessjoker implementated in an engine a day... some help?

Thank you, Giuseppe

Sorry to rain on your parade, but this variant will never be popular, if only for these two reasons:

• it doesn't use a 8x8 board. this is a serious problem. have you ever seen a 9x9 or 9x8 board in real life (I mean a wooden board) ? as for computer chess, bitboards are central to most (if not all) strong programs, and that means you have to use 8x8. I suggest you have a look at Seirawan chess, and resolve this problem by using a gating rule on a 8x8 board.
• your game has path-dependant rules. that is a serious problem. all programs use a transposition table, and the pre-requisite is that the result of the min-max search only depends on the current position, not the last piece moved by the opponent, for example. implementing this is messy, you'd have to store the info in the FEN, and zobrist it into your hash keys. this will probably reduce significantly the number of transposition hence the usefulness of the TT.

[Uri Blass]

Hello to all,

I devised a new chess variant with one joker for each opponent (named Chessjoker). It was born on febrary 2014.
In the paper that you can download free here, you should find all,

http://www.bubok.es/libros/231097/Chess ... n-giullare

but it is in italian. Anyway - while I am traslating the paper - I can tell you that the new rules is practically just one: the joker moves like the last piece moved by the adversary. [I discovered that this interesting idea also came in head, some years ago, to T. R. Dawson javascript:emoticon(':evil:'); anyway my game is new and original: in the Dawson game "Jester chess", Joker's basic movement suffers various complications and moreover there are many other new pieces].
However, my game aims to be as conservative as possible: I want to keep the traditional chess experience as possible.
Something more:
- Joker just copy movement: if it copy the King, does not suffer check, castling,... If it copy a pawn, does not promote at last row.
- Joker it isn't obbligated to eat if opponent has eaten: can move or eat freely.
- if a pawn promotes, joker copy the promoted piece.
- the board is 9x9 with a disposition very similar to the standard one.

Although this semplicity, the joker is able to introduce peculiar situations, those may strongly inhibit the movement of important pieces (and promotion too) of adversary; and so to determine the match. In the paper, I describe various situation of this kind and other peculiar game condition.
In principle, I was hoping that the joker introdution should be able to reassign superiority to man against the machine; but now, after talking with some expert (Ubaldo Andrea Farina, Harm Muller... ), I am not so sure javascript:emoticon(':?').
Anyway, many people told me that the idea is quite interesting.

I'd like to see Chessjoker implementated in an engine a day... some help?

Thank you, Giuseppe

Sorry to rain on your parade, but this variant will never be popular, if only for these two reasons:

• it doesn't use a 8x8 board. this is a serious problem. have you ever seen a 9x9 or 9x8 board in real life (I mean a wooden board) ? as for computer chess, bitboards are central to most (if not all) strong programs, and that means you have to use 8x8. I suggest you have a look at Seirawan chess, and resolve this problem by using a gating rule on a 8x8 board.
• your game has path-dependant rules. that is a serious problem. all programs use a transposition table, and the pre-requisite is that the result of the min-max search only depends on the current position, not the last piece moved by the opponent, for example. implementing this is messy, you'd have to store the info in the FEN, and zobrist it into your hash keys. this will probably reduce significantly the number of transposition hence the usefulness of the TT.

I do not expect a new game to be popular and there are many chess variants when all of them are clearly not popular relative to chess but note
that the second reason is not a reason that the game is not going to be popular.

Note that chess also has path-dependant rules and the same position may be win for white or draw by the 50 move rule dependent on the path.

[Evert]

it doesn't use a 8x8 board. this is a serious problem. have you ever seen a 9x9 or 9x8 board in real life (I mean a wooden board) ?

Shogi is played on a 9x9 board (alternatively: you can use the corners between squares, then you can use an 8x8), Xiangqi boards are 8x9 (the middle squares have no dividing lines, making up the river, but that's easily fixed with a marker and a ruler; Xiangqi itself is played on the corners so effectively uses 9x10) and draughts uses a 10x10 board. More exotic boards certainly exist, but are harder to come by.

But: I'd keep the board square and the sides even (otherwise bishops become a little weird).

as for computer chess, bitboards are central to most (if not all) strong programs, and that means you have to use 8x8.

I'm amazed I have to remind you that correlation does not equal causation. The other point of course is that no one is going to play a game they don't know against a computer program that they are never going to be able to beat. You want something that at least can be set to play at a low enough level that you stand a chance.

Most people who would want to play this game would do so on a computer anyway, I suspect.

your game has path-dependant rules. that is a serious problem. all programs use a transposition table, and the pre-requisite is that the result of the min-max search only depends on the current position, not the last piece moved by the opponent, for example. implementing this is messy, you'd have to store the info in the FEN, and zobrist it into your hash keys. this will probably reduce significantly the number of transposition hence the usefulness of the TT.

Sure, but that's a complication of the game. The rules of games are not determined by how easy it is to build a transposition table for them. It's not really more messy than storing the ep-square (which is actually pretty messy, so maybe a bad comparison). It will make the game much harder for humans though, while computers do not become confused about what a chameleon (err… I guess I meant Joker, but this got me thinking: I vaguely recall reading about a piece like this under the name chameleon, but I don't remember where) could do.

[hgm]

I don't think that quite does it. That does prevent different positions being hashed the same, but it allows the possibility of the same position being hashed differently. Consider two positions with two knights. They are identical except for which knight was the last piece moved. They would have two different ep squares, but they should be considered the same - the only important piece of information is that the Joker can move as a knight...

Good point! So what is really needed is to hash the e.p. square as epKey[square][pieceType]. This is at a complexity/benefits ratio that I norally ignore in Fairy-Max, however. (It for instance also doesn't clear the e.p. square when there are now Pawns that can actually e.p.-capture, so that the identical positions after 1.e4 any 2.d4 and 1.d4 any 2.e4 hash to different locations.)

Because I use an additive key in Fairy-Max rather than an XOR key, it would be quite easy to hash the 'lastTo' square into the key as if there were two pieces of the same type on lastTo.

Another problem is of course that when you have no Jokers anymore, all positions become equivalent irrespective of their last move, so it becomes wasteful to work that into the key. This could be cured by multiplying with the number of Jokers, which is also something fairy-max already keeps track of (for the purpose of Spartan Chess, where it has to know how many Kings it has left).

So the normal key update is

key += KEY(board[toSquare], toSqr) - KEY(piece, fromSqr) - KEY(victim, toSqr);

and when probing I would then add a term
hash = hashTable + key + stmStuff + pieceCount[JOKER + color] * KEY(board[lastTo], lastTo);

[mcostalba]

[*]your game has path-dependant rules. that is a serious problem. all programs use a transposition table, and the pre-requisite is that the result of the min-max search only depends on the current position, not the last piece moved by the opponent

The best approach IMHO is to leave the TT code as is. It won't be 100% accurate, but the case of a TT move that is not the real strongest move is already routinely handled in the standard case, actually many TT moves happens to be in that situation. So it will lower efficiency of TT, but is difficult to say how much and anyhow does not beak the engine.

...and more I read about wild and half-thought fantasies on how to fix that, more I am confident the best approach is just to leave TT as is.

The only change is of course to not store joker moves in TT.

[mcostalba]

...and more I read about wild and half-thought fantasies on how to fix that, more I am confident the best approach is just to leave TT as is.

But because today I am in a good mood I want to give the correct solution:

Code: Select all

Key tt_key() {
  return pos_key ^ Zobrist::psq[joker][joker_sq] 
                 ^ Zobrist::psq[joker_alias][joker_sq];
}

Before storing a position in TT remove the joker and substitute it with its alias piece, compute the resulting key and store that.

Upon probing the TT, compare the retrieved TT key with the pos key after having replaced the joker, if key matches you have a hit.

[lucasart]

[*]your game has path-dependant rules. that is a serious problem. all programs use a transposition table, and the pre-requisite is that the result of the min-max search only depends on the current position, not the last piece moved by the opponent

The best approach IMHO is to leave the TT code as is. It won't be 100% accurate, but the case of a TT move that is not the real strongest move is already routinely handled in the standard case, actually many TT moves happens to be in that situation. So it will lower efficiency of TT, but is difficult to say how much and anyhow does not beak the engine.

...and more I read about wild and half-thought fantasies on how to fix that, more I am confident the best approach is just to leave TT as is.

The only change is of course to not store joker moves in TT.

Hum. I really doubt that. But in order to prove you wrong, I would have to implement that silly game and do some experiments. Really don't have time or will to even try. So we will probably never know.

The fact that this silly joker can be a completely different piece for each TT entry sharing the same zobrist key is a serious problem. The best move (and score) are very likely to depend on what the opponent pieces are. We're talking about TT pruning here. This is extremely critical. We're not talking about some move ordering statistic for example.

Anyway, there are hundreds of variants. It's easy to invent a new one, but it's harder to invent a variant that actually makes some sense and that really is playable (most of them are really stupid, eg. suicide or atomic).

Typically people invent new variants by adding tons of extremely obscure rules to the game of chess. Often these new rules are so poorly defined that it's really unclear how to implement them. I wish they would instead rethink chess from the start and simplify it rather than just add new rules on top (that badly clash with existing ones).

True creative talent would be to rethink chess from scratch and make a game resembling it with fewer rules, yet more interesting and challenging.

Edit: If you simply discard the nature of the joker in your TT, you will often have illegal TT moves...