> * Make a website
> * Setup the DB
> * Manage user accounts
> * Manage payment information
> * Code the sales, auctions, etc
> * Build the integration with my game & my API
> * Manage and maintain the server
> to do it the traditional way. To do it on chain I
> * Create a trivial NFT contract
> * Build the integration with my game & a generic API
I don't understand this argument.
You describe step-by-step in a detailed way what would be needed to implement the usual way and then simply glosses over "build the integration with my game & a generic API". That is exactly the tricky part, isn't it?
The integration to your game also depends on your game having some kind of linking between the NFT and your in-game item (hence a database). It depends on the communication with this generic API being reliable enough so you can completely offload your load to that, if it's not reliable for that you'll need to create intermediate API layers to deal with these issues, and so on and so forth. Generic APIs are never really generic.
And this is the most beaten example already, what else can this provide apart from giving me ownership of in-game items?
Trivialising the work of "build the integration with my game" as something that "just happens" is a naive way to shove the hard work unto a trivial step.
Handling and managing money transactions to run an auction sounds very much like a tricky part, there's a lot of regulation I'd be getting involved in going down that road.
Building the integration with the game doesn't sound hard, no, and it's the same either way. Authenticate, call API to check ownership - beyond that it's down to your game. (edit - to be clear here, the API already exists, I'm not saying "build a generic API" but "use an existing, highly interchangeable service")
The point here is that that side is identical in both cases.
> The integration to your game also depends on your game having some kind of linking between the NFT and your in-game item (hence a database).
I'm not sure what you mean, this can be as simple as a hard-coded list in the game, it doesn't have to be a shared database.
> It depends on the communication with this generic API being reliable enough so you can completely offload your load to that
Sure, but they really are quite generic - you can swap them out for one another easily, they implement the same interface for this kind of work. There's subtle differences when it comes to more complex cases but "read public information" isn't one of them.
> Trivialising the work of "build the integration with my game" as something that "just happens" is a naive way to shove the hard work unto a trivial step.
What about this do you think is going to be the tricky part? Authenticating the user? Checking if that account currently owns the NFT?
What makes you believe there won't be regulations on trading NFTs in the future? The moment NFTs become an instrument for money laundering you're going to end up with the same KYC regulations as any other financial instrument. There is nothing in NFTs that protect companies using it to be above regulations. They simply don't exist yet which doesn't mean they won't ever come. There is money in this, there will be regulations and major companies will have to abide by them.
> Building the integration with the game doesn't sound hard, no, and it's the same either way. Authenticate, call API to check ownership - beyond that it's down to your game. (edit - to be clear here, the API already exists, I'm not saying "build a generic API" but "use an existing, highly interchangeable service")
> What about this do you think is going to be the tricky part? Authenticating the user? Checking if that account currently owns the NFT?
I don't know, I don't work on the space. Leveraging from my 20 years of career I'd say that it's never trivial to integrate with a 3rd party for any kind of complex business logic.
Like never in never ever, I've never seen it be just a case of "call this API, save some data" and that's why I have this instant reaction that you're glossing over a part that isn't that trivial. Even if the APIs exist, are generic, etc., integration is the hard part.
Even more reason for me to not want to be involved in the actual trading part.
> There is nothing in NFTs that protect companies using it to be above regulations.
Sure! The crypto-bros are wrong that there aren't/can't be regulations on these things, as are those complaining it's an unregulated area.
> I don't know, I don't work on the space. Leveraging from my 20 years of career I'd say that it's never trivial to integrate with a 3rd party for any kind of complex business logic.
This isn't complex business logic, that's my point. There's _already_ a standardised API. As I've said, there are annoying differences, but they are for more complex use cases and "read public data" is about the simplest there is.
To break it down a bit more, you utilise two key things. One is the standard API that all nodes have (https://ethereum.org/en/developers/docs/apis/json-rpc/) which acts the same for the use case here. There are public ones, you can pay a company to run one and you can if you want run one yourself. The end user can be free to swap between any of these.
The interface there isn't so nice, as you can ask for data stored somewhere, but finding exactly what address to read isn't that nice. Helpfully it's extremely generic so you can use a library to help with that step. You would do something like this in python:
web3 = Web3(node_provider_url)
my_contract = w3.eth.contract(abi=my_abi, address=my_contract_address)
print(my_contract.functions.my_read_only_function().call())
That's it. You're pulling from a shared database.
I hope that helps explain it a bit more - the API/backend stuff is generic and doesn't have to be run by you. However the only real external piece here is the storage layer - you're still in control of the data structure & functions (you write the contract). You're not relying on a third party to manage a "game item" API and hoping they don't change it, if you use a third party here it's about paying someone to run an open source project for you on their hardware.
There is a fairly specific kind of game where anything like this would even be useful and arguably it is impossible for the practice to not be predatory anyway. It is difficult to imagine an entity that would do this without also wanting the kind of complete control that a blockchain supposedly exists to avoid.
From there, implementing "Player X has given item Y to Player Z" is pretty straightforward. It's even built into most RPG multiplayer games by default, unbound to any form of external payment.
Multiplayer games also add event logs - creating a immutable record of all inventory changes - just so customer service (CS) can do their job. For example, in Everquest, GMs (aka CS) were able to see that yes, indeed, a player did get the drop from the dragon, even though it later glitched out of their inventory, and re-gifted the item to the player.
So, for a single game, a blockchain only adds a second, delayed (and relatively expensive, since it requires extra compute resources to create) record of events that are already recorded.
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.
The real issue with responses like this is that you can do anything with computers anyway. The blockchain basically gives you a
* Globally writable database
* With stored procedures
* And row level security
Now, you can always swap out that with a centralised service. Turing machines can do stuff and machines can talk to each other. Whether it's possible to build a technically equivalent thing is not really the important question.
What tends to happen though is that the underlying infrastructure if supported by a profit-making company is that it has its own agenda and desire to control access. There's no real desire for the base layer to be open, it's not profitable in itself.
One of the more appealing things to me in the area is that there's a lot of work with shared interfaces. Working with the ERC721 spec I can easily make a non-fungible token that refers to a ticket at a conference, or right to claim a financial security, or game item, or has a link to a wiggly line or whatever I want. Someone else can build an auction contract, and my nft will automatically work in it, as will anyone elses. If you have control of the NFT you can pick which auction type/contract/service you want to use. I don't (and shouldn't) care, that's not the part I build or manage.
Finally, "but can't you do it with postgres and ..." is true but there's a huge shift that's happened. Before, sure, I'd have to have built all this stuff on chain and have all of the complete pain-in-the-arse stuff to deal with that comes with crypto. But now that all exists.
So to make, say, an in game item that people can re-sell, swap, etc, instead of
* Make a website
* Setup the DB
* Manage user accounts
* Manage payment information
* Code the sales, auctions, etc
* Build the integration with my game & my API
* Manage and maintain the server
to do it the traditional way. To do it on chain I
* Create a trivial NFT contract
* Build the integration with my game & a generic API
That's it. All the other work, auctions, etc. has been solved and built already. User accounts are already managed.
You can always solve it another way. The more interesting question is in which cases should you solve a problem in certain ways? Not everything makes sense on chain, the database is slow and public (and even for very cheap chains comparatively expensive), and the stored procedures are extremely limited.
However some things can fit well - do you need to create some kind of economic incentive & want to let market forces control things (for example, filecoin and paying people for storage)? Maybe just creating a token on existing infrastructure will fit your needs. If it does, does it make sense to build even more things yourself?
Disclaimers - I am currently doing contract engineering in this area but am not looking for work, have only small holdings and am not here to shill for anything.