Create the game contract design proposal document.
alilloig opened this issue · 2 comments
Issue To Be Solved
We have to create a rock, paper, scissor style game on chain, showcasing the use of the [dynamic nfts](#6 and a commit and then reveal scheme for plays. This game will also serve as a basic example for turn and decision based games.
Suggest A Solution
- Ideally the solution will be generic enough that it facilitates the creation of any turn and decision based game, from rps to a pokemon style battle.
- The logic of the game mechanics should happen after both players have submitted their commits. How the puppet account pattern affects the design of this aspect? We need to sync with the Solutions Team and TEA to understand how this will actually happen.
- We need to define a structure of how matches, in lack of a better word, happens. The situation when one or more players escrow one or more NFTs and submit an amount of plays (commits), then the game produces and outcome that likely will be a result (defeat, draw, win) and the mutation of zero or more NFTs. The suggested solution will be the creation of tournament resources. They will conform to the collection defined for mutating NFTs by the DynamicNFT proposal and keep track of a structure of plays (commits), turns (reveals), matches (sets of turns) and rounds (sets of matches). Based on this tracking of rounds the tournament could maintain leaderboards and perform other actions such as giving prices. Tournaments could be only created by the owner of the contract or publicly depending of game creators preferences.
- We will also need a resource for representing the user state for a certain game, think of a user profile or a saved game. An account will be able to hold only one state per game if this resource is stored at this own storage path, being effectively the way of "login" for a user into any tournament of a game, by escrowing it to it. This resource should conform to the DynamicNFT mutable resource interface for reflecting the outcome of tournaments (or smaller sets of plays). If the mutable metadata of the NFT holds a record of sessions when the NFT has been escrowed, that could be used in the creation of the tournament leaderboards.
- In a further version way may want to include NFTs that are mutated by playing the game and also need to be put in escrow for being able to commit plays. Those could be defined as assets. User state could be a more specific type of game asset.
- A rough pseudocode draft, taking in consideration the streamlined tokens proposal:
pub contract Game {
pub resource interface Asset: DynamicNFT.Mutant, NonFungibleToken.NFT, MetadataViews.Resolver
pub resource interface UserState: Asset // DynamicNFT.MutableCollection for holding other mutant assets??
pub resource interface Tournament: DynamicNFT.MutatorCollection, NonFungibleToken.Collection, MetadataViews.ResolverCollection
WIP
- Details of the technical implementation
- Tradeoffs made in design decisions
- Caveats and considerations for the future
If there are multiple solutions, please present each one separately. Save comparisons for the very end.)
Context
The DynamicNFT and Commit // Reveal proposals should be done or at least defined before creating this proposal document.
Noting that this is in progress and can be seen on this Notion page
I'm moving this to done since the doc was made in September and I believe than rather than improving it we are moving to a final design / explanatory document that will include the the puppet account model based on two full weight keys and the dynamic NFT + game mechanics which are kind of interdependent