Skip to main content

Game matchmaking on the BCH blockchain

Project description

gamechain-lobby

Sometimes 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.

Hypothesis

This 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 (see GameChain 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.

Scope

This 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 at GameChain. 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.

Assumptions

This 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 Code
Hex Value
Name Description
0x01 LFG Looking for Group. Initiator broadcasts they would like to start a game as detailed in the message.
0x02 WTP Willing to Play. Responder indicates interest in participating in a broadcaster's game.
0x03 ACC Accepted. Initiator accepts responders and provides information about how to participate in the game.
0x04 REJ Rejected. Initiator lets responder know that their WTP will not be fulfilled.
0x05 CAN Initiator 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 constructed Looking for Game transaction addressed to the GameLobby address of the Game they want to start. The transaction contains the following information in the OP_RETURN:

Byte Count Name Format/Values Description
1 Protocol version Version byte See protocol description.
1 LFG 0x01 Looking for Game message code. See above.
33 Initiator's public key <public_key> Key used by the initiator to sign messages.
1 Message data size Size byte Number of bytes to read for message data
1 Signed message data size Size byte Number of bytes to read for signed message data
<message_data_size> Accepted parameters for game Comma-separated UTF-8 encoded values
* game communication channel and protocol
* start parameters (game/protocol-specific)
* initiator game ID
Contains 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 message Byte array used to authenticate message from initiator Signed version of the message data

Message: 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 Count Name Format/Values Description
1 Protocol version Version byte See protocol description.
1 WTP 0x02 Willing to Play message code. See above.
32 LFG Tx ID <transaction_id> Transaction ID of the LFG message being responded to.
33 Responder's public key <public_key> Public key used by the responder to sign messages.
1 Message data size Size byte Number of bytes to read for message data
1 Signed Tx ID data size Size byte Number of bytes to read for signed transaction ID data
<message_data> Bootstrap parameters for game Comma-separated UTF-8 encoded values for counter game start parameters, initiator game ID Contains 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 ID Byte array used to authenticate message from responders Signed version of the transaction ID being responded to. Prevents spoofing of this message.

Message: Accept/Reject/Cancel Game

Once 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 Game To 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, unused game 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 Count Name Format/Values Description
1 Protocol version Version byte See protocol description.
1 ACC 0x03 Game Accepted. See above.
32 WTP Tx ID <transaction_id> Transaction ID of the WTP message being responded to.
1 Message data size Size byte Number of bytes to read for message data
1 Signed Tx ID data size Size byte Number of bytes to read for signed transaction ID data
<message_data> Game hosting details Comma-separated UTF-8 encoded values for game connection information Contains 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 ID Byte array used to authenticate message from responders Signed version of the transaction ID being responded to. Prevents spoofing of this message.

####Reject Game To turn down the challenge, the transaction contains the following information in the OP_RETURN:

Byte Count Name Format/Values Description
1 Protocol version Version byte See protocol description.
1 REJ 0x04 Game Rejected. See above.
32 WTP Tx ID <transaction_id> Transaction ID of the WTP message being responded to.
1 Message data size Size byte Number of bytes to read for message data
1 Signed Tx ID data size Size byte Number of bytes to read for signed transaction ID data
<message_data> Game rejection details UTF-8 encoded description of game rejection Information 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 ID Byte array used to authenticate message from responders Signed version of the transaction ID being responded to. Prevents spoofing of this message.

####Cancel Game To cancel an offered game, the Initiator sends a transaction with the following information in the OP_RETURN:

Byte Count Name Format/Values Description
1 Protocol version Version byte See protocol description.
1 CAN 0x05 Game Canceled. See above.
32 LFG Tx ID <transaction_id> Transaction ID of the LFG message being responded to.
1 Message data size Size byte Number of bytes to read for message data
1 Signed Tx ID data size Size byte Number of bytes to read for signed transaction ID data
<message_data> Game cancellation details UTF-8 encoded description of game rejection Information 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 ID Byte array used to authenticate message from responders Signed version of the transaction ID being responded to. Prevents spoofing of this message.

Project details


Release history Release notifications

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Files for gamechain-lobby, version 0.0.1
Filename, size File type Python version Upload date Hashes
Filename, size gamechain-lobby-0.0.1.tar.gz (13.2 kB) File type Source Python version None Upload date Hashes View hashes

Supported by

Elastic Elastic Search Pingdom Pingdom Monitoring Google Google BigQuery Sentry Sentry Error logging AWS AWS Cloud computing DataDog DataDog Monitoring Fastly Fastly CDN DigiCert DigiCert EV certificate StatusPage StatusPage Status page