Limitations of MetaData in Native Tokens for Blockchain Games?

TL;DR is in bold at the end!

As a preface I have been theory crafting and designing a blockchain RPG game for some time now and recently I have been researching and experimenting with Cardano.

At a super high level the idea is to use minted NFT as player owned (and therefore tradable) characters in the client. While many things such as the images, animations, interfaces, etc will be off-chain the idea of storing at least some attributes as meta data within the NFT itself is one of my primary goals. This would make the history and progression of developing your unique character verifiable, secure, etc, etc.

This is all well and good for randomly generated initial attributes such as class, attack, defense, etc during the transaction which creates the token. However I would ideally like to include experience as a 64-bit value within the token metadata fields. This would allow your “character level” to be calculated by a simple linear equation in the game.

In traditional RPG your character gains experience during normal play from slaying monsters, winning duels, completing quests, etc, etc. The problem I am faced with is that minUTxOValue was specifically designed to exclude any micro-transaction type system from storing such small amounts of data in the blockchain ledger.

If players are required to provide the minAda for acquiring experience on their character token of 1.448276 by my calculation that would make engaging in battles and game activities cost prohibitive. At least I can’t imagine many users wanting to spend roughly $2 USD per fight when much more elaborate games than a humble indie developer like myself can create charge on average $15 a month no matter how much you play!

So far my best idea is using experience as function of time such that storing a timestamp on the token could then be used to extrapolate age of the token and confer experience based upon elapsed time since the character’s “birth.” This removes any impetus for the user to actually play the game though as your token would “level up” automatically just due to the passing of time whether you played or not …

Note: My backup plan if it’s not feasible is simply generating a UUID and having literally everything else be off-chain so that only creating a new character, trading of characters, or deleting (burning) character tokens requires any transaction processing.

I am open to clever suggestions from anyone else out there considering blockchain games as an interesting twist on smart contract and NFT enabled dapp development for Cardano!

2 Likes

Recording the metadata on the blockchain would only cost a net of ~0.15 ADA (just the fee) if it is an intra-wallet transaction: for instance, one would send the min-ADA of 1.45, but receive back 1.3 ADA as part of that transaction after the 0.15 ADA fee. This still might be too expensive, however. Only transferring the token outside of the wallet would involve losing the whole min-ADA.

Could you point me to the developer documentation that explains how this works in detail?

If I am understanding correctly I could have the token and minAda as inputs and the updated token and most of the ADA would be outputs returned to the user as the token never actually leaves their wallet in the case of updating the metadata.

If (or more likely when) the exchange rate of ADA increases I think this might still be cost prohibitive as another one of my goals is for the game to be free-to-play or as close to free as possible for the users.

Yes, you’re correct. Here is the documentation for posting metadata using cardano-cli. To do an intra-wallet transfer, just use one of the wallet’s own addresses for the --tx-out parameter.

You can test out an intra-wallet transfer on Daedalus or Yoroi by just sending a small amount of ADA from a wallet to one of its own receiving addresses: when you view that transaction on Cardano Explorer, you’ll see that both the input and output belong to the same wallet. For example, here is an example of a transaction from an Oracle that posts energy prices as metadata in an intra-wallet transaction each weekday: in this case the sending and receiving addresses are identical, and the overall transaction cost 0.274 ADA (more than the ~0.15 ADA minimum because the metadata payload is rather large).

Smart contracts can carry data, but they aren’t more cost effective. I think that the long-term plan for micro-payments is to use a lightweight side chain (which requires smart contracts), either a new side chain or an existing one like iota. I’ve been thinking about interim solutions that might use something like IPFS pubsub or IPNS and then periodically posting to Cardano after every n micro-transactions–I’d be happy to brainstorm about stuff like this.

My current working model of the metadata structure for an embedded character sheet was reduced to 32 bytes before I even started looking for alternative ideas.

Some sort of batch processing to reduce transactions could work but would add complexity. IPNS might be better as dynamic data is the crux of the issue. Not sure if it would be fast enough for the sort of real-time updates expected of a game though. New problems this would introduce would be determining a reasonable value for n, when to prompt user for gas fee (level-up, end of session, ???), recovering from asynchronous error conditions (lost connectivity, power outage, process termination), and probably a handful of things I am not even thinking of.

Occam’s razor keeps coming to mind …

If the NFT was used only to convey ownership and uniquely linked in a static manner then the only time transactions or ADA come into the picture is creation (mint), transfer (buy/sell/trade?), deletion (burn). The onus and frequency of all these types of transactions are entirely at the discretion of the users regardless how much or how little they actually play the game. I might not even need smart contract integration at all using Cardano’s native MA policies if this was the extent of what was necessary?

