Running Doom on blockchain: a landmark moment for Cardano and Hydra

Intro

Doom (1993) is an era defining game. Not just for its contributions towards community participation in gaming, such as distributing a shareware version of the game and an open sourcing of the game engine, but also for bringing gaming (previously a virtually console-exclusive feature) to the mainstream on personal computers.

Appearing in an era of floppy disks and very limited RAM (RAM size in 1993’s computers was 32 MB. For comparison, a single photograph in a modern smartphone averages 2 MB), Doom’s release was an amazing feat, made possible by the innovative approach of the id Software team.

Unlike other contemporary games, Doom remains an enduring cultural phenomenon decades after its launch. (Doom turned 31 in 2024.) To this day, the original game boasts an active community of both players, speedrunners, and modders, that is, users who create their own custom maps and game assets. Doom is in fact credited with kickstarting the modding hobby.

But it’s not just that.

Can it run Doom? has become both a question and a gauntlet of sorts, with clever engineers having managed to run the game on graphical calculators powered by potatoes, cars' navigation systems, and even a bioluminescent grid of cells. This is largely because of Doom’s ability to run on restrictive hardware, enabled by clever game engine designs.

This begs the question, when it comes to the very restricted environment that is a blockchain transaction, which is typically reserved for comparatively simpler smart contracts focused around financial interactions, is it possible to make a set of smart contracts that allows running Doom on Cardano?

Short answer? Yes, with a few notes. For example, the current transaction size limit on the Cardano main network is around 16 KB, while the DOOM.wad (v1.9) file containing the maps, monster sprites, weapons, parameters, etc, is 10,899 KB; and the time between blocks is around 20 seconds, whereas the time between frames of the game is 28 ms. This is where Hydra technology comes in handy!

Hydra heads: an analogy

To explain how Hydra heads are instrumental in making the Doom tech demo a reality on Cardano, let’s first explain with an analogy what a Hydra head is.

A Hydra head is a bit like a plane, while the Cardano mainnet is the ground. You can move the plane to a landing strip, load it up with cargo (UTXOs) and crew (participants), and take off.

While in the air, there's nothing and no one going in or out of the plane*, but you're free to move stuff around as much as you'd like. Then, when ready, you can land the plane and it's only the end state of where the stuff is that matters. You could have moved it around 10 times or 10 million times, it won’t make any difference once back on the ground.

An amazing feature is that you can allow as many planes as you’d like to fly around in parallel, so whatever performance you get from one Hydra head, if you are able to parallelize the problem, you can scale it up to meet whatever demand you want by spinning up more heads.

A very useful feature, which we’re relying on for the Doom tech demo, is that someone from outside the plane can communicate with the crew via walkie-talkie to have them move stuff around, so you don't have to be operating the plane to benefit from it! This is called a delegated head, and is a very useful way of using Hydra heads.

Since you're not beholden to the same restrictions as the main network, you can do a few things inside the plane that you can't do on the ground. You can charge no transaction fees, you get virtually instant finality, and you can move stuff around pretty fast. But not only that, you can also run super-duper complex smart contracts that would be way too big to run on the main chain, since heads have no limitations on transaction or block size.

Everything considered, the size of the DOOM.wad file is no issue, and the complexities of executing a smart contract system as elaborate as a game engine -although not what Hydra is really intended to be used for- is also doable.

There are a few directions of development that are removing these restrictions, but the basic Hydra head works this way.

So with Cardano’s Turing-complete smart contracting language and the flexible execution environment that is a Hydra node, today we’re striving to answer the question: can it run Doom?

What does ‘run Doom’ really mean?

There are various approaches to the challenge of running Doom on unconventional platforms. Some completely reimplement the source code from scratch, using the original game engine more or less just as a reference. Others simply reimplement the controls and screen used to interface with the game, while actually running the game on a regular computer elsewhere.

Although it is theoretically possible to perform a complete source port of Doom into a set of smart contracts and execute them inside the Hydra head by taking user inputs as transaction inputs, verifying the full game logic using smart contracts, and generating each frame individually as an output NFT, the tech demo at Rare Evo is more like an MVP of this approach. Elaborating on what exactly has been implemented presents a fun way to learn a bit more about Hydra and how smart contracts and transactions work on Cardano. We don’t have to get too technical, but let’s have a look under the hood to understand what running Doom on Hydra really means!

How Cardano transactions work

You may have heard that Cardano transactions are deterministic, which means that when you’re making a transaction on Cardano, you both can and need to calculate the whole transaction. Not only the inputs and smart contract logic, but also the resulting outputs.

This is actually quite convenient for the Doom engine, since it is also completely deterministic! In fact, this is one of the core features that helped define speedrunning as an activity, as it allows the game to produce ‘demo files’ after a player has finished a map. The demo file just contains the sequence of user inputs and can be shared between players. Since the game engine is completely deterministic, replaying a demo file from inputs will always result in the same game! Even the randomness in the game is defined in such a way that there’s no variability between replays of a demo file. Even on different devices and different times.

So how is Hydra actually running Doom?

All of this leads to the following: to play the game on Hydra, smart contracts validate this deterministic evolution. For each frame (editor’s note: each batch of frames, if we end up batching*), the users' browser runs the normal Doom game code to determine a new state: a new player position, health, ammo stock, etc. Then, this new state is built into a transaction and submitted to a Hydra node in real time. The Hydra node has equivalent logic encoded in smart contracts written in Aiken, to validate that these state updates adhere to the game engine’s logic! This prevents a user from cheating by forging their final stats: they must produce a sequence of inputs that lead to that final state. Since both systems are deterministic, the game progression is unaffected and arrives at the same result. For the purposes of this tech demo, a subset of the full game logic was implemented that allowed demonstration of the principles at play.

