Package: gamechain-lobby
gamechain-lobbySometimes harder than winning a game itself is finding, rounding up, and synchronizing players. Doing it digitally in an open platform is even worse. Let's see if we can't make it better with a flow something like that below.HypothesisThis project is to test my hypothesis that the Bitcoin Cash (BCH) blockchain and mempool with zero-confirmation transaction times can make a good, open, non-proprietary game lobby system for multi-player game participation.Participants signal their intent to start or join a game (or one of its variants) with a public key-based player identity along with enough information to let participants connect/watch. Challengers can accept, and game moves/summaries/outcomes could published on the blockchain, too (seeGameChain protocol).What is Game Match-making?A multiplayer game is a set of shared constraints on possible actions starting from an established set of conditions that a group of participants engages in. For video games, finding other parties who want to accept those constraints has traditionally been a developer-driven set of choices based on their software and servers. With Bitcoin Cash, there is a global, low-cost way for sharing  transactions and messages that isn't bound to a particular server. Just as a variety of cryptocurrency wallets can find each other and transfer units of currency around the Internet, so can a multitude of game clients find other willing parties and transfer intents to play focusing on a shared protocol and not some matchmaking server somewhere.The point of matchmaking is to make sure that all players interested in a game at a particular point in time can agree on the game itself, how the game will start out, and protocols and semantics to use for making plays and taking turns. These common concerns are handled in this protocol, though each individual game will have to have a protocol and software client for actual use.ScopeThis protocol focuses on initiating gameplay: selecting a game, finding other participants, and making sure everyone is clear on the rules/variant you are playing.
Once that's done, gameplay can start based on these parameters. For example, if a server is established as part of initiation, different client applications can connect using their gamechain-lobby identities. Note that a companion protocol for on-chain game play is being tested atGameChain. Ultimately, how a game ends being played is ultimately up to the participants.There's a lot to do yet...There are a lot of details to work out and conventions/protocols to support all types of games would be very important, but I am optimistic. One thing to note is that games that use randomness should be possible, but I'm starting as simply as possible. Many games have more than two players, which should also be possible, but I will start with only two players to keep communication simple while testing this hypothesis.AssumptionsThis system works by using mempools and 0-conf to notify clients about transaction relevant to protocols used for game discovery and play. We will start with some basic assumptions.A Player is denoted by a BCH address. This BCH address is that Player's PlayerId.A Player uses their private key to sign/authenticate messages they transmit.A Player who wishes to start a game is called the Initiator.A Game is defined as: a set of initial conditions, rules that define valid actions players can take, how the game state changes based on those actions, transitions between Player turns, when the game ends, and what the outcome of the game is.A Game has a GameLobby identifier BCH address.A Match is an instance of a Game. A concluded Match consists of initial conditions, at least one Player, and a series of Player-induced actions.##Protocol
####BCH Transaction addressing scheme
The first occurring P2PKH UTXO in a GameChain Lobby transaction is the address of the message sender. Addresses of intended recipients are the remainig P2PKH UTXO(s). The OP_RETURN code is the GameChain Lobby message.####Message Format
Gamechain Lobby messages are preceded by a version byte and a message code byte. During development, the version byte will be set to 1. Message codes are as follows.Message CodeHex ValueNameDescription0x01LFGLooking for Group. Initiator broadcasts they would like to start a game as detailed in the message.0x02WTPWilling to Play. Responder indicates interest in participating in a broadcaster's game.0x03ACCAccepted. Initiator accepts responders and provides information about how to participate in the game.0x04REJRejected. Initiator lets responder know that their WTP will not be fulfilled.0x05CANInitiator broadcasts that they will not be listening for WTP responses.Message: Looking for Game (LFG)The Initiator broadcasts a signal that they would like to start a game. They send a specially constructedLooking for Gametransaction addressed to the GameLobby address of the Game they want to start. The transaction contains the following information in the OP_RETURN:Byte CountNameFormat/ValuesDescription1Protocol versionVersion byteSee protocol description.1LFG0x01Looking for Game message code. See above.33Initiator's public key<public_key>Key used by the initiator to sign messages.1Message data sizeSize byteNumber of bytes to read for message data1Signed message data sizeSize byteNumber of bytes to read for signed message data<message_data_size>Accepted parameters for gameComma-separated UTF-8 encoded values* game communication channel and protocol* start parameters (game/protocol-specific)* initiator game IDContains enough information to bootstrap a game. Maximum allowed length is 120 characters. Note that initiator game IDs should NOT be reused once they've been issued!Example message:bch-gc:tic-tac-toe,1X,MyGameId-1<signed_message_data_size>Signed messageByte array used to authenticate message from initiatorSigned version of the message dataMessage: Willing to Play (WTP)Any client listening to a GameLobby address will see LFG transactions for that Game. To play, they will send a transaction to the Initiator's address. They will use their address as the sender's address. The transaction contains the following information in the OP_RETURN:Byte CountNameFormat/ValuesDescription1Protocol versionVersion byteSee protocol description.1WTP0x02Willing to Play message code. See above.32LFG Tx ID<transaction_id>Transaction ID of the LFG message being responded to.33Responder's public key<public_key>Public key used by the responder to sign messages.1Message data sizeSize byteNumber of bytes to read for message data1Signed Tx ID data sizeSize byteNumber of bytes to read for signed transaction ID data<message_data>Bootstrap parameters for gameComma-separated UTF-8 encoded values for counter game start parameters, initiator game IDContains enough information to acknowledge a game and propose changes to initial parameters. Maximum allowed length is 120 characters.Example message:2X,MyGameId-1<signed_tx_id>Signed LFG Tx IDByte array used to authenticate message from respondersSigned version of the transaction ID being responded to. Prevents spoofing of this message.Message: Accept/Reject/Cancel GameOnce the Initiator has received responses, it's required to accept and polite to deny the Responder and start/reject the game. This is done by the Initiator sending a message to the Responder's address and using the Initiator's address as the sender's address.####Accept GameTo accept the challenge, the Initiator is responsible for setting up game  "hosting" and publishing the connection information. For the use of GameChain, hosting will be based on a new, unusedgame table address, which is an address players will send messages to. Regardless of hosting mechanism, the Initiator creates a transaction with the following information in the OP_RETURN:Byte CountNameFormat/ValuesDescription1Protocol versionVersion byteSee protocol description.1ACC0x03Game Accepted. See above.32WTP Tx ID<transaction_id>Transaction ID of the WTP message being responded to.1Message data sizeSize byteNumber of bytes to read for message data1Signed Tx ID data sizeSize byteNumber of bytes to read for signed transaction ID data<message_data>Game hosting detailsComma-separated UTF-8 encoded values for game connection informationContains enough information to let all players join the game constructed by the initiator. Maximum allowed length is 120 characters.Example message using BCH gamechain protocol:bitcoincash-gc:<txid><signed_tx_id>Signed WTP Tx IDByte array used to authenticate message from respondersSigned version of the transaction ID being responded to. Prevents spoofing of this message.####Reject GameTo turn down the challenge, the transaction contains the following information in the OP_RETURN:Byte CountNameFormat/ValuesDescription1Protocol versionVersion byteSee protocol description.1REJ0x04Game Rejected. See above.32WTP Tx ID<transaction_id>Transaction ID of the WTP message being responded to.1Message data sizeSize byteNumber of bytes to read for message data1Signed Tx ID data sizeSize byteNumber of bytes to read for signed transaction ID data<message_data>Game rejection detailsUTF-8 encoded description of game rejectionInformation about why the WTP message was rejected. Maximum allowed length is 120 characters.Example message:Sorry. Accepted another game. You can watch here @ bitcoincash-gc:tic-tac-toe:<txid><signed_tx_id>Signed WTP Tx IDByte array used to authenticate message from respondersSigned version of the transaction ID being responded to. Prevents spoofing of this message.####Cancel GameTo cancel an offered game, the Initiator sends a transaction with the following information in the OP_RETURN:Byte CountNameFormat/ValuesDescription1Protocol versionVersion byteSee protocol description.1CAN0x05Game Canceled. See above.32LFG Tx ID<transaction_id>Transaction ID of the LFG message being responded to.1Message data sizeSize byteNumber of bytes to read for message data1Signed Tx ID data sizeSize byteNumber of bytes to read for signed transaction ID data<message_data>Game cancellation detailsUTF-8 encoded description of game rejectionInformation about why the LFG message was canceled. Maximum allowed length is 120 characters.Example message: **Sorry. Can't play. :( It's bedtime.<signed_tx_id>Signed LFG Tx IDByte array used to authenticate message from respondersSigned version of the transaction ID being responded to. Prevents spoofing of this message.