NFT Fantasy 2: Why NFTs Don't Enable Knowing What You Own In Other Games
NFT Fantasy 2: Why NFTs Don't Enable Knowing What You Own In Other Games
We do that already. Inter-game communication is far less complicated than you might think.
Welcome back, friends.
Today, we’re talking about communication.
People have become quite fond of saying that NFTs will enable games to understand what stuff you own, and let you load your gear from other games. As we discussed in part one, the idea of just plucking those assets off the internet is a fantasy. So, we accept that in order to use NFTs for items in modern games, a studio would need to pre-implement any actual assets and use the NFT to refer to them.
In the kind of modern, online games we’re talking about, each item is probably identified by the combination of two things:
A string that indicates what type of item it is (e.g. WEAP_ENERGY_SWORD_ULTRA)
An item ID that refers to a specific instance of that item (e.g. a UUID like f561e9cc-06b3-4399-a274-d1e431a84cac)
If you wanted to load an item from an NFT, the contents would most likely be, at a minimum, those two things.
Since we established that you can’t store the item’s actual game assets in the NFT, the pitch we’re left with is that the NFT will tell games what you own using these identifiers, and that will prevent games from messing with your inventory, give power to players, etc. etc.
But if you’re going to suggest that a new technology can enable something, you should first understand how the current technology works. In order to demonstrate this, I’m going to make up a new platform, like Xbox Live or PlayStation Network, called Games Network Live, for the HomeXperience platform. GNL and HX, if you will.
So you boot up your HX console, and tell it to log into GNL. What happens next?
Now, I have to warn you: this part is boring to most people. Which is weird, because this is the actual technical layer at which blockchains and NFTs operate, and it’s the one people are also “excited about”. It’s going to be long, involved, and complicated, but if you’re here, you care about that sort of thing, so let’s dig in.
Everything Is Just Websites, Kinda
Pretty much all modern online games are powered by something called Web Services, which are also referred to as APIs. They’re functionally identical to how your web browser loads a web page with a URL.
Your console can also make HTTP requests, exactly like the ones your web browser makes, to services that receive them. This time, it sends some data along with it — some JSON.
If the JSON looks familiar, it’s because it’s exactly like what NFTs use. Your login request JSON might contain your username and password, and maybe some other metadata about your login attempt. It might look something like this:
Then, exactly like your web browser, it receives a response. For your web browser, the response is a HTML web page and maybe some JavaScript, but for a web service, the response is usually just JSON.
Most importantly, the response contains an authentication token (or “auth token” for short), which is a specially encoded piece of text that the platform will use to identify you from here on in, so you’re not repeatedly re-transmitting your password. It’s cryptographically signed so you know it hasn’t been altered.
If you hit F12, or look at your cookies after logging into a game’s web site, you might find something that looks like the Encoded section above, and if you paste it into a decoder (like jwt.io), you can see what your actual token looks like. ✨HACKING!✨
So, why do you care about any of this? Well, because it’s the basis for most communication between systems on the internet, and we’re here to learn about how shit works. What NFTs do, from a game client’s perspective, is identical to any other web service.
So you have your GNL Auth Token - now it’s time to do something with it.
“The Login”, by J.R.R. Token
Thanks, I workshopped that.
So you boot up the newest, hottest game you’ve been playing the last few months, Call of BattleHalo, and you’ve just bought the latest DLC, Fate’s Cry.
Your console boots up Call of BattleHalo (hereafter COBH), and it logs into the COBH servers by sending it your GNL Auth Token. With this, it knows what your GNL account is, can validate that you are in fact logged into GNL, and is able to look up which COBH account is associated with it by checking its database. Most games use MySQL, Postgres, or some cloud-hosted version of same, but COBH uses Postgres.
So COBH accepts your GNL token and issues you its own authentication token, that it will use to identify you for the rest of your session.
So, now you have a COBH Auth Token, and you can start making the requests you need to play the game.
How Does It Know I Bought The Fate’s Cry DLC?
I’m sure you’ve guessed - it’s more HTTP requests.
When you sent your auth token to the COBH servers, it knows that you’ve logged in from GNL, so it sends a request to GNL’s purchase servers to ask it whether you’ve bought anything. There are a few methods of doing this, but we’ll stick with a simple one.
COBH maintains a list of your purchases, requests a fresh list from GNL, and then goes through and delivers anything that hasn’t already been delivered. This could be COBH virtual currency that goes in an inventory, or an entitlement record that says you own the expansion and can access it.
It might go something like this.
To recap:
Your game knows it needs to check the GNL store for purchases
It makes a request to GNL to ask what you bought
It compares that to a list of what it’s given you already
It grants you anything you’ve bought but not received
Using a remote source to understand what someone owns in a game isn’t new - it’s how all console platforms work.
More Data Required
When your game starts to load in, it makes some requests to various COBH services to get the data it needs, including:
Social (e.g. friends list, guild information)
Progression state (e.g. achievements, quests, level, data)
Inventory (e.g. items, cosmetics, consumables)
This is the part you’re interested in.
The game client makes a request with its auth token to a game server API. The game server has its own secret token that it uses to make a request to an inventory server on behalf of the player. When the inventory server gets that request, it looks up the player’s items in a database, and the data weaves its way back up the chain.
Note that the inventory server does not need to send everything it receives from the database back to the game server. In fact, it’s normal not to. Items and currencies get deprecated all the time, and although games might perform migrations on the database to get rid of such things, there’s no reason they can’t instead filter them out in the inventory server.
How might that be different with NFTs?
It wouldn’t. Here’s how the same flow would go.
The same inventory server is the arbiter of what you get to have in-game. While it can’t remove things from your wallet, it can make them useless or worthless. A game company can immediately nullify anything you own. If they remove or block the item your NFT represents, then all you have left in your wallet is a JSON string that refers to nothing.
“But if the client makes that request and then sends it to the game server, a game company can’t interfere with it, right?”
No. This is incorrect for two reasons:
Never, ever, ever, ever, ever trust that what a player’s computer tells you is real. Anyone can do anything to it. You could make your client say you have every item in the game. Inventory cannot be client-authoritative if you want your game to be secure.
The inventory still requires interpretation by the game server. The game server can similarly just ignore or change anything you send it. You probably have dead, invisible items in the inventory of every online game you play.
What about items from other games or services?
It’s not meaningfully different than getting your purchases from GNL. When you earn an item by watching a Twitch stream, Twitch sends a request to that game's inventory server and tells it to grant you that item in-game.
I’ve simplified this a fair bit, but at a high level, this is how it works. It’s all just a bunch of requests flying around between services you’ve chosen to trust.
And trust is the important part here, because there’s functionally no difference between choosing to trust a particular service and choosing to trust NFTs minted by a particular contract address.
I’ve alluded to the Trust Mesh Problem before, but the core of it is simple:
Item Origin Matters
If, as the operator of COBH, I choose to honor items from another game, like the fictional Hail Of Storms (HOS), I should only trust those items if they were created by Hail Of Storms.
Which makes sense right? If I’m telling my game that the item WEAP_ENERGY_SWORD is a HOS weapon, then I should only trust NFTs minted by HOS. If some other game started minting NFT items containing WEAP_ENERGY_SWORD, I know they didn’t originate in HOS. Like right-clicking and saving a popular NFT, then minting your own with it, the contents might be the same but it is the source that gives it its validity.
If I trust HOS items from any other source, anyone could create fake HOS items, and I’ve just allowed anyone to add anything to my inventory that COBH supports.
So given that you’re loading HOS items, and they can only ever come from HOS, all you’ve done is added more steps, when you could just ask HOS directly. If you ever recognize HOS items from a source other than HOS, you’ve allowed anyone who can mint an NFT to hack their own inventory, so the blockchain serves no purpose.
I’ve added a second game in here, Per Requiem Inventorius (PRI) for illustration purposes.
For all that talk of decentralization, that sure looks a lot like centralization, doesn’t it? The fact that the storage is decentralized doesn’t actually change anything in a centralized architecture.
Here’s how it currently works today:
Looks pretty similar, huh?
COBH, HOS, and PRI are all free to dictate how their item exchange works, and design solutions that work for them. They can build exactly what all parties agree upon, without being kneecapped by an unnecessary choke point rife with counterproductive limitations.
In a future article, we’ll talk about what those limitations are, and why every possible version of a system like this is worse for them.
We’ll also talk about marketplaces, game design, and game economy health. Each of those topics raise their own issues, and any one of them is serious enough to kill any assertion that NFTs enable anything in games. But the future articles must wait for future days, and my hope is that if people can understand the inner workings of how they’re talking about, that they might focus on possibilities for the future that aren’t self-defeating.
Thank You For Your Service
So.
This was a fairly long and in-depth look into game services, and if you made it this far, I’m impressed - you care more about infrastructure than the average game-enjoyer.
But at its core, when people talk about NFTs and gaming, they’re talking about infrastructure, so that’s what I’ve attempted to get people thinking about here.
Next up, we’re going to be talking about the Trust Mesh Problem in detail, so stick around for the next article “You Can’t Fix A Bad Plan With More Code”.
for those we have lost; for those we can yet save