OpenBOR: a royalty free engine for 2D side scrolling games

An engine that grew out of a shareware DOS game

OpenBOR started as Beats of Rage, a free beat em up for DOS released in 2003 by the Senile Team, inspired by the Streets of Rage series and using assets from SNK Playmore's King of Fighters series. It spread by word of mouth, and the Senile Team released an edit pack so that anyone could make a module for the BOR engine. In 2005 the developer Kirby2000 asked the team to open the source, the project was renamed OpenBOR, and it quickly spawned a large number of ports and branches. By 2006 the loose group of developers had been reorganised into the OpenBOR Team, and features from the branches were backported into the main engine. The repository migrated from SourceForge to GitHub in 2017, and the project describes itself as a royalty free sprite based side scrolling gaming engine. That origin explains the shape of the whole ecosystem. The unit of work is a module, a package of game assets and scripts, and the community site carries dozens of finished modules to download and play. The listed platforms are Android, Linux, macOS and Windows, which is a deliberately small surface for a project that has been running since 2003.

Scripts decide behaviour, not the engine core

The engine is written in C and sits at the top level in an engine/ directory, with the rest of the repository arranged around it: media/ for assets, tools/ for utilities, tests/ for the test suite, cmake/ for the build system definitions, and a CMakeLists.txt at the root. The part that makes OpenBOR more than a sprite blitter is the built in script engine, and the project's history notes that work on it has been ongoing for most of the project's life. One major early contributor, uTunnels (2007-2014), is credited with the original scripting engine, and the current project manager's stated focus is replacing specialised hardcoding with generalised features that allow for more author creativity. That is the architectural direction: a module author should be able to implement new behaviour in script rather than asking the engine team to add a special case. The 4.0 line moved toward a more object centric script engine during its long development cycle, and the 2026 direction is to keep refining the engine architecture and build tools while removing legacy console port cruft. For a user, the practical meaning is that the difference between a community module that does something clever and one that does not is usually in the script, not in a patched binary.

Building from source with CMake and the build-all script

The repository ships a COMPILING.md file, which is the place the project points anyone building from source, and a build-all.sh script at the top level alongside the CMake configuration. The build system is CMake based, which is what makes the four listed platform ports from one codebase practical.

Running the script is the path the repository provides for producing the engine binaries. A developer working on the engine itself would configure with CMake directly, and the presence of a.devcontainer/ directory and a.vscode/ directory tells you the project expects a prepared container or editor environment rather than a bare system. A CODEOWNERS file, a PULL_REQUEST_TEMPLATE.md, a CONTRIBUTING.md and a CODE_OF_CONDUCT.md describe how changes are expected to arrive. The tests/ directory at the top level is where the engine's own checks live, and unit testing is listed among the contributions of one of the current team members, so the test suite is treated as part of the workflow rather than an afterthought. A.gitattributes file is present, which is the usual signal for line ending and file mode handling across the different platforms the engine targets.

Modules are the unit of distribution, and the community ships finished games

The README is unusually direct about who should use this and why. If you want to try game making, the advice is to open an existing module and tinker, with the community there to help. If you want to make something of your own, the advice is to gather some images and start. If you are feeling ambitious, the suggestion is to dig into the built in script engine and the graphical suite. The commercial angle is stated too, in the form of a suggestion to build something and sell it, and the 2026 focus mentions positioning OpenBOR as a commercial option for beginners and advanced creators while staying enthusiast friendly and royalty free. The current team composition is telling about where the work goes. The project manager handles core engine and scripting development and code cleanup. Malik maintains the Android port, with the stated goal of keeping it commercially viable for authors who want to sell original IP. Kratus, creator of the Streets of Rage X fan remake, contributes unit testing, engine logic advice and bug fixes, and the Linux port. Former members did the ports for PSP, PS3, Wii and GP2X, the Wii GPU accelerated video code, alpha masks, control upgrades and the PalApply tool. The engine is released under the BSD-3-Clause licence.

The 4.0 cycle and the gap between tagged builds and current work

The release history explains a lot about where the project is. The alpha, v7142, was tagged as OpenBOR 4.0 Alpha in December 2019, and after what the history calls an extended development cycle, the first official 4.0 build dropped in 2024 with v7530 and v7533, both tagged on 2024-01-01. Development then continued to refine things and fill in requests that did not make the initial 4.0 deadline. The 4.0 release notes are not part of the repository, so anyone wanting the specific change list has to look outside it. What the repository does show is the direction for 2026, which is the removal of legacy console port cruft and a refinement of engine architecture and build tools, with the stated goal of making OpenBOR a credible commercial option without losing its royalty free character. The repository is not archived, and the last push was on 2026-09-28. So the work is moving, but the tagged builds listed are from the start of 2024, which means the tagged artefacts and the current tree are not the same thing, and a developer who wants the newest engine code should be building from the repository rather than reaching for a release.

Where OpenBOR is the wrong tool

The obvious boundary is the genre. OpenBOR is optimized for side scrolling beat em up style games, and while the README claims it easily accommodates any sort of gameplay style and feature set, that claim is about 2D work in the same family, not about 3D, and the platform list has no console targets. The second boundary is tooling. A C engine with its own script language, its own module format, its own graphical suite and its own asset pipeline is a self contained world, and if your plan depends on a modern editor, on an existing plugin ecosystem, or on a scripting language you already know, the switching cost is real even though the engine is royalty free. The third is the asset situation. The engine does not ship art, and the module format means every game you make needs artwork, animation and a script, so the bottleneck for a solo developer is rarely the engine. The fourth is the platform spread. Four platforms, no console, and a 4.0 series whose newest tagged build is from 2024, so a commercial release targeting a console needs a port nobody has written. The fifth point is about the script engine's own ceiling. The original scripting contribution is credited with breaking nearly every limitation module authors faced, and the current direction is to generalise further, but a bespoke engine still means the ceiling is set by what the core team chooses to build, which is a different kind of dependency from using a large commercial engine.

Editorial conclusion

OpenBOR suits an author who wants to release a 2D side scrolling or beat em up commercially with no royalty attached, and who is prepared to work in the engine's own script language and module format rather than a general purpose game framework. It does not suit a project that needs 3D, physics beyond what the engine provides, or the tooling ecosystem of a modern engine. Before you start, read COMPILING.md, build one of the existing modules to see the format, and confirm that the script language matches the way you prefer to author behaviour, since the last push was on 2026-09-28 and the newest tagged build listed is OpenBOR 4.0 Build 7533 from 2024-01-01.

Frequently asked questions

Official sources

1. DCurrent/openbor on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases