JavaScript on this site is used to render LaTeX math, but is non-essential. blamster19 - all stuff blamster
blamster19 - all stuff blamster

Making a quantum computer game, part 1

Published: 2026-09-16T11:16:03Z
Last modified: 2026-09-16T19:49:15Z

Contents

  1. Introduction
  2. Game design and architecture
  3. Quantum simulator implementation
  4. The rest of the game

Introduction

When I learned about quantum computing I was simply amazed. I attended a lab where I programmed the well-known and lesser-known things like Bell's state, Grover's search, spin chain, Ramsey experiment and so on. I even ran some of them on a real machine! Seeing how the concepts from quantum mechanics come to life with a click of a button was such an awesome feeling that I knew I wanted to do more of it.

My mind started wandering, thinking of ways to make quantum computing entertaining for non-experts. One idea is to program a game for a quantum computer. Currently those machines have about 100 qubits, which is less memory than the first video games needed. The obvious drawback is that the current-gen machines are very limited and very noisy, and that's ignoring the fact that they are unavailable for ordinary people just yet and that the subscription-based services cost a small fortune. We are stuck with simulation, then.

Simulation of a quantum computer has some serious limitations. Consumer hardware is limited to about 25 or 30 qubits, top-notch supercomputers can handle about 50. This is because the memory requirements scale exponentially with the number of qubits (after all, that's why we want to do QC in the first place). A 50-qubit computer needs $2^50$ tuples of 32-bit floats to represent its state, which is about 72 PB of memory. We can settle for less qubits to sit comfortably in the range of a few gigabytes at most.

Game design and architecture

Quantum simulation is math-heavy and quite slow, so real-time games are excluded, bare for a couple qubits. This gave me a general idea that the game I will be making will have to be turn-based. I thought about it a bit more and I came up with a nice idea for a game loop: a tower-defense-like game. The entities coming along the path will form the state vectors, one for one enemy wave. The path tiles will be places where the player can place the quantum gates (my game will simulate a gate-based computer, annealers are not my domain). This gives a nice correspondence between the game world and the underlying simulator - this won't be another 'woo-woo-quantum-themed' game but a real thing, essentially a gamification of quantum circuit design.

Representation was a big challenge. The quirky thing about quantum mechanics is that you need the information about the whole state to describe it. This means that the entities roaming through the map of my game are not independent, but form cohorts of certain configurations. To illustrate the problem let's compare the classical and quantum representation of a 3-bit binary string. The entities will be represented by square brackets [ ] that use two sprites, [0] and [1]. Say we have a classical string 101, it's really trivial to show it in-game using sprites:

[1][0][1]

Now the quantum case. We'll start with a state $|101\rangle$ which is a so-called pure basis state:

[1][0][1]

If we only used states like this one, we would have a fancy and very expensive classical computer on par with its 1950s counterparts in terms of capacity. Let's go quantum and produce a superposition of two states $|101\rangle+|110\rangle$. Oh no, the first qubit to the left is simply 1, but the second and the third qubit are both 1 and 0. Easy, just introduce a third sprite [0/1] that signifies a superimposed qubit:

[1][0/1][0/1]

Hold on, this notation is ambiguous! It could mean a few different things: $|100\rangle+|111\rangle$ or $|101\rangle+|110\rangle$ or $|100\rangle+|111\rangle+|110\rangle$ or $|100\rangle+|111\rangle+|101\rangle$ or $|100\rangle+|111\rangle+|101\rangle+|110\rangle$. All of these states have the second and third qubit in either state 0 or 1. There's no way of telling which state is really it from the representation we chose. The only way to accurately represent the state is to show all the basis states at once, separately:

[1][0][1]
[1][1][0]

Reader familiar with quantum mechanics will notice that this picture is incomplete: there are no state amplitudes and the state lacks normalization. Moreover, the amplitudes are complex numbers. The state representation should be:

c_1[1][0][1]
c_2[1][1][0]

where $c_i\in\mathbb{C}$ are amplitudes that satisfy normalization $\sum_ic_ic_i^\ast=1$ (the $^\ast$ is complex conjugate). I had to somehow show all of that in a simple graphical manner.

At first I wanted to write the whole game myself from scratch, but I quickly realized that I would spend a lot of time doing things that were done a million times, like screen resolution and input handling, and the result would be sub-par anyway. Instead I opted for Godot engine. Now I could dedicate more resources to actual game design and writing the simulator.

Quantum simulator implementation

There's a lot of quantum simulators out there, but all of them are feature-rich scientific software. I needed a subset of their functionality, only the state simulation and a few hard-coded gates. On top of that, to my knowledge, there are no quantum simulator plugins for Godot. I decided to write one in Rust.

A simulator for my needs is quite trivial to implement, it's really just construction of operator matrices and matrix multiplication. I found an excellent paper that does just that in JavaScript: arXiv:2506.08142 [quant-ph]. I managed to port it to Rust and implement only the essential parts.

The simulator is structured more or less as follows:

This was my first time programming Rust for Godot (and the whole project is my first time programming in Godot for that matter). Godot, and I suppose other game engines, has no complex numbers, so I implement the complex vectors using arrays of Vector2 and manually converting them in Rust code. I do the reverse with the results. My quantum simulator is structured in such a way that the whole thing is composed of single steps that can be applied independently. Normally the circuit would consume the initial state and spit out the final state, but not here, since I need to know the quantum state at every step of computation for presentation purposes. The whole thing is about 300 LOC and its performance is acceptable for workloads that I expect.

The rest of the game

I wrote the simulator one year ago and since then I had to pause the project to finish my studies. I came back during vacation and now I have to do the things outside my expertise - game development. I have an idea for a whole silly story arc that follows a few tens of levels where players will have to build quantum circuits to reach the end.

I'm doing all the sprite work by hand and maybe I'll create SFX and music (although it's my weakest skill if you could call it like that). I plan to release the code under GPL v3 and all assets under some Creative Commons license, because I believe in free software and free culture. Many FOSS games, while very good, are clones or source ports of successful commercial games. There's nothing wrong in creating a thing similar to the hot thing (look at Mario vs Sonic the Hedgehog for two successful and very similar franchises), but nevertheless it's the cause of free games' reputation as poor rip-offs of 'real games' in some circles. Don't get me wrong, I love OpenTTD and Hedgewars! Sure, there's a lot of open games produced during Ludum Dare, but unfortunately, there aren't that many original games that entered the mainstream. There's not many games about quantum computers, apart from very simple toy models, and, to my knowledge, there is no game similar to my idea, so I decided to make this game to scratch that itch of mine. This is my first public announcement about the game, but I have a lot of it already done. In the next posts I will show more content and present the game mechanics.

Walk animation loop of the state entity