1 Like

I like your idea (in the last paragraph of your previous message) of just memorializing into transaction metadata the major events like creation, transfer, and deletion. You could even add “backup” as an event that users could initiate at their discretion. (Maybe characters wouldn’t benefit from their growing experience until it had been recorded on the blockchain–it would act a little bit like the Cardano staking system where a wallet gradually accumulates rewards that are redeemed in a later transaction.) If there is a notion of character levels in your RPG, then maybe that would be considered a major event that is memorialized in the blockchain–spending 0.15 ADA per character level might not be too costly.

That does seem more feasible.

The current experience scheme is incredibly simple yet increasingly difficult to achieve. The range of character levels was to be 1-100 due mostly to the numeric limits of using a 64-bit value for storing total experience accumulated. i.e. only the most dedicated players (read: insanely caffeinated) could ever reach the highest levels possible anyway.

If larger transient and/or historical data for tracking purposes including the accrued experience could be securely stored off-chain then perhaps only the current level and essential data should be in the NFT metadata itself?

Since level is based upon total experience a transaction which “claims experience” could presumably yield one or more “level-ups” and be processed as a single transaction. Worst case scenario if the user chose to claim experience for every level individually the journey from level 1 to maximum would be ~16 ADA (as creating the NFT character at level 1 will be a bit more).

Thank you very much for informing me about intra-wallet transactions! I suspect my next topic of research will be how to integrate side-chain storage for frequently updated data and/or how to validate and secure off-chain data for a transaction that updates NFT metadata.

1 Like

Is it necrotic to revive a thread from a few months ago with additional information?

The primary update is that my research was not particularly successful. I did not find a viable cost effective solution on-chain. I decided to scrap most of my initial concepts and focus more on the educational aspects of the game. My third and final goal not mentioned previously was to incentivize users to learn about blockchain and cryptocurrency technology by playing the game. It turns out I can do this without blockchain based rewards with my new system …

I have trashed all but one smart contract for simplification and reduction of scope. Character creation is still issuing a NFT that is used for identification, access, and starting attributes. No usernames and passwords needed here! Since it seemed like experience accumulation and other intermediate metrics were required to be off-chain I deduced there was no reason to incur a fee to “claim experience” as previously conceived. Effectively that would just be negotiating a Tx or Sc based on a private server anyway which is somewhat boring to me.

A truly decentralized solution needed something better … I want to make a real dapp unlike the BS that currently exists!

Instead I am moving forward with a concept that the token confers both identity and access and the timestamp of creation dictates the level of “wisdom” which unlocks access to higher level content as a function of time. Only the transaction that created the token ever needs be referenced for the base attributes so subsequent clever updates to metadata are irrelevant. The idea of “leveling up” is replaced by “learning up” such that bonuses to restore health, increase energy, etc are granted upon completion of content. Content does not need to be tracked as higher level content is constrained by wisdom alone.

In theory with this new system as long as I can produce content the “accrual of wisdom” dictates there is no limit to the bonus (level) a user can achieve. Some folks may repeat lower level content for a smaller bonus and some might max out for their particular tier from everything available. The beauty of it is every time I release new content on Gougen era or Voltaire era the timestamp of when I do so becomes the wisdom required. In this way new users do not become overwhelmed and veterans always have a level to reach. If I personally fail to release new content someone else can pick up from where I left off in the repository.

@bwbush Did you find a reasonably “free” solution to on-chain storage of micro-transactions? Just curious even though I have found the workaround I needed. I still have a concept drafted circa 2023 involving inventory tokens.

At this point I am arguably behind schedule. I have a very basic game, some interfaces, and a few bells and whistles, but nothing is integrated with Cardano as yet. However since it’s mostly just me working on the project and paying out of pocket I do not particularly care as I am having fun :wink:

If you are skilled at website design, graphic arts, plutus, marketing, or something technical other than C/C++ (my primary domain) then hit me up in a DM about consulting at hourly rate!

1 Like

Thanks for the news and informative update. I like how your current approach handles identity, access, and learning in a unified manner.

In answer to your question

I didn’t find a satisfactory solution for micro-transactions. My current opinion is that a side-chain or an account database would be needed. If I had to implement something like that right now, I’d probably try to develop a design that uses an IPFS database like orbit-db along with periodic recording of a database state hash in a Cardano transaction.