LÖVE (love2d/love): a Lua 2D game framework you build yourself

What LÖVE actually gives you, and who that suits

LÖVE is a framework, not an editor. The README describes it as a way to make 2D games in Lua that is free, open-source, and works on Windows, macOS, Linux, Android, and iOS. That sentence is the whole product promise. You get a runtime that opens a window, gives you a draw call, a sound device, keyboard and gamepad input, and a main loop. You do not get a scene graph editor, a tilemap painter, an animation timeline, or a node inspector.

The audience follows from that. It suits programmers who are comfortable writing Lua and want the game loop to be their own code. It suits small projects where a full engine's asset pipeline is more ceremony than help. It does not suit designers who expect to drag sprites onto a canvas, and it does not suit teams that need an editor to be the shared source of truth for level data. If you have used a batteries-included engine before, the first hour with LÖVE feels like being handed a blank file and a graphics API, because that is essentially what happens.

The mechanism: a Lua runtime, a callback loop, and C++ underneath

The repository is C++ with Lua embedded. The dependency list in the README names SDL3, OpenGL 3.3+ / OpenGL ES 3.0+ / Vulkan / Metal, OpenAL, Lua / LuaJIT / LLVM-lua, FreeType, harfbuzz, ModPlug, Vorbisfile and Theora. Read that list as the boundary of what the framework does: windowing and input through SDL3, rendering through a graphics backend you do not choose at the Lua level, audio through OpenAL with ModPlug, Vorbis and Theora decoding, text through FreeType and harfbuzz. The Lua side is a binding layer over those libraries.

Your game is a directory containing main.lua. The runtime loads it and then calls functions you define. The related searches people run, love.load, love.run, love.keypressed, love.graphics.draw, love.graphics.rectangle and love.conf, are exactly those entry points and configuration hooks. love.conf is where window size, title and module loading are set. The testing directory in the repository covers the LÖVE APIs and, per the README, tests them the same way developers use them, and it runs like any other project: love testing. That is a useful detail, because it means the test suite is itself a LÖVE project, which tells you the API surface is exercised through the same path your code takes.

Installing LÖVE and running a first project

The README does not give install steps for end users. It points at the releases section on GitHub for release files and at the project site for files and additional platform content for the latest release. So the supported route is a binary download, not a package manager command, unless you are on a distribution that packages it. For unstable builds the README names ppa:bartbes/love-unstable for Ubuntu and love-git in the AUR for Arch.

Once the binary is on your PATH, the workflow is a directory with main.lua in it. The README shows the test suite being run this way, as love testing, so the pattern is to pass the project folder name to the love executable. The README does not print a main.lua example; the API names it references elsewhere are the ones the wiki documents, such as love.load, love.update, love.draw and love.keypressed.

Run the test suite from a checkout to confirm the installation works before you debug your own code:

love testing

If that opens a window and runs, the runtime is installed correctly. If nothing opens, the binary is not on your PATH or the folder you passed does not contain main.lua.

Building from source is a separate, heavier path

If you want to build LÖVE rather than download it, the README is explicit that in-tree builds are not allowed and the Makefiles must be generated in a separate build directory. The example it gives uses a folder named build and an install prefix:

cmake -B build -S. --install-prefix $PWD/prefix
cmake --build build --target install -j$(nproc)

The README warns that CMake 3.15 and earlier does not support --install-prefix, in which case -DCMAKE_INSTALL_PREFIX= is the substitute. Windows builds are not covered here at all; the README defers to the megasource repository page. macOS and iOS both require Xcode plus a separate dependencies repository, love-apple-dependencies, whose macOS/Frameworks or iOS/libraries subfolder has to be placed into love's platform/xcode tree before the Xcode project will build the love-macosx or love-ios target. Android build instructions live in a different repository entirely, love-android.

