Making games for Ethereum, Part 1: Requirements and Limitations

I'll preface this by saying I haven't spend nearly as much time on Ethereum based games as I have on other kinds. But my involvement with Ethereum from the beginning (and I have been involved since before Frontier) has been centered on the concept of Ethereum-based games.

While I might not have too much to publicly show, I've been thinking on the subject for ages--which is what many crypto-idea have to offer, to be honest. And I do have a tech demo of a DMMOG (Decentralized Massively Multiplayer Online Game) called the Impermanence of Space.

A screenshot from the develop branch of the Impermanence of Space. This is the less functional rewrite from the original hackathon version, but I have been unable to get said original version to work, even to take a screenshot. And while it may not look like much, the game is of epic scope, with unlimited randomly generated galaxies, ship customization, FTL travel through a player-built wormhole network...

So what's this about? You might've seen the immense game-making potential on the Ethereum platform. Or maybe you're wondering what all it takes--games are, after all, often incredibly complex programs, if not to mention more interesting than many programs of similar complexity.

But before you jump into making the next League of Warwatch Fortress on Ethereum, there's a bunch of unique challenges. This article is about those before you even start.

Most importantly...

The game must have a reason for being on Ethereum

Tech demos are fun. I've made one myself, obviously. But, after you're done, is it actually something you want to use on the live blockchain?

If you want to write a game in Javascript, fine! Or Java, or C++, or C#, or Objective-C, or COBOL, or whatever else you fancy! It won't matter to the players if the game is running in 6502 assembly, as indeed many famous games are.

