Programmer Casriel has shown the SAGE 2019 demo of Pizza Tower running on a Nintendo 3DS. The interesting part is not that one game was ported. It is that nothing was ported.
Cinnamon is an open-source reimplementation of the GameMaker: Studio runner in C, targeting the 3DS and Wii U. Written by the Project Sunshine Native team, it is a fork of Butterscotch, an earlier open-source reimplementation of YoYo’s runner.
Project Sunshine’s own demonstration of the approach on real Nintendo hardware — Undertale on a Wii.
Why bytecode changes the economics of porting
When you export a game from GameMaker: Studio, the engine does not emit machine code for the target. It emits bytecode — GML compiled to an instruction set for YoYo’s own virtual machine.
That single fact is the whole story. A game shipped as native x86 is welded to x86: porting it means recompiling from source you probably do not have, for an architecture with different endianness, alignment and graphics APIs. A game shipped as bytecode is welded to nothing. It is data for an interpreter, and if you write an interpreter for a new platform, every game in that format runs.
So the unit of work moves. Instead of n ports for n games, you do one runner and the catalogue follows. Casriel’s own framing is exactly this: the Pizza Tower demo is “one of many games Cinnamon will be able to run at release.” Already demonstrated: Undertale, Deltarune, Undertale Yellow.
This is the same leverage that keeps Infocom’s Z-machine games, ScummVM’s adventure catalogue and every ROM-based console library alive. Each depends on someone having built an interpreter rather than a port. GameMaker happens to sit in that category by accident of its own build pipeline, and a large fraction of the last fifteen years of independent 2D games is in it.
What building one actually involves
“Write an interpreter for the bytecode” compresses a great deal of work, and it is worth being clear about the shape of it.
The instruction set is undocumented. YoYo’s VM is proprietary and its bytecode format has changed across versions — reimplementation projects commonly target a specific bytecode version, because an opcode table derived by reverse engineering one export does not transfer cleanly to another.
The runtime library is the larger half. Bytecode calls built-in functions by name, and GameMaker’s standard library is enormous: drawing, surfaces, sprites, audio, collision, data structures, file I/O, input. Every one of those has to be reimplemented against the target platform’s own APIs, and each has to match the original’s behaviour including its quirks, because games depend on quirks.
The 3DS and Wii U are tight targets. The 3DS has on the order of tens of megabytes of usable RAM and a fixed-function-ish GPU; the Wii U is more capable but idiosyncratic. Games authored against a desktop runner assume neither constraint. Making them fit is not interpretation, it is engineering.
Doing this in C, for homebrew Nintendo targets, is the right choice and the harder one — you get the control and the footprint you need, and none of the conveniences.
The project context
Cinnamon exists because of Project Sunshine, a collection of fan-made ports of Undertale, Deltarune and Undertale Yellow for the Wii U, Wii, GameCube and 3DS. The runner was built to serve those ports and turned out to be the more generally useful artefact.
The repository describes itself as “the best working and fully optimized GML runner in C for the Nintendo 3DS and Wii U.” It is MPL-2.0, has 409 stars, and was created in March 2026. Casriel says other Nintendo consoles may follow.
One line in the write-up is doing deliberate work
80 Level notes that the solution was “created without any AI involvement”, and the project’s own write-up carries the same claim.
It is there because this is precisely the kind of project where the claim will otherwise be assumed in the other direction, and because the work is the opposite of what a model is good at: an undocumented binary format, behaviour that has to be inferred from how real games break, and a platform with hard constraints that reward understanding over fluency. Reverse-engineering a VM is a long accumulation of specific, checkable knowledge about one artefact. Stating that no model was involved is a statement about where the knowledge came from.