Emudevz: a Game about Making an Emulator - Review

I always keep an eye on Eki’s weekly publication of new releases playable on Steam Deck, and with Native Linux Builds as I can find some gems there. If there is a demo I often try it.

The game I write today, EmuDevz, is a free game from one of Eki’s lists. Well, even better, the dev also released it as open source.

This game starts with that Zachtronics vibes, a mix of puzzles, story and teaching you about something. In this case, a futuristic post-apocalyptic world where you try to put together an emulator based on recent archaeological discover. NEEES, a fictitious console based on the real life homonym.

You have a partially functioning emulator, but ROMs are glitching because it is incomplete. So you go around fixing CPU, PPU, memory access, and controller modules until you can make them playable.

It starts quite nice, teaching a bit of Assembly through puzzles. It explains what an instruction does, and then asks you to fix a set of instructions to do something needed. I like how you can see the memory being updated with your commands, and keep an eye on pointers and accumulators. I wish I had something like this game when I was learning Assembly a few decades ago, it would make it even more enjoyable.

The story happens in a computer screen, in a terminal. Through a chat with your friend telling you about the concepts, the things you will need to implement and providing you with access to documentation and code templates. Many keywords are clickable, and it would open a document on the left side of the screen, or a quick dictionary entry pop-up.

Everything you will need for a task will be added to your screen in a tiling window-manager style. Do you need a text editor? It will use half of the screen. Want to look at the memory? A quarter of the screen is used for memory, and your editor is now just a quarter of the screen as well.

It would be nice if I had more control over sizes and appearances, but it is not a big issue. Same with keybinds and shortcuts. You have some basic shortcuts to alternate the active element you are interacting with. But if you are in the text editor, you still need to use the mouse to navigate the tabs. I think that might change, the game is new, and I keep seeing new features being added.

Besides the intro that gives you a bit of “this is the future, we found this”, the whole chat is focused around the emulator and how to build one, so do not expect any Sci-Fi writing award from it.

You start with Assembly. It offers a glimpse of what is going on in the emulator hardware. It soon switches to high-level programming, as most of the game is done in JavaScript. Maybe that explains the apocalypse.

When the game changes to JavaScript, it feels less like puzzles and more like corporative workshop. It brushes over a subject, gives you some documentation, a boilerplate and ask you to implement something.

JavaScript knowledge might help speed up things, but it is not necessary. If you have any experience with imperative languages, this will be breezy. The game gives you everything you need to know, and often a pseudocode very close to JavaScript.

If you ever coded an Electron app, or debugged something with a Chromium-based browser, you can also debug your JavaScript with that. With some debugging skills you will be able to see the tests the game does to your code before allowing you to progress.

I had some problems because the unit tests were changing what one of my functions was returning, instead of altering the supposed value in the simulated memory. I notified the author, who promptly fixed it. But that highlights one of the limitations of the game. You are pretty much trying to pass unit tests. It does not matter if your code performs better, or it is cleaner, you need to do whatever the unit test wants, with names and structure it wants.

I give it a pass because it is hard to cover all the bases while testing for function. But at some point I was writing code just to pass those tests and move to the next part, what made me lose a bit of the joy.

My suggestion for improvement would be for the JavaScript part to follow the same suit that you had with Assembly, it would feel more like puzzles, and it would not matter whether people know JavaScript or not. Zachtronics did that well.

Instead of explaining what a PPU is, and what code you need to implement to get it working. It should talk about a problem and ask you to do a little bit, and show the impact of that bit. Then ask you to use the bits you did before to make something bigger. Showing the results at every step.

The way the game is right now, you have to fully implement a component (PPU, CPU, etc…) before seeing the results. And that can take several hours to see any progress of your effort.

It takes about 30~40 hours to fully make the emulator. But you can always load your code to test rooms independent of the status and test the ROMs you have.

Once you complete some parts of the emulator, you get rewarded with some rooms to play. And the more complete you made your emulator, better the gameplay.

While it does not feel much like a game later on. I learned a bunch about making an emulator. But the most important lesson was: “Don’t think too much about why, just do it”. That is because you are emulating something, and not all decisions at the time were made to be optimal. Not only that, but some games rely on some bugs to happen and other peculiarities. If you fix them, those games would not work.

I had some fun with EmuDevz, and it also reawakened my interest for emulation. Leading me to find more literature on the subject, and also to recommend it to everyone.

EmuDevz is free on Steam, and with open-source code available on Github.