By Peter Aronson
Transactional Chess is a Chess variant produced by treating sets of moves of each player at orthodox chess as a transaction in the sense as it is used in the field of Computer Science. The resulting game is a sort of demented version of Kriegspiel.
What Is a Transaction?
Loosely, a transaction is a set of grouped actions that all either happen or don't happen. Formally, according to Transaction Processing: Concepts and Techniques by Gray and Reuter:
A transaction is a collection of operations on the physical and abstract application state.
In Transaction Chess, a transaction is a set of changes to the squares of the board that either all happen or all do not happen. The following concepts are associated with a Transactional Chess transaction:
- A pending set of moves is a number of moves (up to five) that have not been committed yet, hence might or might not happen. A piece may move move than once in a transaction.
- A commit is when a pending set of moves is made actual as opposed to potential. They become visible to the opponent, and they can no longer be rolled back.
- A rollback is when a pending set of moves is discarded.
- A lock is placed on a square when it is modified: that is, when a piece either moves to it or away from it. A piece may not move to a locked square.
Each of these terms will be discussed in more detail below. Some additional useful terms are:
- Committed view: A player's view of the board as of the most recent committed positions of both players.
- Transactional view: A player's view of their own position as of their most recent move, including their pending (not yet committed) moves, and the opponent's position as of the opponent's most recent committed position.
- Potential view: The referee's view of the board, including both player's committed annd pending moves.
The rules of Transactional Chess are identical to those of orthodox chess, except when noted below. In general, Transactional Chess is played much like Kriegspiel, with a referee and three boards. Moves are only visible to an opponent after they are committed. The referee is responsible for updating a player's board when their opponent commits, keeping track of locked squares (checkers on the referee's board would work), and for informing players when they attempt to move to a locked square.
Once a player has successfully moved, they must decide if they wish to commit their current set of pending moves, rollback their current set of pending moves, or neither. A player must commit under the following circumstances: if they have captured a piece that turn, if they have promoted a piece that turn, if their transactional view indicates that they have put their opponent in check, or if their committed view indicates that they had started the turn in check.
It is illegal for a player to make an illegal chess move according to their own transactional view. The move may appear to be an illegal chess move according to the potential view.
If a player's transactional view indicates that they have no legal move and their committed view also indicates that they are not in check, then a stalemate occurs.
If a player's transactional view indicates that they have no legal move and their committed view also indicates that they are in check, then they have been checkmated.
Structure of a TurnA turn goes as follows:
- A player attempts to make a legal Chess move, the legality of which is determined using their opponent's visible (committed) position.
- The referee informs the player if the square that the player attempted to move a piece to is locked. In the case of castling, the referee informs the moving player that one of the squares is locked, but not which one. Note that you may move through locked squares as long as you do not land on them.
- If the move did not succeed, the player chooses another move. This continues until the player finds a legal move. (It is possible that the player is stalemated, in which case it is the referee's task to declare the game a draw.)
- Once a player has successfully moved, they decide if they wish to commit their current set of pending moves, rollback their current set of pending moves, or neither. A player must commit under the following circumstances: if they have captured a piece that turn, if they have promoted a piece that turn, if they have apparently offered check that turn (as determined from the committed position of opposing side's pieces), or if they had started the turn in check. A player must commit or rollback (their choice) if they have just completed their fifth move in a row without a rollback or a commit.
When a player commits, their pieces' current positions become visible to their opponent (possibly placing their opponent in check), and all locks that player held on squares are released. The player's next turn after a commit occurs in a new transaction.
If a commit places the committing player in check, the committing player is mated, and loses immediately, unless the other player is in check as well and could not break check by capturing the committing player's King. In that case, the other player must move out of check in preference to mating the committing player's King.
When a rollback occurs, the player's pieces are returned to positions they held at the start of the transaction, and all locks that player held on squares are released. The opposing player is not informed that the rollback was occurred. It is not legal to rollback to a position that places your King in apparent check (that is, your King can not be returned to a square attacked by any of your opponent's pieces' current committed positions). The player's next turn after a rollback occurs in a new transaction.
If a piece of the moving player has been captured in this transaction, rollback will not restore it.
Locks are held on squares. When a piece moves, both the square it moved from, and the square it moved to are locked; IE, if white's Queen's Rook's Pawn made an initial double move, white would obtain locks on squares a2 and a4 (but not a3). A player's locks are held until that player commits or rollbacks their current transaction.
The opposing player is not allowed to move into locked squares, and will be so informed by the referee if they attempt to do so (this includes attempted capture of pieces that have moved in their owner's current transaction, since the square they moved from will be locked). However, a player may move through squares locked by their opponent as long as they do not end their move there. Note that because rollbacks are not announced, it is possible for a player to fail to move to a square on account of a lock, and on later turn to succeed, even though his opponent has not committed, and nothing has visibly changed. A player may move onto squares that they have locked, assuming the move is otherwise legal.
A Pawn's eligibility to be captured en passant is not determined by the turn on which it double moved, but the turn on which its double move was committed. A Pawn may be captured en passant the turn after its double move was made visible to the opposing player. So if white double moves a Pawn from a2 to a4 on turn one, and commits on turn 5, if black had a Pawn on b4, it could capture the white pawn en passant on turn 5. However, at the time of the commit, the opposing player only knows where the Pawn ended up, not how it got there, so player may ask the referee if a particular Pawn that has advanced two squares from its starting position may be captured en passant or not (or to save time, the referee may simply announce which Pawns may be so captured). A pawn that has advanced more than two squares in the just committed transaction may not be captured en passant, even if it could only have reached its current position by passing through a square where in regular Chess it could have been captured en passant.
Transactional Chess uses standard algebraic Chess notation with a few additions. A transaction identifier of the form T<transaction#>: is prefixed to the move, and commit is indicated by (C) following the move and rollback by (R) following the move. For example:
White Black 1. T1: Nc3 T2: a5 2. T1: Nf3 T2: a4 3. T1: Nb5 T2: a3 4. T1: Nxc7+(C) T2: Qxc7(C) 5. T3: bxa3(C) T4: Nc6 6. T5: Ne5 T4: Nb4(R) 7. T5: Nc6 T6: Kd1
Notice that white always uses odd transaction numbers, and black always uses even transaction numbers. That helps keep whose transactions are whose straight.
Another notation issue is how to describe the results of a commit to the other player. If you are playing back-to-back, as is done with Kriegspiel, the referee will just rearrange the opposing pieces on your board to reflect he change. If playing by mail, however, an announcement of what has changed is required. That should be in a form that gives both source and destination squares in order to avoid confusion. For example, white's commit on turn 4 above:
Black has committed: Nb1-Nxc7+
A graphic of the updated board would be a good idea as well, if possible.
White, Tony Quintanilla; Black, Peter Aronson; Referee, David Howe.
White Black 1. T1: e4 T2: e5 2. T1: d4 T2: Bb4 3. T1: Nf3 T2: Nf6 4. T1: Nc3 T2: O-O 5. T1: Bg5 (C) T2: e:d4 (C) 6. T3: f:d4 (C) T4: Ba5 7. T5: Bh4 T4: Qe7 8. T5: Nf3 T4: Re8 9. T5: Bd3 T4: Nh5 10. T5: O-O T4: g6 (C) 11. T5: B:e7 (C) T6: R:e7 (C) 12. T7: Re1 (C) T8: Re8 13. T9: h3 T8: d5 14. T9: Qd2 T8: c5 15. T9: Re2 T8: c4 16. T9: a3 T8: c:d3 (C) 17. T11: c:d3 (C) T10: d:e4 (C) 18. T13: e:e4 (C) T12: Re5 19. T15: Re2 T12: Rc5 20. T15: Qh6 T12: Ng3 21. T15: Ng5 T12: Nf1 22. T15: Q:h7+ (C) T12: Kf8 (C) 23. T17: Q:f7++
Questions and Answers
This section consists of interesting questions raised during playtesting, and their answers.
Is it legal to move a piece twice within a single transaction?
Yes. A piece may move as many times as there are turns in a transaction, so up to five times.
If a player makes a capture attempt based on his opponent's last committed position, but since the last commit the target piece has moved (but not yet committed), my understanding is that the capture will not be legal because the target position is locked. However, the opponent player will never know that a capture was attempted.
This correct. A player is only informed of their own encounters with locks, and not their opponent's encounters.
Also, if a player attempts a committed move (capture) to the destination of an opponent's piece, which is not yet committed, again, this position will be locked and the move will not be legal -- even though it would be a capture. Once the piece is committed then the same move would be legal and a capture would occur.
This is correct.
If you specify a capturing move, and a piece is no longer in the destination square, should the referee bounce back to the player indicating that the move cannot be completed as specified?
If you give a sequence of moves, and in the middle of that sequence, the opponent commits or rolls back, should the referee bounce back to the player at that point, or simply continue with that player's sequence?
The referee should bounce back to the player whenever there is a change to the board as visible. A commit by their opponent visibily changes the board, and thus the player may wish to make different following moves. Giving batches of moves to the referee at a time is a convenience to speed up the game, but the game is actually played one move at a time.
This game had its genesis when Fergus Duniho asked on the Chess Variants Yahoo Club message board for name suggestions for the game he eventually named Fatal Chessgi. In Fatal Chessgi, the capturing piece is demoted to the next weakest sort of piece. One name I suggested was Transactional Chessgi, since you were sort of buying the piece you captured (which went into your hand) with the demotion of the capturing piece. But I couldn't help but to think of other meanings of the word transactional. Thus, this game was born.
A number of characteristics of this game could be played with. The most obvious is the number of uncommitted moves allowed. Another would be to disallow passing through locked squares. To limit attacks, a piece might only be allowed to move once per transaction. Experiment!
(Technobabble alert!) The transactions in this game provide a rather poor degree of transaction isolation (although not any worse than the default operation mode of one major commercial relational database, which shall remain nameless). If a proper degree of transactional isolation was maintained, you would not be able to see your opponent's commits until you yourself committed or rolled back your current transaction. This would make the game even more difficult to play.
I'd like to thank Tony Quintanilla and David Howe for helping me playtest this game, and for their many excellent questions and suggestions; and particular thanks to David for his additional explanatory language which I have added to the text of these rules. I would also like to thank Fergus Duniho for looking over the rules and expressing his opinions.
Written by Peter Aronson.
WWW page created: May 4th, 2001.