ObEngine: a 2D game engine with Lua scripting on top of SFML

A C++ engine where the game logic is Lua

ObEngine is a free and open source 2D game engine written in C++ on top of SFML, and the repository description says it plainly: a 2D game engine with Lua scripting made on top of SFML. The README insists it is not only a framework but a fully fledged engine with everything you might need, including a map editor, a plugin system and more.

The split between C++ and Lua is the design decision that shapes everything else. The engine core is C++17, and the C++ dependencies listed in the README are ordinary engine infrastructure: the fmt formatting library, spdlog for logging, Catch2 as the test framework, zlib and minizip for zip archives, a minizip wrapper, a dynamic library loader, an extension of the SFML text class, and the Lua runtime itself at 5.4. The binding layer is Sol, the C++ to Lua binding library, which is what makes the scripting side feel like an engine rather than a scripting facade.

Two Lua-side libraries come with it. debugger.lua is an embeddable Lua debugger and inspect.lua gives a human readable representation of Lua tables, which is the sort of tooling that makes an embedded language debuggable rather than a black box.

The feature list in the README is broad for a 2D engine. Event based scripting, animations, a canvas you draw on with a simple API, network support, a scene and GameObjects system, a projects and packages system, a layering system with parallax, polygonal collisions with full collision detection, an integrated CLI to manage a project, a custom package manager with an online repository, gamepad support, bindable actions that support complex key combinations, shader support, and audio in OGG, MP3, WAV and FLAC among other formats.

The scope limit is stated in the same breath: you can do everything with it as long as it is in 2D, since ObEngine does not handle 3D, with maybe partial 3D support in a future update. Platformers, RPGs, 2D racing games, visual novels, roguelikes and metroidvanias are the genres named as realistic targets.

Third-party code is vendored, so the build has no package manager step

The dependency story is unusual enough to be worth a section, because it affects how you build the thing.

You need SFML 2.5.1, which the README links to the exact release page, and you may also need alsa-lib if you are on Linux. Beyond that, the other third-party libraries are included in the repository, in the extlibs/ directory. There is no vcpkg, Conan or system package step for the bulk of the dependencies, which means a clone builds against the versions the author chose.

The bundled list, with the licences the README records, is worth reading for what it implies. The zip handling comes from a minizip wrapper based on Vili Petek's work, the dynamic library wrapper handles plugin loading, the homemade Vili data language is a YAML-like format that is the engine's own serialisation approach, RichText extends the SFML text class, and Lua 5.4 is the scripting runtime. The Lua dependencies are the embeddable debugger and the table inspection helper.

That last entry, Vili, is the piece most likely to be a decision you will meet in the code rather than in the README. A YAML-like data language written for the engine means the engine's own data files, and the configuration of your components, are read through it rather than through Lua tables, JSON or a standard serialisation format.

The licences are all permissive, from MIT through BSD 2-Clause to zlib, with Catch2 under the Boost Software Licence. That matters for a game engine because the code ends up in a shipped binary, and a project that wants to keep its own licence clean will want to see the dependency table rather than assume it.

The map editor, package manager and CLI are part of the engine

The three tools that distinguish ObEngine from a thin framework are the map editor, the package manager and the project CLI.

The map editor is a first class part of the engine rather than an external tool, and the roadmap lists a collaborative map editor as a planned improvement, which tells you the editor is expected to grow. The custom package manager comes with an online repository, so dependencies on other packages are resolved over the network, and there is an integrated command line tool to manage a project.

The plugin system is the third piece, and the README is specific about how it works: native plugins written in C++ that extend the engine, with automatic bindings and a documentation generator. That combination is unusual. Automatic bindings mean a C++ plugin does not have to be wrapped by hand in Lua, and the documentation generator means the plugin's API is documented without a separate authoring step, which is what makes a plugin system usable by people who are not the engine author.

The result is a coherent toolchain rather than a set of unrelated extras. You create a project with the CLI, pull packages from the repository, edit the map in the editor, script the behaviour in Lua, and extend the engine itself in C++ when you need to, with the bindings and the docs handled for you.

The examples repository linked from the README is the place to see what the result looks like in practice, since the engine is only interesting next to games made with it, and the wiki, the documentation site and the Discord are the three places the project points you to for the rest of the story.

Development is paused, and the release trail is much older than the code

The first line of substance in the README is a status note, and it is the most important fact in the repository for anyone considering adoption. It says that the engine development is currently paused, because the author is working hard on a co-op party game called Keep Crafting, and invites people to wishlist it.

