An ink! tool for playing and researching games based on the field of "Game Theory" by using smart contracts.
This repo contains an implementation of some games within the Game Theory field.
One example of games in the field of game-theory is called "Prisoner's Dilemma" and here's a video from Youtube explaining the game's logic.
public good
: WiSYijQ7QyTvpt27CuqyoyGgi6Z3okXeuEt9JeB9mjcAdgGrock paper scissors
: XeYM2p1KSq9z3daXwfaw41ZKZLPbJGdaBdghsrfb3kPNMBmdictator
: randomness extension not currently supported on Shibuya.
Only a couple of games are currently implemented, deployable (tested on Shibuya) and playable from the list linked above, however, the implementation is done such that it follows a standardized set of traits (see
./logics/traits
directory) defined within the reusable (across contracts) code such as type and trait definitions. More details in the Project Components section.Taking such an approach means more games can be easily added to extend this project beyond the current hackathon submission.
Open-source software such as oTree, a behavioural-research platform, is often used to create games in order to simulate, with students or participants, stakes seen in real-life economics. Data from such simulations is then utilized in research papers or case-studies.
This motivates us to create a decentralized version of such a platform. The benefit of using blockchain for such a purpose is the following:
- Transparency and Trust of data quality and authenticity
- High Availability
- (potentially) Incentive-driven participation of players
Sources for economics research can vary and be equally valid. Could blockchain and lightweight yet economically motivated games introduce a fun way to contribute to this goal?
Another motivation is the exploration of !ink smart contracts functionality for basic game dynamics development.
-
Traits: the
traits
crate defines the behaviours which every game must provide as well as common types. -
Games: the games are !ink smart contracts which implement a subset or all the traits mentioned above.
- Each instance of a game contract represents a single game play.
- To play the game again, a new instance must be launched.
- The contract should terminate once the game is completed and the final round's winnings are issued.
-
[post hackathon] Router: the
games_router
create defines a generic contract which the UI will invoke when launching new games as well as when having high-level interactions with the games' contracts.- It does not contain game specific code.
- It is extensible to allow future games to be added.
-
[post hackathon] Typescript/React UI a. Add event indexing and lookup b. Add Admin / Analytics dashboard c. Add ability to connect using a wallet (see use-inkathon)
Note: please use the
nightly-2023-02-07
cargo toolchain channel. See Cargo.toml
Simply run cargo test
to run tests of all the crates / packages.
To run a specific contract's tests, use the -p
(or --package
) flag, for example:
cargo test -p public_good
or
cargo test -p rock_paper_scissors
or
alternatively cd
into that contract's directory and run cargo test
within the package code.
Since this is a workspace, each contract currently needs to be built independently into WASM / ABI.
Use the following command to a build a contract:
cargo contract build --release --manifest-path contracts/SOME_CONTRACT_FOLDER/Cargo.toml
or this to build all of them:
sh build-all.sh
Contracts can be deployed on any Substrate chain which supports smart contract functionality via !ink, however, some games' contracts
require certain chain-extensions
in order to operate correctly.
For example, the Dictator
game requires a function which generates a random value. This functionality is available in the
Randomness Pallet and can be made
accessible by using the chain-extensions
feature in !ink and add some relevant code in the Runtime to handle calls
from smart contracts.
Note: The corresponding Runtime code which handles getting the random value from the pallet is added into a forked version of "Swanky Node".
See the extension-specific code added to the forked Swanky Node Repo for reference.
- Create UI for Game Theory experiments: #44
- Use shared events: #33
- Move completely to OpenBrush
- Enable Upgradeability: #34
- Use Mappings instead of Vector of Tuple: #10