QuantumChess

Latest revision as of 12:23, 15 January 2024

Quantum Chess (stylised as Qhess to help distinguish from other Chess variants known as "Quantum Chess") is a chess variant with a key change: The type of each piece is unknown at the start of the game - being in superposition of all piece types, and it's type is refined by actions through gameplay - each time a piece moves, it's type collapses (if appropriate) into only the types possible to have made that movement.

Whilst sharing some similarities with SpyChess, it was arrived at independently. Quantum Chess idea is through the grapevine, heard by Nemo via Thomas, and written by here after a discussion about how it would go.

[edit] Gameplay

UI mockup

The board is setup as per normal chess - two rows of 8 pieces. However the capability of anyone piece is yet to be determined. Each starting piece has the potential to become any piece, but in doing so, collapses it's options down to that one type, and collapses other pieces options likewise, with the end state being that a traditional chess demographic of pieces is arrived at.

Thus, at the start of the game, every piece has the potential to move in any manner at all. But if a piece moves as a knight, then it can only ever be a knight thereafter. "knightness" is still available to all other pieces. As soon as a second piece is locked in as a knight, no other piece can become a knight. Likewise a piece that moves one space forward may be a pawn, a rook, a king or a queen - but no longer has the opportunity to become a bishop or a knight. If it then moves two spaces sideways, it has further collapsed it's waveform to only include rook and queen possibilities. A piece that moves multiple places diagonally (and has never shown non-diagonal movement) is reduced to being bishop or queen, and the other bishop is only available to pieces that have only moved diagonally on the opposite colour).

These possibilities are visible to both players at all times. In traditional chess, a turn is one step:

1. move a piece (with a requirement to resolve check if it exists).

In quantum chess, a turn is multiple stages:

1. Resolve check (which may be a declaration that an potential-check is not check because the threatened piece is not a king - thus collapsing it's waveform, or may involve moving a piece (this does not prove an potential-check was actual-check. The only collapsed waveforms, if any, are due to piece movement.
2. Move a piece (unless a piece was moved in the previous resolution stage)
3. Declare potential check (if the player chooses to do so - only if one of their pieces has the ability amongst it's options to challenge a could-be-king on the opposite site.

I note here that declaring potential check may involve collapsing waveform of the attacking piece to allow it to make such an attack, but resolving check involves no such collapse, even if the resolution is acted in a way that implies the piece WAS king. Because of these three steps, and the multiple-waveform nature of all pieces, it means at the start of the game the front row is full of potential queens, and also potential kings. A call of potential-check may be made at the start of the game (by collapsing the attacking piece to queen/rook/bishop to do so, depending on the exact target being queried.

The traditional chess "first move" is white. In Qhess, the first *physical move* is still white, but the first turn is in fact the "declare potential check" stage from black. This (like all potential potential-check checks (golly I enjoyed writing that)) is optional on the players behalf. Black may prefer to not collapse the waveform of any pieces by such a check, meaning white's first turn has no resolve and can go straight to "move a piece".

[edit] Castling

This is allowed, and collapses both the king and a rook to their true state completely.

Rule based on that of Fisher random chess: ie, both must be on the back row, not have previously moved, and all squares involved must be free from attack, and all square between must be empty. Final positions are as per Fisher random. King/Queen side castling is determined by the relative positions of the rook and king in question.

Fisher Random Chess requires the king to be between the two rooks on initial setup. That requirement does not exist here as the pieces are in superposition, and the original location of the non-castled rook may not be known till later in the game (if at all).

[edit] Promotion

Any potential-pawn which reaches the opposite back row gets a promotion, which consists of restoring a set of (QBNR) waveforms, and it then being excluded from chained collapses. Any subsequent promotion is the same - being seperate from both the original pieces and also each other for collapse chaining.

[edit] Taking pieces

A piece is taken as per normal chess - an attacking piece moves into the location of the defeated piece which is then removed off the board.

Some notes:

• taking of a piece does not inherently collapse it's waveform, with the exception it can no longer be a potential King, which may cause a chain reaction of other collapses.
• en passant reveals the attacking piece as a pawn, and is valid against any potential pawn (in a situation where en passant is possible), and thus collapsing it's waveform to a pawn upon capture.

[edit] Check and Checkmate

To set the logic here: in regular chess, check is a situation where a king is under attack (ie, if it were a normal piece, it could be taken next turn), and the player of that king MUST in their turn resolve that situation so as to not be in check. If that is impossible, then it is checkmate.

In Qhess, the same basic logic applies, but needs to be explained to cover superpositions.

• potential-check is a situation where a potential-king is under attack. This ONLY occurs by declaration of the attacking player (it is never automatic), and has four possible resolutions
  • Defending player declaring that it wasn't a king afterall. Defending player still has a physical turn.
  • Defending player moves the potential-king piece out of the way, and if appropriate to it's movement, its waveform collapses as per normal waveform collapse behaviour.

• • Defending player moves another piece to defend the potential-king. This may collapse the waveform of the moved piece, but does not collapse that of the potential-king. They may yet turn out to not be the king
  • Defending player moves a piece (probably not the potential-king, but it's possible) to take the attacking piece.
    • Note that the potential-check check only applies to the attacking piece and potential-king. So if the potential-king CAN take the attacking piece, it can do so, even if that position is "defended" by another piece. It is up to the attacking player to call potential-check again on the next turn in that situation.
• automatic check is akin to traditional chess - where a singular king is under attack by a piece with the capability to do so (even if it has other waveforms available to it). However, due to the superposition nature of pieces, a hypothetical situation is that a players turn begins with two potential-kings, both under attack one is challenged by potential-check, and the defending player defends in a way that collapses the potential-check by declaring that piece not-king. The other potential-king now collapses to be the true king and is under attack = check (automatically)

Checkmate is as per regular chess - a situation where the king cannot move out of check. A checkmate cannot occur with multiple potential kings, since the base logic of checkmate is "I will take your king on my next turn", but if there are multiple potential-kings, then the true king cannot be definitively identified.

[edit] Implementation

It's very likely that this is best implemented in computer, where each piece's waveform options can not only be easily visualised, but visual filters for waveform options can be applied easily, as well as predictive "if I move this piece and collapse it's waveform in a certain way, what other waveform collapses occur?". It is imagined that each of the six piece types be represented by a colour, and each piece thus be a grid or a pie-chart to show the waveforms it's still unclear on. (if needed, the border of the pie chart in black/white to denote which side they're on)

A physical implementation may be done with Trivial Pursuit pieces, however collapsing waveforms by hand may be difficult, due to chained collapses (eg: if two pieces are Rook/Queens, and one collapses to the Queen, the other collapses to a Rook) and implicit collapses (eg: if three pieces are, respectively, Queen/BlBishop/Pawn, Queen/BlBishop and Queen/BlBishop and no other pieces have Queen/BlBishop available to them, then the first collapses to a pawn, since otherwise two bishops or two queens are inevitable). Iterating recursively through all collapse options after every collapse is liable to be tedious and error prone.

[edit] Notation

Qhess notation is derived from chess algebraic notation - extending it to handle the additional features of Qhess, but otherwise understandable as the same "language" as it were.

Chess algebraic notation normally uses an indicator of the type of piece, plus the minimum of disambiguation required, and then the destination coordinate. Long algebraic notation gives from source and destination coordinates. Qhess aims to use long algebraic notation at it's core. Long algebraic notation is (apparently) also commonly used in UCI for communication between engine and interface, and our notation here will intend to be used the same way

Additions to the standard:

• (optional) specifying the waveforms of a piece BEFORE it's location. The letter codes are as per english chess algebraic notation, with the addition of 'P' for Pawn. If there are multiple letters, they are held within parenthesis. eg: (KQBNRP)e2
• Specifying the waveform of a piece at it's location - this indicates a specification of it's waveform state. This (alongside with colour indication, see below) may be used to save/restore the state of a board midgame, resolve potential-check challenge, or (optionally) be used to indicate waveform collapse at the end of a piece's movement eg: e4(QRP). it is presented in square brackets for the first two cases (this is a nod to Portable Game Notation for initialisation of mid-game boards)
• (optional) specifying the colour of a piece with "b_" or "w_" preceeding the first-displayed waveform state of a piece at it's location. Like most of algebraic notation, it's only included when required for disambiguation. If the notation is for a game from the start, then it is never needed. However if the notation is restoring a saved gamestate, then it is needed on initialisation of the board. eg: e4(b_QRP)
• A move may be as simple as long algebraic notation with no additions "e2e4" or may include the full waveform specifications "(b_KQBNRP)e2e4(QRP)"
• A potential-check challenge is written as a sequence of positions within angle brackets. The first position is the piece in potential check, and is indicated with '+' as per normal notation. Then pieces 2..n are the attacking pieces (there may be multiple, with waveform collapse stated as needed), eg, this would be a valid opening move "<g7+ (w_KQBNRP)g2(QR) (w_KQBNRP)b2(QB)>", and could be written at bare minimum as <g7 g2 b2>
  • By definition, a potential check has only one piece on the opposite site, so it could be said that the order of pieces within a potential check block are irrelevant, and that the target need not be identified. However it is done this way so as to balance readability. Note that "target first" was chosen to match the UI order of operations in the first Qhess implementation, even though "target last" has a sense of logic to it also.
• Normal (definite) check is still indicated by a "+" in the move stage, same as normal
• turn zero is allowed for the initial black potential-check challenge, should they choose to play it.
• castling notation is that of normal castling notation (0-0 or 0-0-0) but preceeded by the specification of the king location. The castling notation specifies the direction of castling, and castling rules then mean the rook and all final positions are known. eg: "d10-0-0"
• promotion: prepending "=" to a piece as it regains superposition: d7d8(=QBNR). If the notation is used to setup a mid-play game, then the = must be used in the initial declaration. This is important as a promoted piece's type is not entangled with any others.

Once a piece collapses to a single type, it no longer needs to be in brackets, and no longer needs to specify it's source location (beyond disambiguation needs). This the base notation collapses to standard algebraic notation.

The major difference to standard chess notation, and which stops it from the possibility of collapsing to being standard notation by the end of a game, is instead of a sequence of turns on a line, we specify each turn on it's own line, and name it.

Finally, on each line a player may optionally make a short comment on their own turn. This comment is public as soon as the turn is made, being visible to the other player. This means the game is a minor IM system. The comment length is not limited in this writeup yet, but is expected to be in implementation - and that will then be reflected here.

thus a game progress is (each turn being white, then black):

   0b. <challenge> # comment
   1w. [resolve] move <challenge> # comment
   1b. [resolve] move <challenge> # comment 
   2w. [resolve] move <challenge> # comment
   2b. [resolve] move <challenge> # comment

etc.

Remember that "[resolve]", "<challenge>" and "# comment" information are optional - they are not part of every turn or required.

Any position in the game may be indicated by not only turn, but part turn, given in a decimal-like indication. eg

• "2w." would be the beginning of the 2w turn (ie, "1b" completed)
• "2w.1" would mean the "resolve" stage of 2w was complete, but not yet the move or challenge
• "2w.2" would be after the move, but before the challenge
• "2w.3" would be after the challenge, and logically equivalent to "2b."

Note: this notation is not yet locked in, and open to change if and when limitations are discovered or additional features required.

[edit] Forking games

If game numbers are recorded (as an online version may be). then in conjunction with the turn indications, the location of any part of any game may be indicated, and then different players may fork the game and play from there. This "forked game" should be indicated as such within the interface. The idea is that interesting locations in interesting games may be explored multiple times. Forked games naturally may be forked themselves, etc.

Thus:

   gamenumber.turn.part-forknumber.turn.part-forknumber

Note that "turn.part" does not reset with a fork, meaning later turn.part numbers are always higher than earlier ones in this.

To clarify - if a game is indicated in a manner which ends at the "gamenumber" or "forknumber", then that indicates the entire game. If a "turn.part" is appended, then that indicates a location in that game. And if a "-forknumber" is appended, then we have a forked game, and follows the same rules of what is indicated.

[edit] Useful links:

• https://en.wikipedia.org/wiki/Algebraic_notation_(chess)
• https://en.wikipedia.org/wiki/Portable_Game_Notation
• https://en.wikipedia.org/wiki/Universal_Chess_Interface

[edit] See also

SpyChess also written up on this wiki is an older chess variant which shares the similarity that the types of each opponent's piece is unknown and is discovered through gameplay. However in Spy Chess, a piece's type is definitively known to their own side at the start of the game. Quantum Chess differs in that a type isn't definitively known, and a player can choose what each piece becomes throughout the game.

[edit] Other Quantum Chess

Suitably, this is not the only game called "Quantum Chess".

• In this game, pieces are in superposition across multiple locations: https://interestingengineering.com/culture/what-on-earth-is-quantum-chess
• And in this one, like ours, pieces are in a superposition of types, but only across a maximum of two types (not all six) and the king is always known: https://research.cs.queensu.ca/Parallel/QuantumChess/QuantumChess.html