nba(jump ball): cadence #273
Conversation
chumeston
commented
Dec 11, 2024
chumeston
commented
- Write initial contract.
* Write initial contract.
* Next commit.
* Fix win logic.
* Fix pre logic.
* Make opponent optional.
* Next iteration.
* Create player resource.
* Fix pre{}.
* Update access.
* Update to deployable contract.
* update UInt64 to String.
| } | ||
|
|
||
| // Create a new game | ||
| access(all) fun createGame(gameID: String, startTime: UFix64, gameDuration: UFix64, selectedStatistic: String): String { |
There was a problem hiding this comment.
We should add an entitlement for createGame, addOpponent, and setMetadata to ensure only the owner/entitled reference to the Player resource can call the methods in case a capability for the resource is published
| return self.opponentCap | ||
| } | ||
|
|
||
| access(all) fun setMetadata(key: String, value: AnyStruct) { |
There was a problem hiding this comment.
We should add an entitlement for methods that should not be callable publicly after getting a reference to a Game resource using the getGame contract method, which might be setMetadata, setOpponent, and depositNFT?
| } | ||
|
|
||
| // Helper functions for contract metadata | ||
| access(all) fun setMetadata(key: String, value: AnyStruct) { |
There was a problem hiding this comment.
This can be called by anyone - we can address by making it access(contract) and wrapping in admin resource, or we just don't have a setMetadata method if we are not currently making use of the metadata map
| } | ||
|
|
||
| // Destroy a game and clean up resources | ||
| access(all) fun destroyGame(gameID: String) { |
There was a problem hiding this comment.
This can also be called publicly, maybe this should be part of the Player resource with logic to validate the creator/opponent address? And/or this could be part of the Admin resource?
| } | ||
|
|
||
| // Factory function to create a new Player resource | ||
| access(all) fun createPlayer(playerAddress: Address, collectionCap: Capability<&{NonFungibleToken.Collection}>): @Player { |
There was a problem hiding this comment.
Any playerAddress and collectionCap can be passed here not necessarily those of the account calling this method
We might be able to address this:
- By using Player resource UUIDs rather than addresses to tie games to users so that addresses are not needed anymore, or
- By using an entitled capability param here and getting the address from the capability itself, though we should avoid storing the capability if it's not useful (it looks like
collectionCapis not actually used?). Also the address value would remain the same in case the player resource is transferred to someone else and there may be limitations related to that
| panic("Player does not have a valid collection capability to join a game.") | ||
| } | ||
|
|
||
| gameRef.setOpponent(opponentAddress: self.address, collectionCap: self.collectionCap) |
There was a problem hiding this comment.
It looks like the game creator address is added instead of opponent address? Or maybe I'm misunderstanding something about the expected flow/caller for addOpponent?
| // Player resource for game participation | ||
| access(all) resource Player { | ||
| access(all) let address: Address | ||
| access(all) let collectionCap: Capability<&{NonFungibleToken.Collection}> |
There was a problem hiding this comment.
this is for sending the nft to the user if they win?
There was a problem hiding this comment.
i think some things are missing, like how player resource interfaces with the game, will be nice to have some tests with transactions and scripts that define how the contract is to be used.
Also it's not clear if this is supposed to support 1 nft type or it's meant to be generic. Might also be better to not save capabilities but instead get the capability for that nft collection using metadataviews to resolve the collection public path
