In my previous post, Is There Actually a Game That Requires Blockchain?, I ended up changing the question.
Not:
Blockchain Required?
But:
Blockchain Preferred?
I still hadn't found a game that I could confidently say was technically impossible without blockchain.
Axie Infinity, Gods Unchained, The Sandbox — the core game systems could all, at least in principle, be implemented with a normal server and database.
Play-to-Earn didn't solve the problem either.
So it would be easy to stop there and say:
Maybe games simply don't need blockchain.
But something about that conclusion bothered me.
Being able to reproduce the same functionality with a database is not necessarily the same as saying that nothing changes when you replace blockchain with one.
So I started thinking about that difference instead.
What happens with a normal database?
Imagine a game with a single character.
That character has information such as:
Who owns it?
When was it created?
What has happened to it?
Who owned it before?
What achievements does it have?
In a normal game, all of this can simply be stored in the operator's database.
And in most cases, that is probably the better design.
It's faster.
It's cheaper.
It's easier to build.
It's easier to fix when something goes wrong.
For most games, a centralized database makes perfect sense.
But there is one important assumption:
The game operator controls the authoritative record.
The operator ultimately controls the record of who owns the character.
The operator controls its history.
The operator decides whether outside developers can access that data.
And if the service disappears, the operator also determines what happens to that database.
There is nothing inherently wrong with this.
For most games, it's completely fine.
But what if that authority itself matters to the game?
What actually changes with blockchain?
Now imagine that some of the same information is recorded on a public blockchain.
The gameplay might not change at all.
The character could still behave exactly the same way.
But depending on how the system is designed, something important could change:
The game operator would no longer have to be the only party capable of verifying the authoritative record.
Other people could independently verify records such as ownership and transfers.
A developer who has nothing to do with the original game could potentially read that public data and build another tool or game around it.
And if the original operator disappeared, the records that had actually been placed on-chain would not necessarily disappear with the operator's database.
That doesn't mean the operator automatically loses all control.
A blockchain game can still use admin keys, upgradeable contracts, centralized servers, private APIs, or other components controlled by the developer.
So simply putting something on a blockchain doesn't solve the problem by itself.
But it does make a different trust model possible.
So yes:
A database can reproduce the functionality.
But:
It does not necessarily reproduce the same trust model.
That started to feel like a more interesting distinction.
An NFT surviving doesn't mean the game survives
There is another problem here.
Suppose a game character is represented by an NFT.
If the game shuts down but the NFT remains on-chain, it's tempting to say:
“The asset survived.”
But what exactly survived?
If the game server is gone,
if the system that calculates its stats is gone,
if its images or 3D models were stored on a dead server,
if the client no longer works,
or if the actual game rules were never made available,
then the token may survive while the game does not.
An asset surviving is not the same thing as a game surviving.
Using blockchain does not automatically make a game independent from its operator.
You still have to ask:
Which parts are actually independent?
Which parts still depend on the original company's servers?
Which parts can be verified without trusting that company?
And what would someone else actually need in order to continue the game?
Maybe “Required” was the wrong standard
Originally, I was looking for something that was:
Blockchain Required.
A game that simply could not exist without blockchain.
I still haven't found that.
If we allow one trusted operator to control a server and database, an enormous amount can be reproduced centrally.
So perhaps that standard isn't very useful.
A more interesting target might be:
Blockchain Preferred.
A game that can be built with a normal database, but where replacing blockchain with that database changes something important about what the game means.
Maybe history matters.
Maybe it matters that the operator is not the only party capable of controlling or verifying that history.
Maybe it matters that third parties can build on public data without asking the original operator for permission.
Maybe it matters that someone else could continue something after the original operator disappears.
Maybe the identity of something in the game is supposed to outlive a single account, server, or company.
That still doesn't mean:
“This absolutely must use blockchain.”
I'm not there.
Right now, the conclusion is much weaker:
There may be kinds of games where blockchain fits the design better than a normal database.
And that led to the next question.
What kind of thing would make history, inheritance, and persistent identity part of the game itself?
A weapon didn't quite feel right.
A card didn't quite feel right either.
Something whose past affects its present.
Something where things can persist across generations.
That's where the idea finally started becoming more like a game.
Top comments (0)