rbfx: the Rebel Fork of Urho3D, packaged as a C++ library
Lightweight Game Engine/Framework in C++17 with WYSIWYG Editor. Experimental C# bindings.
At a glance
- What is it?
- The Rebel Fork is an experimental MIT licensed fork of the Urho3D game engine, positioned as a code first framework you consume like any other dependency rather than an IDE you work inside, with a WYSIWYG editor, prebuilt binaries, cross compilation through Docker and optional C# bindings. Its README includes a section on reasons not to use it, which is the most useful thing in the document.
- Who is it for?
- rbfx fits an independent developer who wants a mature 3D engine they can link into their own build and drive from code, who is comfortable with a C++ API that moves, and who values the Urho3D lineage more than a large asset store. It does not fit a team that wants a plugin ecosystem, a managed scripting language, or ready made gameplay systems, because the README says plainly that you must write the code yourself and that documentation is thin.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 20, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A code first engine, on the Urho3D lineage
The Rebel Fork, aka rbfx, is an indie game engine and framework, and it is an experimental fork of the Urho3D game engine, which was released in 2011 and is distributed under the MIT licence.
The way the README describes itself is a list of six properties, and the fourth one is the positioning. It is just a C++ library with a couple of tools. Everything else follows from that. It is free and open source software and the project says it will stay this way. It is suitable for 3D games and applications. It is moderately lightweight and modular. It is supported for Windows, Linux, macOS, Android, iOS, Web and Xbox via UWP. And there are optional experimental C# bindings.
The reasons to use section makes the trade explicit. It is a code first framework with full control over code execution, unlike Unity-like game engines with an IDE first approach and script sandboxes. It is portable and relatively lightweight, usable like any other third-party dependency, unlike huge mainstream game engines. And because it is a fork of a mature and stable engine that has been around since 2011, it is more feature rich and better tested than many of the newer non-mainstream engines.
The project is written in C++17, the licence is MIT, the site is rebelfork.io, and the repository was last pushed to on 2026-10-10.
The platform matrix has holes, and the Mac and iOS rows need MoltenVK
The README publishes a table of graphics API against platform, and it is the table to read before you start, because the gaps are not symmetric.
Direct3D 11.1 and Direct3D 12 cover Windows and UWP. Vulkan 1.0 covers Windows, Linux, macOS, iOS and Android, with a footnote that Vulkan on macOS and iOS is supported via MoltenVK and that additional setup is required. OpenGL 4.1 covers Windows, Linux and macOS. OpenGL ES 3.0 covers iOS and Android. WebGL 2.0 covers the Web.
So a desktop project has a choice of Direct3D, Vulkan or OpenGL, a mobile project has Vulkan or OpenGL ES depending on the platform, and the Web gets WebGL 2.0 and nothing else. If your deployment depends on Vulkan in a browser, this is not the engine.
The UWP row is worth a second look, because Xbox support is listed in the feature bullets and it is the oldest of the platform rows, and UWP is a shell of a platform that Microsoft has been winding down. Treat that row as a historical artefact rather than a commitment.
The three engine-level promises are also there in the property list, and they are the ones that matter most for an engine fork: supported for Windows, Linux, macOS, Android, iOS, Web and Xbox via UWP, moderately lightweight and modular, and a WYSIWYG editor that comes with it.
Prebuilt binaries, and the difference between the two zips
There are prebuilt binaries for the latest successful build of the master branch, and the README explains the two archives, which is a detail that matters more than it sounds.
The rebelfork-sdk archive can be downloaded and used out of the box. The rebelfork-bin archive contains only the prebuilt binaries without any resources, and the README says to download it only if you already have the necessary resources and you know what you are doing.
The distinction is between the engine and the content. The resources are the art, the sounds and the data that the engine ships with, and the sdk archive includes them while the bin archive assumes you supply your own. For a quick evaluation, the sdk archive is the one that works without further thought.
The README also recommends running the Release binaries, in bin/Release/ or bin/RelWithDebInfo/, and warns that debug binaries may require additional dependencies in order to run, with the Win10 SDK given as the example.
That warning is the kind of thing that saves an afternoon on Windows, where a debug build links against the SDK rather than shipping with it.
One more note on the releases, and it is unusual enough to flag. The tags in the repository are named latest for the latest successful build of master and test for a test release, with the latest dates recorded in 2023 and 2024. There are no version numbers, because the project states that the framework is not yet released and is undergoing active development, and that the C++ API is prone to change even though backward compatibility is mostly preserved at the resource level.
The reasons not to use it are the most honest part
There is a section headed Reasons NOT to use, and it is worth reading in full, because a project that lists its own disqualifying conditions is telling you something useful.
Do not use the framework if you are not ready to do your own research. Because of the small community size, there is not as much documentation, tutorials and other onboarding material, and the README suggests considering mainstream engines with bigger communities.
Do not use it if you are not ready to write code when you need some feature. There is not much ready to use codebase, for the same reason, and the alternative is suggested explicitly, mainstream engines with a user store and ready-to-use assets.
Do not use it if you want the newest graphics graphics or technology for an AAA game. The project says it tries to provide a decent level of technology but does not aim to be at the level of AAA graphics fidelity, and points to commercial mainstream engines backed by paid full-time developers.
Do not use it if you are happy with Urho3D, because this framework is not intended to be a replacement of Urho3D.
And do not use it if you want a C#-oriented Urho3D. The project does have C# bindings, but C# is not a first-class citizen here and its support is lacking, with Urho.Net offered as the alternative.
That last section is the one that decides the project for many people, and it is stated in the same document that invites you to try it.
Building it: CMake on the desktop, Docker for everything else
Building the project is described as usually straightforward on desktop platforms, with a standard CMake configure and build, and on mobile and web platforms extra steps may be needed. The advice for the extra steps is to look at how the GitHub Actions are configured, and then to check the documentation.
The cross compilation story is a Makefile that drives Docker, and the approach is elegant. A single crossbuild image, named after the engine it descends from, is used for every target, and the target is selected with an environment variable.
make cross-linux-staticThe variables are CROSS_TRIPLE, which selects the target, and either STATIC or SHARED, which selects how the library is linked. The targets cover linux, osx, win32 and win64, each in a static and a shared variant, and the Makefile mounts the working directory into the container and a shared directory for the cross build outputs, so the toolchain lives in the image and only your source travels.
That is a good pattern for a project with many target combinations, because the alternative is a matrix of build machines. The cost is a dependency on a Docker image that somebody else maintains, and the image name in the Makefile is the older Urho3D one, which is a small reminder that this is a fork carrying its parent's build infrastructure.
The repository itself is conventional for a C++ project of this size, with Source/, SourceAssets/, android/, packaging/ and script/ directories, a CMake directory and CMakePresets.json, both a Makefile and a Makefile.cmd for Windows, a .clang-format and a .clang-tidy, and a nuget.config for the C# side.
Two template projects instead of documentation
Given the honest admission about thin documentation, the template projects are the onboarding path, and the README describes two of them.
The empty project is the absolute minimum of code required to get things running on desktop platforms, and the README suggests checking it out if you do not care about the recommended high-level workflow and want to do things your own way.
The sample project demonstrates the recommended workflow, which enables certain high-level features such as writing your code once and then running it both from the editor and standalone. It is also mobile and web friendly, and it is deployed to itch.io, which is worth noting because it means the web build is a real deployment rather than a claim.
The distinction between the two captures the difference between the engine as a library and the engine as a tool. The empty project is the library view, which is the one the README sells the project on, and the sample project is the editor view, where the WYSIWYG editor is what makes the workflow pleasant.
For a team coming from an IDE first engine, the sample project is the one to read first, because the code once and run anywhere arrangement is the part that requires an explanation. The documentation repository is separate, at rbfx-docs, with a note that documentation issues and pull requests go there, and the rendered documentation is at rbfx.github.io.
Editorial conclusion
rbfx fits an independent developer who wants a mature 3D engine they can link into their own build and drive from code, who is comfortable with a C++ API that moves, and who values the Urho3D lineage more than a large asset store. It does not fit a team that wants a plugin ecosystem, a managed scripting language, or ready made gameplay systems, because the README says plainly that you must write the code yourself and that documentation is thin. Verify three things before you commit: that the resource level compatibility is enough for your project, since the C++ API is explicitly prone to change while resources are mostly preserved, which platform and graphics API you need, because the matrix has holes, notably no Vulkan on Web and no OpenGL on iOS, and that you are comfortable with a project that has not been formally released and whose release tags are rolling builds rather than versions.
Frequently asked questions
What is the Rebel Fork and how does it relate to Urho3D?
It is an indie game engine and framework, an experimental fork of the Urho3D engine that was released in 2011, distributed under the MIT licence. It is positioned as just a C++ library with a couple of tools, suitable for 3D games and applications, and it ships a WYSIWYG editor. Backward compatibility is mostly preserved at resource level, but the C++ API is prone to change.
Which platforms and graphics APIs does rbfx support?
Windows and UWP have Direct3D 11.1 and 12, Windows, Linux, macOS, iOS and Android have Vulkan 1.0, with macOS and iOS via MoltenVK and extra setup, Windows, Linux and macOS have OpenGL 4.1, iOS and Android have OpenGL ES 3.0, and the Web has WebGL 2.0. The project also lists Xbox via UWP among the supported platforms.
How do I get prebuilt binaries of rbfx?
There are archives for the latest successful build of the master branch. The rebelfork-sdk archive works out of the box, while the rebelfork-bin archive contains only the binaries without resources and is for people who already have the resources they need. The README recommends the Release binaries in bin/Release/ or bin/RelWithDebInfo/, because debug binaries may need extra dependencies such as the Win10 SDK.
How do I cross compile rbfx for other platforms?
Through the Makefile, which runs a crossbuild Docker image and selects the target with the CROSS_TRIPLE variable, for example make cross-linux-static, with STATIC or SHARED choosing how the library is linked. There are targets for linux, osx, win32 and win64, each in static and shared variants, and the working directory is mounted into the container so only your source travels.
When should I not use rbfx?
The README lists the cases itself. Do not use it if you are not ready to do your own research, since the community is small and the documentation is thin, if you are not ready to write code when you need a feature, if you want the newest graphics graphics at AAA fidelity, if you are happy with Urho3D, or if you want a C#-oriented Urho3D, because the C# bindings are experimental and not first-class.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/rbfx-rbfx)Was this useful?