Check out Atomic Chess, our featured variant for November, 2024.

This page is written by the game's inventor, Peter Aronson.

Transactional Chess

By Peter Aronson

Introduction

          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:

Each of these terms will be discussed in more detail below. Some additional useful terms are:

General Rules

          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 Turn

          A turn goes as follows:

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.

Rollback

          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

          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.

En Passant

          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.

Notation

          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+
                     Ng1-Nf3

A graphic of the updated board would be a good idea as well, if possible.

Example Game

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?

Yes.

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.

Notes

          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.

Acknowledgments

          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.