Implement a chess game in Hydra head

[ghost]

NOTE: Re-iterated this into multiple increments, the first being:

• Prototype Hydra chess game on testnets #1237
• Provide a working Hydra Chess game on mainnet with simple GUI #1238

Why

• We want to "eat our own dog food", eg. use the technology we are building on a daily basis in order to:
  • Test our own stuff
  • Improve the overall user experience, even though developers can tolerate more complex UIs than the average user
  • Experience running an app/system
• Games where plays are run in a Hydra head with only results/leaderboards being kept on L1 seem a good use case for Hydra Head protocol
• Chess being a well-known deterministic game, with simple rules, few players, easy to build interface, is a good candidate
• Yet it's also challenging to provide a great UX so that it's fast and easy to setup a game
• We want to improve the DX for people wanting to build stuff on top of Hydra, this app will be a "reference DApp", something we can point people at and refer to when improving Hydra

What

• Implement an application that allow 2 players to play a Chess game remotely in a Hydra Head and record the result on L1
• The application should be easy to install even for users unfamiliar with cardano-node and hydra-node
  • Having a short and sweet README.md on a dedicated repository (e.g. hydra-chess) could be a good goal post here.
• The UI provided can be a simple TUI or even a CLI, but there should be a proper API to make it easy for anyone to build a proper UI, whether web-based or for desktop deployment
• A player should not be able to Close the head to avoid losing a game
• It must be possible to play on mainnet with minimal funds, eg. playing a game should cost a minimal amount of ADAs

Acceptance criteria

Here is the basic scenario this feature should cover:

• Two users want to play one or more Chess game using Cardano
• They can build the hydra-chess on their machines or download pre-built binaries when/if available
• They run the hydra-chess application locally selecting which public network to run on which provides some command-line interface
• They can exchange connectivity information provided by the interface and use that to configure known peers
• Once peers are configured on both sides, they can
  1. initialise a new head
  2. start a new game once the head is opened
  3. play game using some simple interface and board display
  4. see the result of the game
  5. start and play one or more other games in the head
  6. close the head once they don't want to play anymore
  7. have the game(s) results be reflected on L1

Requirements:

• OS support limited to Linux/Mac OS
• Users should have a good knowledge on their machine and network configuration (eg. be able to tweak firewall to let other people connect to their node)
• Application should be easy to download and build (eg. easier than say cardano-node or hydra-node)

[ltouro]

Suggestions:

• Time plays a crucial role in online chess. Bullet/Blitz/Speed chess are the most popular in online setting. Thus, 'Time control' would be great to have.
• The same Hydra head should handle multiple games between two players (i.e. a Head equals to a chess session).

[ghost]

• Time plays a crucial role in online chess. Bullet/Blitz/Speed chess are the most popular in online setting. Thus, 'Time control' would be great to have.

I am a lame Chess player and unfamiliar with the existing online landscape, thanks a lot for the pointers! Fortunately, Hydra Heads now have a notion of time, albeit with a large granularity, so we could already provide this feature.

• The same Hydra head should handle multiple games between two players (i.e. a Head equals to a chess session).

🤔 I would think a single Head would hold a single game to be simpler and more obvious but that seems perfectly possible. Perhaps in v2 :)

[ghost]

On second thought, running several games in sequence seems pretty straightforward and should be part of v1.

[ghost]

A few months ago, I have started working on a Black Jack game, which could easily be repurposed to support Chess: https://github.com/abailly/black-jack
The core idea is to have the rules implemented in PlutusTx be reusable from Haskell code, and abstract away the details of interacting with the hydra cluster.

[ghost]

Links to some early Miro drawings: https://miro.com/app/board/uXjVMA_OXQ0=/?moveToWidget=3458764561779396079&cot=14

[ch1bo]

Links to some early Miro drawings: https://miro.com/app/board/uXjVMA_OXQ0=/?moveToWidget=3458764561779396079&cot=14

Pasting this here as it might not be accessible to everyone:

[ch1bo]

Had a quick look around for some suitable UIs:

• https://github.com/Clariity/react-chessboard React, MIT, looks like a solid base
• https://github.com/lichess-org/chessground Fancy with multiple "wrappers" (React etc.) GPL3

Maybe we want to do it in Elm?

• https://github.com/darrensiegel/elm-chess Elm, but no license?

[ghost]

Are you aware of https://github.com/mpizenberg/elm-cardano/ ?

[Pdest08]

Why not use something like beacon tokens for peer discovery to identify players who want to play a match. Player dApp indexes on-chain requests to play (they specify what skill level match they want, game type [speed chess, regular match]).

cardano-foundation/CIPs#466

[ghost]

Indeed, the current idea is to have each player be represented on-chain through a dedicated token. My first idea was to hold the ELO score of the player but indeed we could add more metadata either encoded in the token name or the txs' metadata.
Note however that this token will be committed to a head for the purpose of playing, and redistributed back once the game ends (TBH I still don't have the full mechanics of the game sorted out 😄 ) through the usual Head protocol's Fanout mechanism hence there will be a period of time, while playing a game, where the player won't be in control of the delegation of their assets which is one purpose of the CIP you mentioned.
I don't think this is a big issue as I don't envision people tying a lot of ADAs into their game token but this again points at some limitation we are aware of about the Head protocol: Who decides how the funds locked in a Head are delegated?

[ch1bo]

We have broken down and re-iterated this original feature idea into two concrete steps we are currently taking / seeing: #1237 and #1238