openblack: OpenGL and Vulkan Reimplementation of Black & White
openblack is an open-source game engine that supports playing Black & White (2001).
At a glance
- What is it?
- openblack is a C++ reimplementation of the Black & White (2001) engine, built around OpenGL and Vulkan rendering. It suits developers studying engine internals or attempting to run the original game with modified code, but it still requires original game assets and its experimental builds may need patches.
- Who is it for?
- openblack fits developers who want to modify or study a C++ implementation of the Black & White engine and can supply the original assets. It does not fit users expecting a documented, ready-to-launch build without asset extraction or platform-specific patches.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 5 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 23, 2026, and from our analysis. They are not legal advice.
Star history
- openblack/openblack1,591 ★ · +8
| Repository | 2026-10-16 | 2026-10-23 |
|---|---|---|
| openblack/openblack | 1.6k | 1.6k |
8 Stars in the last 7 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
Why openblack Reimplements Black & White
openblack targets a specific legacy game rather than providing a general-purpose engine for new projects. The README describes it as an open-source reimplementation of Black & White (2001), written in modern C++ and using modern rendering engines, OpenGL and Vulkan. Its intended users are therefore developers interested in the original game's engine behavior, source-level modification, or reimplementation work.
The project does not include a replacement for all game content. The README is explicit: users still need the original game assets. This separates openblack's executable code from the data needed to represent the game's worlds, creatures, interface, and other content. The README also points to further instructions for extracting those assets, although the displayed documentation does not include the complete extraction procedure.
That boundary matters when judging adoption. openblack can replace the engine layer as described by the project, but it cannot turn an empty source tree into a self-contained copy of Black & White. It is most relevant to someone who already owns the original game or otherwise has a lawful way to obtain its assets and wants to work with the engine implementation. A prospective user looking for an asset-complete remake will not find that here.
openblack's C++ Code and Renderer Layout
Based on the repository layout, the implementation is organized under `src/`, with application code under `apps/`, reusable or supporting components under `components/`, tests under `test/`, and build-system modules under `CMakeModules/`. The repository also contains an `android/` directory, CMake preset configuration, formatting and linting files, and a `vcpkg.json` manifest. These entries indicate a conventional native C++ project rather than a single script or a thin wrapper around the commercial executable.
The README identifies OpenGL and Vulkan as the rendering engines used by the reimplementation. It does not document a separate rendering abstraction, supported graphics API selection, or required command-line option for choosing between them. The checked-in configuration and source tree provide the places to inspect for those details, but they are not explained in the displayed README.
Compilation and dependency resolution are handled through CMake and vcpkg. The repository includes `CMakePresets.json` and a vcpkg manifest, while CI is split between dependency and build jobs such as `ci-vcpkg.yml` and a packaging workflow. Those files indicate that dependency acquisition and multi-platform configuration are integrated into the project workflow. The repository layout does not support claims about runtime speed, memory use, save compatibility, or fidelity against the original game because no measurements or compatibility matrix are documented.
Downloading a Prebuilt openblack Package
The simplest documented starting point is a prebuilt archive rather than a source build. The README publishes nightly build archives for Linux amd64, macOS amd64, Windows amd64, and Arch Linux. Its experimental section separately labels Windows x86, Windows arm64, Android, iOS, Linux x86, Linux arm64, Flatpak, AppImage, and Snap artifacts as having only a base setup, warning that they may not launch without effort and local patches.
That warning narrows the value of the package list. Desktop amd64 archives are presented as the latest standard builds, but even those do not remove the original-asset requirement. For experimental targets, platform support and package availability should not be treated as proof that the game starts successfully. The README supplies download links but no command-line flags for asset paths, rendering API selection, or launching the game.
The project's sole named release is v0.1.0, released on 2024-09-04. The repository is not archived, and the last push was on 2026-10-16. Those facts show that development activity has not stopped and that the repository remains available, but the documentation does not provide a compatibility statement between v0.1.0 and later `master` builds.
Cloning and Configuring openblack with vcpkg
For a source build, clone the repository with its submodules. The recursive flag is part of the documented command:
git clone --recursive https://github.com/openblack/openblack.gitThis should produce an `openblack/` directory containing the repository and initialized submodules. The README warns that a clone made without `--recursive` can be repaired from that directory:
git submodule update --initThe recommended dependency path is vcpkg. New users are told to select the `"ninja-multi-vcpkg" - Ninja Multi-Config (vcpkg)` preset, allowing CMake and vcpkg to obtain and configure the required dependencies. Supported editors include Visual Studio Code, Visual Studio 2022, CLion, and Xcode.
Visual Studio Code users need Visual Studio Code, the C++ extension, a platform compiler, CMake 3.20 or newer, and the CMake Tools extension. Visual Studio 2022 users need an MSVC C++ component, a Windows SDK component, and the C++ CMake tools component. On macOS, the README names Xcode, Clang, CMake, Ninja, and `pkg-config`.
The Xcode-specific dependency command is documented as follows:
brew install cmake ninja pkg-configAfter installation, the README directs Xcode users to run this command and then configure the `xcode-vcpkg` preset through the GUI or command line:
sudo xcode-select --resetThe displayed README does not include a complete build command, executable name, asset-directory argument, or first-launch procedure. It therefore supports cloning and editor configuration, but it does not provide enough instructions for a documented command-line build and first run.
Asset Dependency and Experimental Build Failure Points
The largest practical failure point is straightforward: without the original Black & White assets, openblack cannot provide the game content. The README's wording is categorical, but the displayed instructions do not name an asset directory, describe supported archive formats, or give an extraction command. Users must therefore consult the full asset-extraction guidance referenced by the README and verify the expected layout against this repository.
A second failure point is platform maturity. The README explicitly qualifies Windows x86, Windows arm64, Android, iOS, Linux x86, Linux arm64, Flatpak, AppImage, and Snap artifacts as experimental. It says not to expect launch without effort and local patches. This makes those packages suitable for investigation and development, but unsuitable as the default choice when the priority is a documented, low-effort launch.
Source builds introduce a third boundary: the build depends on CMake configuration, a suitable compiler, and vcpkg-managed dependencies. The README recommends a specific preset, but it does not publish troubleshooting instructions for dependency resolution, missing submodules, graphics driver failures, or incompatible assets. If any of those occur, the project documentation shown here does not identify a recovery path.
openblack Compared with Running the Original Engine
The practical alternative is to run the original Black & White release rather than use openblack. The difference is direct: the original release represents the existing commercial game runtime, while openblack is a source-level C++ reimplementation built around OpenGL and Vulkan. Only the latter gives developers source code to inspect, modify, compile, and potentially port.
That does not make openblack a better option for playing the game. Users who simply want the original experience have no reason from the documented material to accept asset extraction, source or nightly-build dependencies, and the experimental status of many targets. The GPL-3.0 project also introduces obligations when its code is distributed or incorporated into other software, although determining the exact obligations for a particular use requires reviewing the license text rather than relying on this article.
openblack is more appropriate when the engine implementation itself is the object of work. The README and repository expose C++ source, CMake configuration, tests, components, platform directories, and renderer choices. Those artifacts support development and reverse-engineering-oriented investigation in a way that a prebuilt original game release does not, subject to applicable law, licenses, and asset rights.
Maintenance Signals and GPL Upgrade Responsibilities
openblack is not archived, and its last push was on 2026-10-16. The only named release supplied is v0.1.0 from 2024-09-04. This creates two different upgrade references: a published release line and a `master` branch whose latest push is newer. The README does not provide a version compatibility matrix, migration guide, long-term-support policy, or release-to-branch support schedule.
Users choosing nightly binaries should not assume they match v0.1.0. Conversely, users choosing the named release should not assume it contains later repository fixes. Based on the repository layout, upgrades may affect CMake presets, vcpkg dependencies, submodules, application code, components, tests, and platform packaging together. The documentation does not quantify migration effort.
The project is licensed under GPL-3.0. For organizations considering redistribution or integration, the license file must be reviewed to determine applicable source-disclosure and licensing obligations. The GPL label alone does not answer whether a particular deployment or modification requires a different distribution approach. The original Black & White assets also remain separate from the engine project, and the README does not state a license for those assets.
Editorial conclusion
openblack fits developers who want to modify or study a C++ implementation of the Black & White engine and can supply the original assets. It does not fit users expecting a documented, ready-to-launch build without asset extraction or platform-specific patches. Before adoption, verify the relevant binary for your architecture, confirm that you can provide the original game assets, and check the build preset and dependency configuration for your platform.
Frequently asked questions
Does openblack include the assets from Black & White?
No. The README says users still need the original game assets and points to further information about extracting them, but the displayed text does not include the complete extraction procedure.
What is the recommended way to build openblack?
The README recommends cloning with submodules and selecting the `"ninja-multi-vcpkg" - Ninja Multi-Config (vcpkg)` preset so CMake and vcpkg can handle dependencies.
Are all openblack platform packages ready to launch?
No. The README labels several packages as experimental and warns that users should not expect them to launch without effort and their own patches.
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/openblack-openblack)Star history chart for your README
[](https://hysenlabs.com/projects/openblack-openblack)Was this useful?