lovepotion: porting the LÖVE game framework to Nintendo consoles

A port, and the upstream it is built on

lovebrew/lovepotion is the C++ port of LÖVE, the cross-platform 2D game framework, to Nintendo Homebrew. The project description is two words, LÖVE for Nintendo Homebrew, and the README points you to the wiki at lovebrew.org for the API reference and for how to start making your own games.

The most useful thing in the README is the acknowledgements section, because it sets out exactly what this repository is and is not. The code is not written from scratch. The LÖVE developers are credited, with the note that code is referenced and used in this project, and videah is credited as the original author of LÖVE Potion. So the engine behaviour you get is LÖVE's, and the port work is the part that makes it build and run on Nintendo hardware.

That distinction matters when you evaluate it. This is not a new game engine with a Nintendo-specific feature set; it is a way to run an existing engine, and therefore a way to run existing LÖVE games, on a handheld. The API surface is LÖVE's, which is what makes it a low-friction path for someone with an existing game, and also what caps it: anything LÖVE does not expose is not available here, and anything LÖVE's own limitations are remain limitations.

The repository layout is a conventional C++ project. There is a CMakeLists.txt at the root, a `source/` directory, an `include/` directory for headers, a `platform/` directory for the console-specific code, and a `libraries/` directory for third-party code. There is also a `.clang-format`, which is what you would expect in a project with a large C++ codebase and a stated style, and a `.vscode/` directory for editor configuration.

The last push was on 2026-10-13 and the project is not archived, so it is being worked on.

Three consoles, three toolchains, three build pipelines

The build status badges in the README are the clearest evidence of scope, and they name three targets: Nintendo 3DS, Nintendo Switch and Nintendo Wii U, each with its own GitHub Actions workflow.

The workflow file names carry a branch parameter of dev/3.0, which tells you something useful. The default branch of the repository is main, but the continuous integration for these three platforms runs against a development branch for the 3.0 line. So the version of the engine the CI proves is not necessarily the version on the default branch, and anyone cutting a release needs to know which branch they are releasing from.

The acknowledgements expand on what each console port requires, and the devkitPro section is the most detailed part of the README. It lists devkitARM and libctru for the Nintendo 3DS, devkitPPC and wut for the Wii U, devkitA64 and libnx for the Nintendo Switch, and various portlibs for the consoles. Those are the three distinct compiler toolchains, and the pairing is not arbitrary: the 3DS is an ARM11 core with a Pica200 GPU, the Switch is ARMv8 with a Maxwell GPU, and the Wii U is a PowerPC with a Latte GPU. Each console needs its own compiler, its own libc, and its own graphics layer, and that is why the port carries a `platform/` directory and why the three CI workflows are separate rather than one matrix.

Two further credits round out the dependency picture. piepie is credited with various C++ components, and fincs with citro2d, citro3d and deko3d. Those are the graphics libraries for the Nintendo side: citro2d is the 2D library on top of Pica200, citro3d is the 3D library, and deko3d is the modern 3D API. This tells you that the port is not merely compiling LÖVE for a different CPU, it has a real graphics layer per console, and that the 3DS and Switch paths in particular bring their own 2D and 3D stacks.

The mtheall credit is narrower and tells a story about the order of the work: initial debugging with Switch font rendering. Text rendering is usually the thing that breaks first in a port, because the font rasterisation and the console's own glyph handling do not match what an engine expects.

Where the documentation lives, and what the repository does not contain

The README is short, and that is deliberate rather than thin. Its job is to point you at the wiki, which is where the API reference and the getting-started guides live.

That is a sensible split for a port of this kind. The API is LÖVE's API, and LÖVE has its own documentation, so the useful content here is the delta: how to build for each console, what is supported, what is not, and what has to be done differently. The repository carries no API documentation of its own, no tutorials and no sample games in the listing, so if you are looking for how to get a game onto a device, the wiki is the only source in this project.

The same applies to building. There are no build instructions in the README, no toolchain versions, no command to run cmake, and no instructions for producing a .nro, .elf or .3ds file. The CMakeLists.txt at the root is the build definition, and the CI workflows are the only working example of a build invocation, since they are the things that actually produce the binaries for each console. Anyone building locally is going to be reading the devkitPro documentation for the toolchain and the wiki for the project-specific parts.