Is this a realistic and feasible way to run Doom itself? Of course not! Doom, while a landmark in video game history, isn't made better by this kind of deployment. What it is, however, is a fun project by a small, passionate team to demonstrate the power and versatility of Hydra, and potentially inspire other builders for how Hydra could become a component in their architectures.

*Transaction batching is only needed in some cases due to network speed, depending on the physical distance between the server hosting the Hydra head and the client playing it, and not due to anything to do with the Hydra node. With a node hosted locally (either on your device or on a LAN) the game runs without problems at the fixed 35 frames per second.

This version of Doom sounds different, what’s up with that?

As it turns out, even though the game engine is open source, the same does not apply to all the components that make up the Doom release! In a nutshell the game engine was open sourced in 1997, while the .wad file containing all the game files like monster sprites, maps etc, was initially distributed under a shareware license to encourage people to purchase the full game, which they could do by mailing an envelope of cash to a distributor and getting the remaining floppy disks in return.

Unfortunately, the music and networking components had different licenses. So… to ensure the game had music, we created new tracks that play in the browser alongside the game. The networking component was replaced by our Hydra backend anyway, so that wasn’t a problem!

Benefits of doing this

Running Doom on a blockchain is definitely overkill, but there are a few actual benefits of doing this. Particularly, the whole project will be fully open source, which means that components developed for the Doom tech demo can be reused in other projects, and the design patterns and approaches to problem solving will be available to all as a useful reference for other builders.

Using Hydra heads in this unconventional way will hopefully also inspire new builders to look at Hydra from a new angle and lead to novel applications for the technology and wider adoption.

The team behind the Hydra: Doom project

The Doom tech demo is ultimately a passion project developed by a small team in a few short weeks, and intended as a fun demonstration to showcase Hydra, one of Cardano’s scaling solutions, in action and hopefully inspire more builders to pick it up and use it as a part of their projects.

Pi Lanningham

Although Pi needs no introduction within the Cardano ecosystem, it is worth highlighting his contributions to the ecosystem through Cardano’s first AMM style DEX, SundaeSwap, and contributions to innumerable other projects and work streams including several direct contributions towards the Hydra protocol itself, including Sundae Labs' own evolution Gummiworm.

Pi has been instrumental in setting up and orchestrating the backend components including a Hydra head management platform, multiple tools for measuring performance, assigning users, routing and reading data and much, much more.

Sebastian Nagel

Sebastian is among the core developers of the Hydra head protocol at IO. He successfully demonstrated the first integration of Doom with Hydra by creating a Doom game demo, where game updates were written directly to a Hydra head as transactions.

Josh Marchand

Josh Marchand, known for his work at jpg.store and on SecurityBot, is helping out with the smart contract work required for validating user input and reading/writing the game state to and from the Hydra head.

Adam Dean

Adam Dean put in a heroic effort adapting the proof of onboarding system he pioneered to allow for the user authentication requirements we have for the project, plus various other bits and bobs, without which the Rare Evo participation would be greatly lacking!

Trym Bruset

A product manager at IO with green sunglasses, who had a crazy idea and managed to make it happen.

Next steps

There are some tasks we would have loved to complete in time, but unfortunately we had to postpone, or leave for someone in the community to pick up and possibly apply for Catalyst funds to complete… nudge nudge, hint hint.

Hydra LAN parties

Anyone with a bit of technical prowess could spin up a Hydra head and host a LAN party, just like in the good old days!

This could be a fun activity for local Cardano communities all over the world, and an opportunity to get together to slay some demons while devouring snacks and soda.

Full game engine source port

Performing a full source port of the Doom game engine is not only a true gauntlet for developers wanting to show their mettle, but it’s also an impressive showcase of the expression and ease of use of smart contracting languages such as Aiken, Plutarch, Helios, Plu-ts etc.

For anyone up to the task, or anyone interested in the colorful story about the development of Doom, I highly recommend the Game Engine Black Book: DOOM.

Hydra as a competitive gaming backend

For gaming applications (including Doom and others) Hydra could serve as a valuable backend service for competitive tournaments and world leaderboards, such as speedrunning. It can provide high assurance for submissions through game transition verification, as demonstrated in the Doom demo, helping to prevent cheating like ‘splicing’ and forged runs.

Additionally, Hydra can leverage blockchain technology to manage prizes, donations, betting, and global leaderboards.

CIP68 integration

CIP68 is a token standard on Cardano where the token in a user’s wallet references (‘looks at’) a different token called the reference NFT for certain metadata. This other token can be held in a different wallet or smart contract address, and can be updated by that mechanism without any required input on the user’s part. This can be used to ‘evolve’ a user token (NFTs or otherwise) without them having to do anything. Moreover, multiple tokens can reference the same reference NFT.

The idea for the Doom tech demo was that users could be empowered to either mint a token or to get a token through the proof of onboarding system by scanning a QR code. This would remain in a standby state until the end of the event, since the reference NFT would be inside the Hydra head.

Inside the head, the state of the reference NFT could evolve as a part of the other activity in the head. For example, in the Doom tech demo, the CIP68 token the user receives on the main chain could be a music album NFT, and then the actual tracks could be based on the music they’re able to trigger in-game by progressing through the levels!

Custom Cardano Doom map

We started working on a custom Doom map, but ultimately had to focus on the Hydra and smart contract portion of the project to complete it in time. However, it’s quite simple to load custom maps into the Doom engine and play them. There are some great tools to make edits, even for non-developers. It would be a lot of fun to see a community-driven custom map filled to the brim with Easter eggs and custom-made monsters!