“Is that… Red Alert?” you ask, suddenly twelve years old again, the smell of a hot Pentium II filling the room.
It’s OpenRA, the open-source engine that reimagines the old Westwood classics, running Red Alert and its freeware content in a browser tab. Getting there took a detour through WebAssembly, WebGL, a font rasterizer, and a homemade Lua shim so the mission scripts would run. By August 9 it ran, it drew, and you could play it.
That alone would have been a respectable hobby project. Then it became the last of this batch of demo tests, because it pokes at two things the others don’t: real-time peer-to-peer coordination, and big downloads.
Finding The Other Player
Multiplayer games have to find each other somehow. Normally a company runs a lobby server, everyone connects to it, and the game lives exactly as long as that company stays interested. Regular readers will know I’ve been bitter about dead license servers since roughly 2009.
So here the lobby is a smart contract on Paseo Asset Hub: an open-games list and a sealed mailbox for the handshake two browsers need to connect directly. Once they’ve swapped notes, the browsers talk to each other over a WebRTC data channel, and the actual game traffic never touches the chain. The contract can also escrow a pot for a match and pay out the winner, and one host can run a four-player game.
“So the blockchain is… a bulletin board?” you ask, stapling a lost-cat flyer to a telephone pole.
Pretty much. A bulletin board nobody owns, nobody can take down, and nobody can quietly edit to send you to the wrong opponent. That’s the whole trick: the chain makes the introductions, then gets out of the way.
The 84 Megabyte Question
A browser game engine is not small. The .NET runtime compiled to WebAssembly, plus the game content, comes to about 84 MB. For a web page, that’s hefty. For an app that lives on a chain, it’s a question I couldn’t find anyone who’d answered: can you even do that?
So I tried. On August 12 the entire bundle went onto the Bulletin chain in one go: 85.3 MB across 75 chunks, finalized, with nothing worse than a polite warning that anything over 50 MiB is a bit much. Uploading: viable.
Downloading: less so. The gateway that serves .dot sites to ordinary browsers choked on the single biggest file, a 45.9 MB WebAssembly module. The game resolved, fetched its first few files, and then sat there quietly failing to fetch the rest. A web page that won’t boot is technically decentralized. It is also technically a brick.
“So it doesn’t work,” you say, already digging the original CD-ROM out of a shoebox.
It works after a split, which landed the same day. The app is cut in two. A 1.26 MB shell (the page, the boot manifest, everything that describes the build) lives on chain under openraonchain.dot. The heavy bytes, runtime and game content, come from an ordinary web origin. The shell names and hashes every file it asks for, so the heavy half can’t be quietly swapped out from under it. And since Bulletin forgets things after about two weeks unless you renew them, every renewal now re-uploads a megabyte and change instead of 82.
Is that purely decentralized? No, and I’d rather be honest about where the line sits than pretend there isn’t one. The part that decides what runs is on chain and verifiable; the part that’s merely big is served from wherever is cheapest and checked on arrival. That’s the finding: large downloads are viable, as long as you treat the chain as the source of truth rather than the delivery truck.
Play It
Head to openraonchain.dev-dot.li, or open openraonchain.dot in the Polkadot app. Give it a moment to pull down its 84 MB. Build a power plant first. Always build a power plant first.
— Kasey