Everything else follows from that. The latest tagged releases are obengine-unstable-win from 2020-10-02, v0.4.2 from 2020-09-15 and v0.4.1 from 2020-06-25, so the release trail is nearly six years old, while the last push to the repository was on 2026-07-09. The default branch is v0.5, which is ahead of the last release, and the build badges point at workflows for that branch on both GitHub Actions and Azure Pipelines, so the code is still built by CI even though the releases stopped.

The version scheme is still documented in detail. Each major release is named after a translation of the word for eggplant, and the table lists 1.0.0 as Melanzana from Italian, with the release date still a question mark and the description as the first production release of the engine. So the author has a plan for the naming and has not reached it.

What that means in practice is that you are adopting a paused project with an active repository. The last push date tells you the code is not abandoned, and the pause note tells you the roadmap is not being worked on. Anyone picking this up is maintaining the engine themselves, and the honest framing for a review is that the value is in the code and the tooling, not in a maintained release cadence.

The commercial side is unusually clean for an engine. It is completely free with no premium tier, no in-app purchase and no forced splash screen, and you can sell a game made with it with no royalties, because the engine is MIT licensed. The project relies exclusively on donations.

The build is CMake, and two formatters define the code style

The build system is CMake, and the repository root shows the whole shape of a C++ project of this size: a CMakeLists.txt, a cmake/ directory, a src/ tree, an include/ directory, an engine/ directory, resources/, tests/, docs/ and the vendored extlibs/.

Two configuration files at the root stand out. There is a .clang-format, which is the usual way to keep C++ formatting consistent across a project, and a .lua-format, which is the equivalent for the scripting side. The presence of both is a small but real signal, because the engine has two languages and each has its own formatter. There is a CODESTYLE.md as well, and a CHANGELOG.md, so the conventions are written down rather than left to the next contributor.

The vcpkg.json at the root is the one surprise in an otherwise self-contained dependency story. Since the bulk of the third-party code is vendored, the vcpkg manifest is presumably there for the pieces that are not, most obviously SFML and the Linux audio library, and it gives you a reproducible way to resolve those.

The continuous integration setup is duplicated across two providers, with a GitHub Actions build workflow for the v0.5 branch and an Azure Pipelines build for the same branch. A Codacy badge covers the static analysis side. Two providers is unusual and is usually explained by history rather than by policy, and for a project whose development is paused it also means the build status you see may be the state at the time the last push happened rather than a live signal.

The wiki has a dedicated building page, and the README points to it rather than trying to keep a build guide in the repository, which is the right call for a project whose documentation lives in a wiki.

Where it fits: 2D, Lua, and no mobile export yet

The decision to use ObEngine comes down to a short list of constraints, and they are all stated in the README.

It is 2D only, with 3D listed as a future feature and partial 3D support mentioned as a possibility for a later update. It has been tested on Windows XP, 7, 8 and 10, on Linux for Debian and Arch, and on macOS. Android, iOS and HTML5 export are described as available in a future update, which means they are not available now, and for a project aimed at the web or mobile that is disqualifying rather than a gap.

The other future features are 2D skeletal animations, a collaborative map editor, a light and particle system, scripting the engine in a language of your choice, multiple windows and Tiled Map Editor support. The scripting one is interesting, because it would replace Lua with something else, and the roadmap treats Lua as a choice rather than a permanent commitment.

Against that, there is real substance: a complete toolchain, vendored dependencies, permissive licences throughout, an MIT engine you can modify and ship commercially without royalties, a documentation site, a wiki, a Discord and a repository of open source example games.

So the honest summary is that ObEngine is a capable 2D engine with an unusually complete set of tools, currently between releases, maintained by one person who is working on something else, and best suited to a team prepared to take the engine in-house rather than to a team that wants a supported product.

Editorial conclusion

Adopt ObEngine if you want to build a 2D game in C++ with Lua for game logic, and you value the map editor, the package manager and the plugin tooling more than you mind building on a codebase whose development is paused. Do not adopt it for anything that needs mobile or HTML5 export, since the README lists those as future features rather than shipped ones, and do not plan around a 1.0 release, because the version table still marks the first production release as undated. Before you start, read the building tutorial in the wiki, install SFML 2.5.1, and check the last push date of 2026-07-09 against the fact that the newest tagged release is from 2020, because you will be maintaining the engine yourself.

Frequently asked questions

Official sources

1. License: MIT
2. ObEngine/ObEngine on GitHub
3. Project website
4. README
5. Releases