Hacker News new | past | comments | ask | show | jobs | submit login

Game developers can mint more tokens at any time. There's nothing technical ensuring scarcity of NFTs, and gentleman's agreements don't need a blockchain.

For game assets the game is necessarily the central trusted authority. Ethereum has a speed of C64 and latency of a postal pigeon, so you can't run a game server on the chain. Therefore, you have to trust an off-chain game to actually honor what the blockchain says. This is not substantially different than Steam CS:Go skins, except for industrial-scale coal-rolling.




> Game developers can mint more tokens at any time.

That's a very valid criticism of most game implementations (maybe all? I only know like 3 and they are all centralized blockchains -- puke), and that's why I'm staying away from them too, at least for now.

But I cannot deny there's real potential here, I can imagine totally open source games without servers, just p2p connection for battles (like we used to do to play Age of empires) and its assets backed by NFTs


As has been said, how does the game engine enforce ownership of those assets? The best it can do is query a blockchain (and for p2p games without central server every client must also become a node in all backing blockchains) and check ownership of corresponding private key[s]. There is absolutely nothing stopping you from minting a new NFT describing in-game assets, therefore the *content* of NFT must be signed by players in a match or some other external entity, but the blockchain makes no guarantees about the content.

Most of the blockchain properties only apply to on-chain assets. The very moment you involve an off-chain party, blockchain becomes append-only database with performance of table top calculator and latency of postal pigeon and is therefore a shitty database.

The only valid use case I see is a smart contract that automatically issues certain assets, which could be seen as somewhat of a solution searching for a problem, but games are not the problem. With games all clients must agree on game state anyway, storing game state on the blockchain is too expensive/cumbersome and if you have to agree on game state anyway, the state can also include assets.


The "content" doesn't matter, all that matters is the NFT id (or hash, whatever is used to uniquely identify it). The game is what players have to coordinate about, make sure is the same one, and the exact same version of it. Because the code is the only thing that gives real meaning (the content) to that NFT. The blockchain is ONLY used to track ownership of and id (The NFT) nothing else is required.

I mostly agree on everything else you said as the current state of NFT-games. But unlike you, I do see potential for different kinds of games and dynamics that are not possible or impractical in database-games. I don't think they will be the same type of games we are used to, if you kill it now, we will never see into what it evolves.


The game client reads only canonical game assets - you can't just add any nft willy nilly.

An nft can also include a hash of some offchain data. In this way it can make a verifiable claim about content.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: