Get desktop application:
View/edit binary Protocol Buffers messages
* One move in the channel game. The std::string-encoded BoardMove bytes correspond to a serialised message of this type.
* The full board state of a game channel of Xayaships. The generic board state for libgamechannel (std::string) is the serialised form of this message. This state applies only to channels that already have both participants. While waiting for the second player to join, the core game logic never invokes any board functions at all, as no disputes / resolutions are possible in that case.
* Which player (index into participants array) is the current one. Missing in a "no turn" situation, i.e. when the game is finished. Note that this information is sometimes redundant (e.g. when the initial commitment from player 0 is there but not yet the commitment from player 1, then it is clear that it's player 1's turn). The field is still always set (and must match the implicit value where applicable) to simplify the "whose turn" method.
* The two position commitments from both players (or only one if the second is now to be made). These are bytes encoding 256-bit hashes. When the game is ended and the positions are revealed, the corresponding hash is cleared to save space. The fields remain set, though, just the bytes are set to an empty string.
* The hash commitment of the "random seed" of player 0 when determining who starts the game. This field is cleared again when the preimage has been revealed. Like position_hashes, this encodes a 256-bit hash.
* The preimage of the "random seed" of player 1. This can be arbitrary data up to 32 bytes in length. This field is cleared when the starting player has been determined.
* The information known so far about the ship configurations of both players. These fields are initialised (with all zeros for both players) when the starting player has been determined. This data could be removed as soon as the position is revealed (and checked against previous answers), but we keep the field set since that data can be used by frontends to show the guesses against the final position of the other player.
* If a shot has been made and not yet answered, then this field is set holding the target location. The shot is always by the player whose turn it is not, and the player whose turn it is should answer in the next move. If a player reveals their position instead of answering the shot, this field remains set. That allows us to accurately count turns.
* The revealed full ship configurations as 64-bit vectors. When the first player reveals, this is initialised to two zero elements (and then the revealed position set). So the array might have zero or two elements at any point in time. Note that in theory it is not necessary to keep this information in the game state, as it is enough to just verify the commitment when the move is made. But having it in the game state is useful for frontends.
* If it is already determined who won, the player's index.
* The "known information" about the ship configuration of one player: Where coordinates have been guessed and where (those) have been hits. Both are boolean arrays encoded directly into a uint64.
Used in:
* The coordinates that have been guessed "against" this player.
* Those of the guessed coordinates that were hits.
* A move that creates the position commitment for either of the players. Depending on whether this is the first or second player's move, either the seed hash or the seed (as preimage) will be set.
Used in:
* The uint256 salted hash of the position.
* If this is player 0's move, then the hash of the random seed data.
* For player 1's move, the "preimage" of the random seed data. This can be any string of bytes up to 32 in length (256 bit).
* A move revealing the original ship configuration and salt.
Used in:
* The full position of ships, encoded as bit vector.
* The salt data, which can be an arbitrary string up to 32 bytes (256 bit) in length. The commitment hash is computed by concatenating the 8 bytes of the position in little endian and the salt bytes.
* A move that replies to a shot
Used in:
* The reply for the previously targeted location.
* Possible reply values.
Used in:
* The move of player 0 revealing the random seed preimage.
Used in:
* The preimage data for the previous seed hash. This can be any string of bytes up to 32 in length (256 bit), and it must match the previously committed SHA-256 hash.
* A move that guesses a location for a shot.
Used in:
* The targeted location as index into the bit vectors (0..63).