Pier-Luc Brault came up with a funny game that turns you into an… operating system. Some user loads us with processes that need to be distributed over free CPUs. If we do a bad job, the user will get mad and reboot us. Game over.

Pier-Luc Brault first shared the idea for the game with his computer scientist friend Sam in a letter:

“Imagine a game in which you are the operating system. You need to manage CPU cores, processes, paging, and the paging partition. You should make sure that no process is left without the necessary resources and handle paging when necessary. The goal of the game is not to bring the user to white heat due to the fact that everything slows down. What do you think?”

To which the friend replied:

“I will say that you are a rare prick!”

That’s how Pier-Luc Brault started the development of the zadrot game. First we had to choose the technology. The project was too modest to study a full-fledged game engine, so it was decided to use a simple 2D library. In addition, Pierre-Luc wanted to return to Python programming. So, the choice was obvious — Pygame. In addition, Pygame had the added benefit of being able to compile the game in WebAssembly (using pygbag), allowing for browser play.

It took about a week of pure time to create the game, spread over eight months.

Game mechanics

At the heart of the game are processes and CPU. You can click on an inactive process to assign available CPU to it, or click on an active process to remove it from the CPU. Subsequently, inactive processes pass through six levels of “hunger” (lack of resources), which are in the form of emoticons on a different colored background. If the process is stuck at the last “starvation” level, the user loses patience and terminates it.

If the user has to complete 10 such processes, he freaks out and reboots you – the operating system. This is the end of the game. Goal – last as long as possible without allowing a reboot. This means that each process must spend enough time on the CPU so as not to drop to the lower “starvation” level.

Sometimes you can see an hourglass symbol on an active process in the CPU. This means that the process is paused because it is waiting for I/O events. Suspended processes waste CPU time, so it is better to remove them from there. To remove the pause, you need to handle the I/O events. This is done by clicking on the I/O events button I/O events()which changes color if such events occur.

As the game progresses, more and more processes appear and it becomes more and more difficult to play. Each process creates memory pages. White pages – those in use, and gray – which are not used. At some point, processes begin to take up more memory than is available in RAM, so you need to move them to disk.

If an active process tries to access pages on disk, the process and the pages themselves begin to flash. This means that you need to move these pages to RAM. Until you do, the process will be suspended.

If a process remains suspended for too long, it will descend further and further down the starvation stages and eventually be terminated by a disgruntled user.

Finally, the game has different difficulty levels that affect the amount of CPU, amount of RAM, number of processes at game launch, probability of I/O events, etc. There is also a setup mode where all these parameters can be adjusted individually.

You can play the browser version on site.

Does the game have educational value?

First of all, the game was created for entertainment, so the main emphasis is on lootability and interest, and not on realism. At a minimum, the player cannot run at the speed of a real computer. But there are other points that do not correspond to reality. For example, in-game processes use LESS memory pages than real processes. And, of course, a real computer user usually does not start new processes endlessly. It’s just a game mechanic designed to make the game more and more difficult.

In other words, the game was not created for educational purposes. However, it may be of some value for familiarizing yourself with operating system principles such as process scheduling and memory sharing. With the help of the game, it is easy to visually show what having more cores in the processor actually does, or what happens when the RAM runs out.

Of course, it should be understood that the operation of the OS is very conditional.

Compilation in WebAssembly

Compiling the game in WebAssembly turned out to be easier than expected thanks to the documentation available. Basic steps: Install pygbag and make code changes. All this is described in the documentation. The biggest problem was the library used to display the emoticons, which did not want to work with pygbag. As a result, I just had to download the SVG files from OpenMoji and use GIMP to resize them and export them to PNG.

By default, the game adjusts its size to the size of the browser window, keeping the same ratio as the desktop version. If the size of the window of the desktop version is smaller, then the game is stretched. At the same time, the appearance of the interface does not suffer much.

By the way, the source code of the game is available at GitHub. Will you try?