jumpRV

Logo
Level 1
Level 2

Inspiration

Assembly is the human gateway into the depths of the computer's inner workings. Assembly is a human-friendly way to write and read binary machine code without having to deal with the binary aspect. Ultimately, assembly expresses the lowest level of abstraction and correlates directly with the hardware.

Young computer scientists are expected to be experts in computers. However, many CS students find it difficult to grasp assembly. Many students are first exposed to high-level languages like C and have difficulty expressing program flow in assembly due to its closer-to-the-hardware nature. Many students shudder in fear at the bare mention of x86 assembly.

One could argue that it might be easier to teach assembly to students as their first language due to its relative simplicity compared to other feature-packed languages. However, a barrier to this is the technical aptitude required to get assembly code to run and compile and do useful things.

So, we GAMIFIED ASSEMBLY. Now students can have FUN learning ASSEMBLY without the TECHNICAL APTITUDE and BACKGROUND KNOWLEDGE required to access it.

(it was Abhi's idea)

What it does

Our educational game is an easy-to-access, gamified path to getting familiar with assembly.

Our game is a visual and interactive way to experiment with assembly instructions and a gentle introduction to the art of whispering to the machine in its native language.

     ██╗██╗   ██╗███╗   ███╗██████╗ ██████╗ ██╗   ██╗
     ██║██║   ██║████╗ ████║██╔══██╗██╔══██╗██║   ██║
     ██║██║   ██║██╔████╔██║██████╔╝██████╔╝██║   ██║
██   ██║██║   ██║██║╚██╔╝██║██╔═══╝ ██╔══██╗╚██╗ ██╔╝
╚█████╔╝╚██████╔╝██║ ╚═╝ ██║██║     ██║  ██║ ╚████╔╝ 
 ╚════╝  ╚═════╝ ╚═╝     ╚═╝╚═╝     ╚═╝  ╚═╝  ╚═══╝

There is an RV that jumps from island to island, controlled by a (R)ISC-(V) virtual machine running user-written instructions. Players must manipulate the virtual machine and use assembly programming concepts to solve the puzzles. Players are guided through a campaign of levels where they will be taught the basics necessary to program in assembly and solve the problems.

How we built it

Even though this project is just a game, it is composed of many diverse technologies painstakingly integrated together to attain a game with a working RISC-V emulator that interacts with the game world.

The game was built with the Unity game engine, FIGMA, magicavoxel, and sheer patience and willpower.

The myriad languages used to build the game include Javascript, Rust, and C#.

We fired up a V8 Javascript Engine to run the assembler as well. That's right, our game has an instance of the V8 engine which we use to do cross-language interop with Rust and then eventually C#. The engine is used to run a Javascript library for disassembling and assembling RISC-V instructions known as rvcodec.js, a product of LupLab @ UCD. Why did we instantiate a Javascript engine to do the simple act of assembling RISC-V instructions? (i) It's not that simple and takes a long time and (ii) we are lazy.

The heart of our game is a RISC-V emulator, rvemu. Of course, if we are too lazy to write an assembler, we are too lazy to write a virtual machine. So, we wrote some C# bindings for rvemu that allows us to use it in Unity.

Challenges we ran into

Most of our issues were combinations of bugs that took us hours to debug. There was a particularly nasty set of bugs related to the endianness of the encoded instructions, the size of types (64-bit integers vs 32-bit integers) interoperating between languages, and parsing errors. We had bad output values and determined that the assembler was outputting the instructions with the wrong endianness. We swap some of our code to big-endian, and it works a couple of times. We were confused - since the manual specified that RISC-V uses a little-endian memory layout. A bit later, it magically stops working and we fix it by reverting the change to little endian. What? We would have been much more productive if we were more efficient in debugging and not stuck on a single bug for 3 hours.

Our workflow was slow and we did not have a good build system for the various components of the game, and we often debugged through painstakingly running commands and pressing buttons over and over again. We had problems with the .gitignore file because so many parts of the projects were changing that we inadvertently gitignored vital files.

The V8 engine was a bit hard to set up. The game concept was a bit hard to think about. The interop between Javascript, Rust, C# made us want to cry. One member of the team didn't have tools installed to build and test the game...