But OK if you want to break it down more:
* Have the user prove they own a specific account (https://walletconnect.com/ I would guess would be a simple approach to this)
* Make a REST API call to check if they own the item (edit - to clarify, the API already exists, you just need to do a single get request)
* Set local flag in game to say "yes they own the item"?
What more detail would you need?
Implementing the weapon. Paying for that implementation.
Concrete example: I buy an NFT for a sword in World of Warcraft. I want to take it with me to FFXIV. Now FFXIV has to implement the sword. Its looks, its behaviors, its power, in a completely separate engine and world.
They - Square Enix - also probably have to pay Blizzard for the trademark and copyrights to the sword. Yet when I buy the sword that money goes to Blizzard, not Square. So... why would Square do it?
Plus, implementing a "yes, person with email address N owns sword X" rest API is pretty straightforward. You could even implement public/private key signatures for authentication of the receipt. It just would be stored in someone's email inbox instead of the chain.
Implementing an in game item? That's already part of your game, right?
> Paying for that implementation.
You can buy an NFT entirely on chain, that's surely not in doubt.
> Plus, implementing a "yes, person with email address N owns sword X" rest API is pretty straightforward. You could even implement public/private key signatures for authentication of the receipt. It just would be stored in someone's email inbox instead of the chain.
Yes, I totally could re-implement all of these things. I could handle payment info, get people to manage their own public/private keys using my own implementations and have them copy & paste it from an email (?). I'm not sure I follow the flow there where people copy keys from emails into my game and how duplication is stopped but it sounds like an awful flow.
My point, as I tried to emphasise, is that I can get those things without building them. They already exist if I manage that part with an NFT.
So the question has increasingly become (as the field matures) - why build it myself? Why not use existing, working infrastructure?
> Concrete example: I buy an NFT for a sword in World of Warcraft. I want to take it with me to FFXIV. Now FFXIV has to implement the sword. Its looks, its behaviors, its power, in a completely separate engine and world.
I've not said anything about sharing between games, and the complex part of that is identical whether it's with crypto or not. What the global shared database part solves is that either game can easily check, if this was something they wanted to do.
Nah, not for the usecase of moving items between games - one of the biggest features touted by NFT enthusiasts.
But that aside...
> get people to manage their own public/private keys
For a receipt, the individual users don't need keys. For proof of ownership, that ship has already sailed off into the sea of fraud and pyramid schemes, and we don't expect to see it again. When people are trying to sell NFTs of artwork to the original artist (aka blackmail), you know it's jumped all the sharks.
> They already exist if I manage that part with an NFT.
Most of this already exists in a system regardless. Adding a rest endpoint on the top of a database entry is usually pretty trivial - especially for something as basic as "retrieve and display this row in the DB" - and "already exists" in the form of libraries. And by using a blockchain as a database, I'm actually adding a lot of complexity to my system.
> Why not use existing, working infrastructure?
One, the existing and working infrastructure already exists. All the elements of a purchasing stream are implemented as libraries.
And it's not as if you can stop caring about how money flows, because there are laws that require you to do a lot of bookkeeping and pay taxes on that money (no matter the form the transaction initially took).
Why not use a blockchain as a distributed DB? Because it's slower and more expensive. Because it provides no functionality you don't already want or need to have locally, especially when we're discussing a game.
In other words, NFTs - from a company's point of view - provide the same benefits and detriments as a normal event-stream DB, but it's slower, more expensive, and it includes transactions from every other company using that blockchain.
> What the global shared database part solves is that either game can easily check, if this was something they wanted to do.
Why would the first party need to check an external database, when their game engines literally require them to implement it internally?
Why would a second party check the external database when there are licensing issues that require them to talk to the first party in the first place?
That's not what I've been talking about though.
> For a receipt, the individual users don't need keys. For proof of ownership, that ship has already sailed off into the sea of fraud and pyramid schemes, and we don't expect to see it again. When people are trying to sell NFTs of artwork to the original artist (aka blackmail), you know it's jumped all the sharks.
That wouldn't apply at all for an in game item. Do you understand that two NFTs pointing to the same url would still be entirely distinguishable?
> One, the existing and working infrastructure already exists. All the elements of a purchasing stream are implemented as libraries.
"There is a library" and "there is already running maintained infrastructure" is quite different.
> And it's not as if you can stop caring about how money flows, because there are laws that require you to do a lot of bookkeeping and pay taxes on that money (no matter the form the transaction initially took).
I would be involved in the initial sale, but no auctions/trades/secondary sales.
> And by using a blockchain as a database, I'm actually adding a lot of complexity to my system.
I've outlined the steps required and can't see what you think would add a lot of complexity.
> Why would the first party need to check an external database, when their game engines literally require them to implement it internally?
How are you managing trading items between users without some database external to either users machine - unless you're talking about an entire p2p db of ownership which sounds frankly even more complex.
You're jumping into a use case I've not posited and then bringing up things which don't seem to make sense (art NFTs created by random people).
I don't think this is very productive so I will just leave you with one thought:
Imagine you were already using the blockchain for this, and that was normal for games to do so. Now someone tells you that you could actually use these other libraries, and maintain your own database, and stop users from selling/trading however they wish but only through you, and you could build your own site for trading instead.
Would you say "Yes, that brings me the features I really need - I should change to this different architecture"?
So is a cryptographically signed receipt. So is an internal database log. These are all that are required for the sale of items in videogames.
> "There is a library" and "there is already running maintained infrastructure" is quite different.
You'd still need a library (or a dozen libraries) to implement a NFT DB in your game. And probably some custom coding to wire it into your local DBs required for the game.
Also, RDS. And databases built into the game engines (such as Unreal, Lumberyard, Unity, et.al.). Running and maintained infrastructure already exists for databases.
> I would be involved in the initial sale, but no auctions/trades/secondary sales.
NFTs can be set up in a way when funnels a portion of future sales/trades back to the generating party. So yes, you most likely will be legally involved in the future sales, unless you explicitly opt out when creating NFTs (which doesn't make much sense, from a "we're doing this as part of our revenue generation" point of view.
> How are you managing trading items between users without some database external to either users machine
This must be done regardless. See previous comments about the NFT DB being too slow to act as the source of truth for videogames.
> Would you say "Yes, that brings me the features I really need - I should change to this different architecture"?
From a purely capitalistic point of view, definitely. It gives me more control over how my product is being used. Why would I want to allow people to trade cash shop items (based on your earlier comments, without letting me take a portion of those trades/sales) when I can make two sales instead?
It'd also save me the CS costs associated with anything that goes wrong with a NFT auction/trade/sale for items in my game. Because I know they're not going to blame OpenSea, they're going to blame me. How do I know this? Because players already blame the game provider for things like DDOS attacks and internet outages.
Corporations love control. Even today, they'll spend more money on infrastructure and development to maintain that control. You can see proof of this in the NFT space with how game companies are implementing their own private blockchains to do NFTs. No need for "what if" games.