The power of nonmaskable interrupts on vertical blank compels you! (Because they're nonmaskable. Duh.)

But if you write a game that runs on Ethereum, the players will have to pay to run it.

Let me put that again. The players will have to pay to run your game.

If there is no reason to use Ethereum in the first place, better to stay off it. An app does not magically become better by becoming a dapp. You could distribute it over swarm if you don't want to host it. You could theoretically use whisper to communicate between players if you don't want to use ordinary TCP. Or you can just avoid web3 entirely, as nearly every game in existence does.

But there are many good reasons to use Ethereum. Here's a few:

You need smart contracts.

Allowing players to hook in Turing-Complete code in a safe way is extremely powerful. You can allow all sorts of crazy stuff, when you know that they're not going to jailbreak and own the host's computer.

Yet, if all you want is code, you could also run JS or your own limited language in a sandbox, as how many programming games work.

Then again, smart contracts can access the rest of Ethereum. Even if you don't necessarily have game-altering code, you can use smart contracts externally. Imagine a player creating a unit controlled by a smart contract, which acts as a mercenary. You wouldn't have to do a thing!

You never want the servers to go down, or be taken down.

One of my strongest personal reasons. I have found one of the saddest things is if a server for an online game shuts down, forever. However it played, whoever enjoyed it most, whatever it was or was not... gone.

Indeed, every patch of a commercial online is like one game coming into existence and another leaving. The new one might be better--but there is no return to the old. And it is one group, the developers--one group, not the players--that decides what is done.

But with Ethereum, the smart contracts that run the game are going to continue to function, no matter whether the original owners like it, dislike it, or are hit by a bus. It's hosted by the blockchain! As long as there are players, they can still play.

Yet, even without Ethereum, you could also distribute the server executables and let whatever remnant of your playerbase keep it alive indefinitely.

Then again, with Ethereum no one has to run the server. No one has to find a hosting provider, no one has to wake up in the middle of the night to troubleshoot, and no one has to beg for donations to keep it up. Players will pay, yes, but each will pay only for their own activity.

You want no cheating.

Strange as it may sound, being able to cheat is an advantage in some games. For example, in single player games, the existence of cheats allows a player to see parts of the game beyond their ability. Or, for a game like Minecraft, to turn it into even more of a sandbox. But in multiplayer games, it's essentially all negative.

In Ethereum, short a bug or real-life hacking, everyone must follow the rules. No exceptions.

This is of particular value for a DMMOG, as there is no risk of an admin magically giving themselves a fortune, or banning players they dislike, or whatever other form of abuse.

But this does imply there is nothing any "admin" can do if things go wrong. I've noticed that nearly any online game, after a certain length and size, eventually has a villain--the one player most loved and hated. If the developers intervene, the players are deprived of dealing with this crisis. But if no one can intervene--the players fail to defeat the villain, and permanently lose--then Sauron wins. BG, no re.

You want to involve real money.

Here, perhaps the most serious reason to use Ethereum, if also the most prone to moral questions. I'm not going to get into gambling here. Suffice it to say that I am dubious on a number of levels, and I've seen the damage gambling does to lives.

But gambling aside, it's reasonable to sell in-game objects, and using Ethereum will perhaps be much easier. You can attach the sale code to the actual game!

Alternately, players can, very easily and safely, sell virtual goods to each other for real or virtual money. Depending on how you feel about real money transactions, this may or may not be a feature--but it's an inevitable one if you allow goods to be transferred at all. (I personally see real money transactions as an advantage. A player with more money than time and a player with more time than money can play together. Though I admit I am not quite fully comfortable with them, for there is great potential for abuse.)

Corollary: The game must be multiplayer, or single player with social elements.

Ask yourself: Even if, for some reason, you need to use the EVM, why do you need to use the public chain? Private chains are free, and you can then use excessive amounts of gas.

Are the players scattered about and too difficult to coordinate? Or do you have a DMMOG with a potentially unlimited number of players? Are you actually having match-making on the chain? Then the public chain is a great option. Otherwise, ask yourself it it's necessary.

Similarly, single player. Why does the whole world need to know what moves are being made, unless there is some external consequence? You can run Cookie Clicker just fine without having to have the blockchain notarize every cookie clicked. Even if, for some bizarre reason, you had it already written in Solidity--you could just run in it a private testnet.

Breaking: Cookie manufacturer loses fortune making Ethereum-based idle game.

But if, say, you were hosting a idle game tournament, and you wanted to see who would get the most virtual cookies, while ensuring no cheating was possible--then Ethereum might be the right choice for you. Also, a reevaluation of the life choices that led you to host an idle game tournament.

The game must function without upgrades. (Or accept some level of centralization.)

Y'all who didn't grow up on cartridges and CD-ROMs may not think of a game as a static entity, but a static entity is precisely what a smart contract is. While you can upgrade the frontend all you want, the game's logic is set in stone. Now what?

If the game requires balance tweaks--or, say, constant updates--there'll be no way of doing that. How can an automated system know what is a patch and what is a hack? It can't. Especially if players disagree with whether a patch is good or bad.

Of course, you can allow some wise and benevolent ruler (a.k.a. yourself) to change the system through the various workarounds Ethereum allows. But this is literally centralization. Even if you create a council of players and other developers... it's still literally centralization, just with a bigger center.

It isn't necessarily bad if a game's code is immutable. Consider the patch drama you've seen in the forums of any online game. Consider what it would mean if it was impossible to patch the game at all. Would those dissatisfied with the permanent state of affairs leave, or create their own? Probably. But those who enjoyed the old would still have it.

But, then again, consider what never being able to patch the game is. At best, you can fork it by creating a game with identical state, but with new rules. Is that level of rigmarole worth it? Or, would you rather create a timeless classic, but with no option of ever changing it?

Even for a bug?

The game must not require synchronous randomness.

If only.

One might think, after reading some documentation, that you can use the blockhash of every block as entropy for your contract's RNG. This is true.

What is also true is that a player can contrive their transaction to be completely reverted if something goes wrong. If you have them roll a die for every time they swing their sword, they can just unhappen the roll if they miss.

The only realistic way to stop this is to have the player make their move in one transaction, and have the move be resolved in another. This must happen every time you allow a random roll. Consider the inconvenience, if not merely the logistics. Think of all the things that might go wrong in the process, such as that second transaction never occurring, or occurring too late, or--

You know, maybe you might be better off without randomness entirely.

And speaking of things you might be better off without...

The game must have little or no hidden information.

Everything on the Ethereum blockchain is public. You can't hide a hand of cards, or the composition of an army, or secret orders--someone can just read them from the chain.

There are methods of getting around this--many of which are cumbersome. For example, you can have the holder of the hidden information hash it and provide the hash later when needed.

But this approach has flaws. Suppose you have a game with armies battling, so a player hashes their order-of-battle. Then, having seen the opponent's army, they just refuse to show their own. What now? Do you just annihilate their army as a punishment--oh, wait, they actually just were offline for a few days, sorry.

And in this scenario, we assume we know the potential compositions beforehand. If they are building their armies in secret as well, you'd have to have another contrived system for them to work in verifiable secret. And, once the battle has occurred, any third party can see what happened, unless you have the battle done in secret too. Except if any third party might need to know what happened in the battle, then you have to contrive yet another system to deal with that.

Or... maybe you could just live without hidden information in the first place?

If you are a sufficiently advanced wizard, you could awake the incomprehensible arts of the ancient and most mysterious beings of a lunar civilization from some forgotten era to do your bidding. A.k.a. use cryptographic moonmath. Which, if you understand, are far beyond me anyway.

The game must not be computationally heavy.

A late game battle between my teammate (right) and one of our foes. Each of those little guys is individually tracked! And this isn't even all the units!

Dominions 4 is a great game, with massive battles between armies of hundreds-strong, world-changing spells, and giant demonic macaws.

It's also, for all practical purposes, impossible on Ethereum.

If not for the hundreds of random rolls for every battle, the hidden armies, and general complexity, there is just so much. Every move of every unit would require multiple (expensive!) writes to storage, and more to move about, to say nothing of the actual hand-to-hand combat. (2d6 (exploding) vs 2d6 (exploding), plus bonuses, between one to three times, for every single attack.) A single battle would cost an immense amount of gas and delay the game for perhaps days.

While it's true that you can run nearly any program on Ethereum, including the Quake rendering engine, this does not mean you should.

Pathfinding? Number crunching? Detailed battles? Don't get excited. If it can't fit into a single transaction gas-wise, you'll already been in trouble. Even the Pythagorean theorem is probably beyond your budget, considering the square root involved.

Keep off them diagonals, dagnabbit! Kids these days! (From Wikimedia Commons)

Mind you, there's nothing impossible with a game that has hundreds of units. You just have to offload the work--have individual players move and pathfind for their own units. Or have the players do the math off-chain and then send it to the contract to verify. But be aware you're already introducing complexity atop the initial complexity.

(Aside: if you want to make a Dominions-style PBeM game for Ethereum, consider just having the blockchain keep track of turn files, rather than actually running the turns on-chain. It'll be a lot simpler.)

The game must not rely on player's acting.

Ethereum cannot force anyone to send a transaction, as is generally the point of a public cryptocurrency. But this implies you cannot force the players to send a transaction, either.

Consider that, socially speaking, you can't just stonewall a game of M:tG. Sure, you can take your time to think about what to block, but either your opponent, or the judge, or the store owner will eventually make sure you do something. But I've never actually seen someone simply refuse to take their turn--in any board game, really.

But what about if it's on the blockchain?

Now, sure, you can have the players act through a proxy smart contract that allows others to move for them if they don't--or just kick them outright. But you can't force the player to make a move from information they have hidden--you can't reveal the data when you just have the hash, and you can't make the decision they would have made without knowing it in the first place.

Implication: Absent Generals

Suppose you have a game with giant battles, where the players give orders at the actual battle. (After all, you don't want to deal with hidden information, right?) Then one player attacks--but the defending player just isn't there to react. Does the attacking player use this advantage to own the other player's army--or do you require that both players be online at the same time. (And how do you enforce this, especially if the players are in different timezones?) Do you effectively require that players leave a bot running 24/7 to send their orders, and hope that a live human being won't have the advantage anyway?

But wait! Don't we have smart contracts for this purpose? Put the orders in the form of a smart contract, and then there's no need to leave your computer on.

...Well, there's still issues. If making an order requires heavy computation (optimizing formations, pathfinding, etc,) it's unlikely to be economical for a smart contract. The other, larger issue is anyone can read the smart contract to see what moves you would make in your absence. Your hand has already been shown.

Implication: Dereliction of Evaluation

Yet another implication of this principle is that you will have unequal difficulty in making "triggered abilities." Suppose you have wizards in this hypothetical battle that cast spells. One casts a spell that summons incomprehensible horrors from beyond time and space every time a guy with a funny hat dies.

You, the programmer, might be aware that writing a check for this every action would get complicated, as well as gas-expensive. Why not have the players point it out every Hatbearer death? After all, the one whose wizard cast it will be most advantaged, right?

Well, if he doesn't (because, say, he isn't there) then it never gets pointed out, and it never happens.

This is particularly undesirable if a third party would be disadvantaged by the spell as well. If the main cost Player B pays is that the land is corrupted by evil black hat magic for every horror summoned, then Player C, who plans to invade next, won't point it out, either.

Further...

Implication: No one lets in the barbarians at the gates.

Want to have a neutral party in the game? Better hope that it always advantages one player over another, or no player is going to spend the money for the transaction to send the cyclopean horror out to destroy the world.

All it wants is love. And hats, apparently.

But also consider that a situation may exist where the cyclopean horror has to choose only one target. (It's got just one eye, dude!) If it would hurt mostly Player A, or mostly Player B, then either will point it at the other--a.k.a., whoever sends the transaction in first wins. This is likely undesirable.

On the blockchain, no one knows that you are between 0 and any positive real number of people.

All your smart contract knows is that a given address A did X. It does not know who controls A, or if it's the same dude as B, C, H, 0_0, or Lord Snufflewuffets the Dark. Or if it's multiple people. There's no one to say whether a given address is human-controlled at all.

Whether or not your players are really human may not matter, save that you are attempting to create some kind of sadistic death trap where at game over they DIE IN REAL LIFE (please don't). But whether two, or two thousand, players are really just one dude and his legion of servile robots probably does. If your DMMOG assumes that one player will have only one account, so it's perfectly OK to hand out 1,000 credits for free, then some enterprising human is going to create a gazillion accounts. He might even do it if he doesn't play--no reason to let free credits to go to waste if you can sell them. Hyperinflation!

(Of course, it wouldn't technically be hyperinflation, since the increase in the money supply would be linear. It would still wreck your virtual economy, or, rather create a bizarre kind of peg.)

Consider also--this has kept me pulling my hair--what value does another human player have if there are machines? If your design relies on players to hire other players, why wouldn't a player just have their bot do the same? If you have parties of adventurers entering the dungeon, why wouldn't the leader just multi and have all bots with him?

Or not play at all, and have his bots farm while he sleeps?

But this is not necessarily permanent! There's more than dapp seeking to create a proof of individuality system. If so, you can probably piggyback on it. And maybe, just maybe, with future advancements in VR and IoT technologies, you really can make Sword Art Onchain.

Conclusion.

If this article went into every challenge you might face, it could go on for another three thousand words and still not be done. These are the largest, but a specific dapp might run into some critical but even more obscure issue. For example, I didn't even go into timing issues for real-time games.

But, every one of these limitations is surmountable, and I've mentioned a few ways along the way. While you may have to pick your battles, the ones you pick will be winnable, if difficult. Ethereum is Turing-Complete; there are an infinite number of possibilities. If at last it turns out what you dream is impossible, find another way.

On a positive, personal note, I had actually abandoned the Impermanence of Space, but writing this article has reinvigorated me. You might start seeing lessons I am learning while working in the future.

Next time, though, I'll talk about how to even begin. That will also serve as a guide for starting Ethereum development in general.