First, I don't think the big use case is for items being traded between different games. However, a system like that is possible. Blizzard would be a good example here, since their games have a high degree of cross-pollination, and they frequently offer promotions that unlock similar items in several of their games at once. So, owning a Blizzard "magic sword" token might give you a sword item in WoW, another one in Diablo, and a sword card in Hearthstone, each adapted for its own game. This is a small use case, in my opinion.

I imagine that the big use case is for any game developer (indies especially) to leverage the marketplace without having to build one, or be locked into one provided by a single publisher/distributor. The game itself does not have to be p2p as you're suggesting. Game architecture would remain centralized, and would communicate with a blockchain where the tokens are stored.

The process might look like this:

1) A player purchases an NFT representing an in-game item issued by a wallet owned by the game developer.

2) The player sends that token to a smart-contract address, also owned by the developer, with a memo that identifies their player account.

3) The smart contract notifies a centralized game server, then sends the token back to the player's wallet.

4) The in-game item appears in the player's inventory, within the game.

There could be any number of steps involved, and the contracts could operate however you'd like. The token could be destroyed after a single use (like purchasing keys for loot crates in CS:GO) or used and traded any number of times. The game server would have to keep track of which player account controlled which token, and update players' inventories whenever the token changed hands.

One more thing - NFTs can be programmed such that creators receive an automatic royalty (a percentage of the sale lands in the creator's wallet address) whenever the item is sold on the blockchain, no matter who is selling to whom. This could be huge for indie developers, who would benefit not only from selling the original items up front, but also from the long-tail resale of such items between their players.

Why would the publisher behind Destiny care? Blizzard is the one profiting off the items. Each publisher would create their own mutually incompatible smart contract to maximize profits. Companies absolutely hate the existence of secondary markets. They want cash shop items to be tied to accounts so that every player has to rebuy the same items over and over again. It simply won't work except as an easter egg.

Players re-buying the same item is definitely profitable, but it may turn out to be more profitable in the long-term to allow players to freely trade items while taking a cut of each transaction as royalties. Also, as mentioned before, NFTs allow for single-use items. A game could provide all sorts of different items with different rules.

I'm like 90% certain that there are cross-game item unlocks in Blizzard games already.

> NFTs can be programmed such that creators receive an automatic royalty (a percentage of the sale lands in the creator's wallet address) whenever the item is sold on the blockchain, no matter who is selling to whom.

Why is that good? Who is it good for? Why would a game developer sign up for this? You seem to be under the impression that I have no concept at all of what NFTs do. The problem is that a multiplayer game server is fundamentally already a trusted third party and the incentives for gamedevs to use them are poor, while the complexities enormous. Boiling the oceans to produce a trustless ecosystem for asset transfer is a fruitless endeavor if those assets can only be reified inside of environments that fundamentally require trusted third parties.

You already need to have a trusted third party (the game server) in order to give any functionality to the assets. Once you've added that trusted third party, you've thrown away the key benefit of blockchains.

The trusted third party is effectively required to moderate custom assets in games; untrusted asset creation is an unchecked liability in general, and is expressly prohibited by the terms of many game platforms. If a player creates content that is hateful, then another player that is a child can download it, and if their parent sees that, the kid will say "I'm playing $your_game", and then the parent will raise a stink about how $your_game has $hateful content in it and $your_game exposed their children to that content. That sort of thing will certainly get your game delisted from the Nintendo or Sony stores. Even if you're only concerned with an unregulated PC market, it's going to be a hit to your sales.

If a child wanders onto a hateful website, the parent is going to say "the web exposed my child to $extremism", and then use parental controls to control what their kid can access on the web, but you cannot do that in a game. Sorry, you can't bring your $valuable_item in here because $other_player has it disabled in their content settings. You'd better believe parents are going to say "$video_game exposed my child to hate speech" and it's going to harm your sales.

Beyond hate speech, assets have to be verified by the game dev to verify their integrity; the asset has to be loadable and working without errors and without breaking the game. That's assuming there are zero vulns in the asset pipeline. Beyond merely being loadable, it should also conform to some guidelines so that the asset doesn't perform well for players with fast machines, but make the game unplayable for players with slow machines.

As for royalties: Steam Workshop already gives royalties to people who create assets (albeit at poor rates) and people already play that game. Why would I, a game developer, sign up for something that makes all of this worse, reduces my revenues, is massively more complicated, requires me to verify data against a blockchain constantly, AND increases liabilities? This is assuming you even -can- verify the data against the blockchain frequently. Even assuming you're using a blockchain with a read latency of zero, you're still performing i/o. You want to perform blocking i/o to an external datastore every single time a player wants to use an item? The only away around that would be to write a lock into the blockchain to prevent transfer with a contract and cache the ownership semantics, at which point you have completely duffed every single advantage a blockchain is giving you.

Let's say, hypothetically, that we ignored all extant games and ONLY considered new games. Again: if you're not moving an item between simulations, it's all for naught because the game dev can just implement a traditional inventory system more easily, and if you -are- moving an item between simulations, the spawning simulation and the target simulation need to be in agreement about what an item spawned in one simulation means in the other simulation. That alone is a terrifically difficult problem that NFTs do nothing to address. Few game devs would sign up for this, because it would mean that the -other- gamedev would be able to affect the balance of the economy in -their- game, potentially to catastrophic effect. It effectively ties the game economies together, but different games have fundamentally different economies with different mechanics. Who is in control of the spawn rate of assets? "You just make the asset be some random thing whose nonce is some thing that's made on the blockchain at a fixed rate determined by the blockchain itself" like CryptoKitties or whatever. Ok, fine. How do you issue a patch to alter spawn rates, balance the relative frequencies of different items appearing, or change their properties? If you -can't- do that, you can't balance your game. Balancing live game economies is -incredibly- difficult, you can't just hope to get it right on the first shot.

I completely agree with you on the boiling of the oceans. It's a problem that cryptos will have to solve in the long-term to be viable as any part of a green economy. There are a few projects that are energy efficient, but Ethereum and others have work to do. In any case, NFTs aren't specific to any one blockchain.

I think content creation and limitation is a separate issue, and not implicitly part of NFTs. You can issue a token representing a particular game object, with no ability for the player to customize or modify it. You bring up an interesting point though - there could be a limited, controllable level of customization available to players. Consider a smart contract that mints NFTs and allows certain attributes to be modified, which could affect the cosmetic or functional details of the in-game item they represent. You could sell a class of NFTs representing a certain sword, and players could pay extra for a golden version, or a version with infinite durability.

For Steam Workshop, I think you've identified exactly the issue. They control the marketplace, and set the rates. If it's more profitable for a developer to set their own rates/royalties, and it's easy enough to implement, and there are enough players willing to use NFTs (or a platform that manages NFTs for them) then we'll start to see developers use them. Marketplaces aren't mutually exclusive, so you could have some items on Steam, and others on blockchain. You could make certain desirable items exclusive to the platform that nets you the most profit.

I agree regarding difficulty of implementation - this is something that most developers won't bother with at the moment since it doesn't make economic sense, but as the ecosystem develops we'll likely see companies that provide a simpler abstraction layer for NFTs (perhaps even specializing in games). As the implementation costs drop, we'll start seeing adoption. This might take several years.

Regarding blocking I/O, I don't think it would work like that, just like it wouldn't work as p2p. A game server could poll the history of its smart contracts (or the abstraction layer provided by a service platform) every few seconds or minutes, and update its centralized database of items to match whatever transactions have occurred. All reads within the game would still be to its own database, and not directly from a blockchain.