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.
> * 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.