There is also no code of conduct, no contributing guide and no changelog in the top level listing. For a project with this narrow an audience, that is understandable, but it does mean that the release notes are the tags themselves, and the description of each release is the only record of what changed.

The release history is short and tells its own story. Version 3.0 was published on 2023-10-16, version 3.0.1 on 2024-03-25, and version 3.0.2 on 2025-08-02, with a release note that reads LÖVE Potion 3.0.2: Too Many Small Fixes To Update As 3.0.1 Edition. The tone of that note is a small piece of project history: a set of fixes too numerous to warrant a separate point release against 3.0.1, folded into a 3.0.2 instead. There are no GitHub releases beyond the tags.

A community with one Discord channel and no support policy

Support for the project runs through a single Discord server, linked in the README as the Help and Support destination. There is no issue tracker policy, no support statement, no changelog and no contributing guide in the repository listing, so the Discord is where questions are expected to land.

That arrangement suits the project as it is. The audience is narrow, the user base is people who already run homebrew toolchains and already know how to build for their console, and the volume of support questions is low enough that a chat server covers it. It is also what you would expect from a project whose wiki, rather than its repository, is the primary documentation.

The comparison with the alternatives is worth making plainly. A project with a large user base needs a public issue tracker, a support matrix and a security contact, because questions arrive faster than any maintainer can answer them in chat. lovepotion does not have that scale, and adopting a heavyweight process would be its own cost. The risk is the other side of the trade: a project that depends on an informal channel and on a handful of individuals, where the disappearance of a contributor costs more than a documentation gap would.

The funding side is equally informal. The README ends with the acknowledgements rather than a donate button, so the labour behind the three console ports comes from people doing it for the sake of the platform, with the devkitPro toolchains as the enabling layer underneath.

What this buys a LÖVE developer, and what it does not

The value proposition is narrow and real. If you have written a game in LÖVE, the game is a set of Lua files, a main.lua, and some assets. The engine is the part that has to change, and lovepotion is that part. Porting a LÖVE game is therefore a matter of getting the engine running on the console and shipping the Lua and assets alongside it, rather than rewriting the game for a native console toolkit.

That is a meaningful saving, and it is the reason projects like this exist. The comparison is with the alternative, which is writing the game in a native SDK, with the console's own rendering, input and audio APIs, and the resulting difference in source layout and asset pipeline between a desktop build and a console build.

What you give up is equally concrete. The engine is LÖVE's, so the feature set is LÖVE's 2D feature set: there is no 3D, no shaders beyond what LÖVE offers, and no console-specific capability like the Switch's homebrew-friendly features. The acknowledgement of citro2d, citro3d and deko3d says the console graphics libraries are there underneath, but the engine above them is the 2D one, and the 3D libraries are there for the port's own needs rather than exposed as an API to games.

The other limit is the ecosystem. This is a homebrew project, which means the audience is people running modified firmware, and the platform support is therefore tied to what the homebrew scene for each console currently supports. It is not a first-party release, it is not on a console store, and it will not be for the foreseeable future.

A third limit is the one every console port carries: the undocumented internals. DWM-equivalent problems do not exist here, but the equivalent is that the console's own system calls and font handling have to be reimplemented against whatever the current homebrew toolchain exposes, which is why the Switch font rendering debugging credit appears in the acknowledgements at all.

Editorial conclusion

Adopt lovepotion if you already write in LÖVE and want to run the same game on a Nintendo handheld, because the engine's own code is reused rather than reimplemented. Do not adopt it expecting a first-party Nintendo release or a maintained build for every console revision, since the project lives in the homebrew ecosystem and its build pipelines target a specific 3.0 development branch, and check first that the console and toolchain you have matches the port you need, because each of the 3DS, Switch and Wii U builds depends on a different devkitPro toolchain.

Frequently asked questions

Official sources

1. Issues
2. lovebrew/lovepotion on GitHub
3. Project website
4. README
5. Releases