That distribution of instructions across four repositories is the honest cost of building this framework yourself. It also means the version matrix matters: the iOS instructions say to download the love-apple-dependencies zip corresponding to the LÖVE version being used, so a mismatched dependency bundle is a real failure mode.

Where LÖVE is the wrong tool

The README states plainly that the main branch is used for development of the next major release and should not be considered stable. Anyone who clones main and builds it is running unreleased code, and the dependency list in the tree (SDL3, for instance) may not match the libraries shipped in the 11.5 release from December 2023. If you need a stable base, you take a tagged release, and the gap between the newest tag and the branch head is the gap you are choosing to skip.

The second limitation is documentation location. There is no API reference in the repository. The README says the project uses its wiki for documentation and directs further questions to forums, Discord and a subreddit. That means version drift between the wiki and your installed build is possible, and you cannot resolve an API question by reading the source tree alone unless you are willing to read the C++ bindings.

The third is scope. LÖVE does not include a physics engine, a UI toolkit, a tilemap system or an asset pipeline as part of the framework's core promise. Those exist as community libraries, but you are assembling them, and each one you add is a dependency the project itself does not test. For a game jam this is fine. For a project with a long maintenance horizon, it means your dependency surface is larger than the framework's own.

How LÖVE differs from Godot for the same job

The comparison people search for is Godot versus LÖVE, and the difference is architectural rather than a matter of taste. Godot is an editor-centric engine: scenes are files, nodes are the unit of composition, and the editor is where most of the work happens, with scripting attached to nodes. LÖVE has no editor in the repository. The unit of composition is a Lua table you write yourself, and the runtime only knows about the callbacks you define.

That changes what is cheap and what is expensive. In Godot, wiring a UI or a scene transition is mostly editor work. In LÖVE, you write it. In LÖVE, the entire game state is plain Lua data you can print, serialize or replace in a test, which is hard to do with editor-owned scene files. The related search for a Love2d editor reflects this gap: there is no first-party one in this repository, so anything editor-shaped comes from elsewhere or from your own tooling.

The other axis is language. LÖVE is Lua, optionally LuaJIT or LLVM-lua per the dependency list. Godot's primary language is GDScript with C# and C++ options. If your team already writes Lua, LÖVE removes an entire language from the project.

Maintenance, licensing and what to verify before you commit

The repository is not archived, and the last push was on 2026-09-20. The most recent tagged release listed is 11.5 from 2023-12-03, preceded by 11.4 in January 2022 and 11.3 in January 2020. Read those two facts together: the branch is being worked on, and the release cadence is slow, with roughly two years between the tags shown. If you depend on a feature that only exists on main, you are depending on something with no release date attached.

The licence file is present at the repository root as license.txt, but the repository metadata reports the licence as NOASSERTION, meaning GitHub could not classify it automatically. The README describes the project as free and open-source. That is not enough to tell you the terms for redistribution or for statically linking the C++ core into a commercial product. Read license.txt yourself, and if you plan to ship on a closed platform or bundle the runtime, have someone qualified check the terms of the bundled dependencies as well, since SDL, OpenAL, FreeType and the codec libraries carry their own licences.

Upgrade cost is the other thing to weigh. Moving between 11.x releases means re-testing against the wiki pages for any API you use, because the API reference is not versioned in the repository. The changes.txt file at the root is where release-to-release changes are recorded, and it is the file to read before bumping a version.

Editorial conclusion

Adopt LÖVE if you already write Lua and want to ship a 2D game without learning a scene editor; the framework gives you graphics, audio, input and a loop, and nothing else. Skip it if you need a visual editor, a built-in physics or UI layer, or a team that expects an engine with asset pipelines, because the repository offers none of that. Before committing, verify three things against the version you download: that your target platform is covered by a build in the releases section, that the wiki page for each API you plan to use matches your installed version, and that your code path does not depend on the main branch, which the README says should not be considered stable.

Frequently asked questions

Official sources

1. Issues
2. love2d/love on GitHub
3. Project website
4. README
5. Releases