-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gaming Smart Contracts #3
Comments
Following up on this morning's meeting with some notes on current state & next steps: Current state: Next steps We will spend some time thinking about these components and regroup on 09/12 before meeting with the TEA team midweek. |
There might be a couple missing issues here. I don't see an issue for the NFT metadata win/loss view or an issue for creating the initial NFT contract. Can y'all create those issues too? |
I included the metadata as a part of this issue #6 Probably better to restructure and create separate issues for those? |
Maybe. Actually #6 is probably fine now that I think about it |
Will specify about the NFT utility of the NFT as a win/loss record and that that should be the main focus of the view |
As communicated to TEA team, here's our current thought process on the initial approach toward a Rock Paper Scissors MVP: Based on our Monday convo, it sounds like shared priorities are defining the NFT, its attributes (mutable v. immutable), when and how those attributes are changed as well as custody during gameplay. With that in mind, we’re thinking that the commit-reveal pattern should be our focus in the next iteration, focusing instead on a simpler, single user transaction UX. TL;DR: Players submit a single transaction at the start of a match to deposit their Game Piece NFT into escrow. Throughout gameplay, the game client submits both players’ moves to the chain in a single transaction every round. The NFTs are then returned to each player after the game is over. What that looks like is:
Here’s a visual diagram in case that helps. Feel free to comment there as well. Still working out the specifics of each component as well as which account each resource is stored, but we are thinking that the NFT and Escrow mechanism will be defined in one contract with the Game & GameAdmin defined in another. Álvaro will work on the former while I work on the latter. |
Great summary! I'm interested to hear how you think the escrow mechanism could be defined in the NFT contract. By defining that in the contract, do you just mean defining how contracts that escrow the NFTs can modify the NFTs metadata (as well as the associated views?) or defining the entire escrow mechanism? |
I just found this on my opened tabs, sorry for the delay! This will be a little more detailed on the design document, but we are talking about defining the entire escrow mechanism in the NFT contract. Why? Because at least so far I haven't find another way of restricting the access of the owner of a resource to call a method in it rather than the method being
|
Context
We need to create and documentate the basic contracts for supporting NFT based games on Cadence showcasing best practices for the most common use cases, including a MVP rock, paper, scissor style game.
Definition of Done
The text was updated successfully, but these errors were encountered: