GemRB re-implements the Infinity Engine, and it needs your own game data to run

The engine is open, the data is not

GemRB stands for Game Engine Made with preRendered Background, and it is described as a portable open source reimplementation of the Infinity Engine, the engine that underpinned Baldur's Gate, Icewind Dale and Planescape: Torment. The project claims a cleaner design, greater extensibility and several innovations over the original.

That framing puts the legal and practical boundary in the right place. The engine is a reimplementation, which means the code is new work under an open licence, and the game content is not included. The README says it directly: to try it out you either need some of the original game's data, or you can get a tiny sneak peek by running the included trivial game demo.

So a fresh clone gives you a working demo and nothing else. Everything else, the world, the rules, the dialogue and the art, comes from the original game. That is the design of an open reimplementation, and it is also why the project can exist at all: it makes the format and the behaviour available without redistributing anyone's assets.

The audience is therefore specific. It is a developer who wants to build a game like Baldur's Gate, in the same isometric format and against the same data structures. It is a modder who wants the engine to keep working on a modern system. And it is a retro computing enthusiast with a device the original games never ran on.

The licence is GPL-2.0, with the COPYING file at the root and a LICENSES/ directory alongside a REUSE.toml, which is the modern way of recording the licence of every file in a repository with mixed content.

The bundled demo is a real configuration set, not a stub

The demo directory is worth looking at before anything else, because it is the only part of the project you can run without the original data.

It is a small complete setup rather than a placeholder. There is a demo/README.md and a demo/TODO, a chitin.key file, a dialog.tlk, and a set of ini files: gem-demo.ini, keymap.ini and tester.cfg. Alongside them are the asset directories a game needs to start, with music/, sounds/ and override/ subdirectories.

The chitin.key and dialog.tlk are the two files that make the demo plausible. A chitin.key is the key file of an Infinity Engine game, and a .tlk is its talk table, the dialogue table. A demo that ships both of those is a minimal but structurally valid game, which is exactly what a new contributor needs in order to run the engine, change something and see the result without owning Baldur's Gate.

The ini files are the other half of the picture and they are the engine's configuration surface. A keymap.ini holds the key bindings and a tester.cfg is a test configuration, so the engine's behaviour is described in plain text files that a developer can read and diff.

The demo/TODO file is a small honesty signal. A bundled demo that comes with a list of what is still missing tells you it is a starting point, and it is also an invitation to help, which matches the README's pointer to the CONTRIBUTING document with its list of options, tips and priorities.

Getting game data onto a non Windows machine is the first hurdle

The README spends a paragraph on this because it is the step that stops most new users.

The original game data has to be installed if you want to see anything but the included trivial demo. On non-Windows systems you can copy it over from a Windows install, use a compatible installer, use WINE, or extract it manually from the CDs using the unshield tool.

Four options, and they are not equivalent in effort. Copying from a Windows installation is the shortest path if you already have one on another machine. WINE is the general answer for running an installer, and the project links to it in the useful links section as the open source implementation of the Windows API, useful for installing the games. Unshield is the path for people with the original CDs and no installer, since it extracts the .CAB files that InstallShield created, which is what unshield is for.

The project also links a small set of companion tools that make this practical, and they say something about the community's shape. IESDP is documentation for the Infinity Engine file formats and more, the research material a data modder needs. Near Infinity is a Java viewer and editor for the data files, and DLTCEP is the Windows equivalent. And iesh is a Python library and shell for exploring data files, hosted in the same organisation.

That last one explains the python topic on the repository. The tooling around GemRB is written in Python, even though the engine itself is C++.

The platform list is the strongest argument for the project

The supported platforms section is the most striking part of the README, and it reads as a list of places someone got the engine to start.

Linux on x86, x86-64, ppc and mips, with s390x builds but no running information. FreeBSD, OpenBSD and NetBSD. MS Windows. Various Macintosh systems, and the parenthetical note that this even includes pre-x86 hardware. Some smart phones, naming Symbian, Android, other Linux-based systems and iOS. Some consoles, naming OpenPandora and Dingoo. And then a list of exotic operating systems: ReactOS, SyllableOS, Haiku, AmigaOS, AmberElec, ArkOS and UnofficialOS.

The list is the argument. An engine that runs on Haiku, on a Dingoo handheld and on AmigaOS is an engine that depends on very little of the platform, and that portability is exactly what an open reimplementation can offer over a closed engine tied to its original platforms.

The caveats in the list are as informative as the entries. The s390x line says builds exist but no running information, which is a different claim from working, and the README invites corrections in both directions, asking readers to add to the list or to say if an entry no longer works. That invitation is a good sign for the accuracy of the list, and it is also a sign that the list is maintained by people who have the hardware rather than by the project.

For a user picking a platform, the distinction to hold on to is between a platform where the engine is known to run and a platform where the build succeeds, and the list distinguishes those two cases only for s390x.

A modern C++ tree with the tooling of a maintained project

The repository layout is that of a serious C++ project rather than a hobby port.

The build is CMake, with a CMakeLists.txt at the root and a cmake/ directory for the module files, and there is a platforms/ directory for the platform specific code, which is how an engine supports a BSD, a console and an exotic operating system without the platform differences leaking into the core. The engine source is in gemrb/, with tools/ for the command line utilities, testing/ for the test suite, admin/ for the administration utilities, and artwork/ for the packaged art. A Doxyfile generates the API documentation and .clang-format defines the code style.

The quality infrastructure is visible in the badges at the top of the README. There is a GitHub Actions builder workflow, an AppVeyor build for the Windows side, a Coverity scan, a SonarCloud quality gate, and a CII Best Practices badge, which is the Core Infrastructure Initiative's assessment of a project's development practices rather than of its code. The project also has a CircleCI directory and a .sonarcloud.properties file.

Licensing hygiene is handled in a way that is becoming standard: the REUSE.toml at the root and the LICENSES/ directory record the licence of every file, so a repository that contains third party code, art and documentation can still state clearly what is under which terms.

The Doxygen and the documentation site at gemrb.org/Documentation, together with the in-tree gemrb/docs/ directory and the gemrb.6 man page generated from gemrb.6.in, give you three ways to read the same material, which is generous for an engine of this kind.

Writing in the Infinity Engine versus writing in a modern engine

The alternative to GemRB is not another engine, it is a different kind of work, and the comparison is worth making plainly.

With a modern engine you get an editor, a scene format, a scripting language with documentation, an asset pipeline and a community that has already solved the problems you are about to hit. What you do not get is compatibility with the Infinity Engine's data formats, so existing toolchains, existing mods and existing data do not carry over.

With GemRB the trade is reversed. The data format is the original one, so anything produced for the classic games can be read, and the same class of tool exists in the community: IESDP for the file format documentation, Near Infinity and DLTCEP for viewing and editing the data, and iesh for scripting against the files from Python. A developer who wants to make a new isometric role playing game that loads the same resources as Baldur's Gate has no other realistic path, because the format is the format.

The cost of that path is visible in the repository. The version is 0.9.x, the configuration is ini files, and the documentation is a website, a docs directory and a man page rather than a set of interactive tutorials. That is the profile of a capable reimplementation with a community around it, rather than a product with a curriculum.

Maintenance, community and where the work goes

The release history is steady and slow. The published tags are v0.9.5 in March 2026, v0.9.4 in January 2025 and v0.9.3 in July 2024, the repository is not archived, and the last push was on 2026-10-19, so work is landing on master between releases rather than the branch being frozen.

A 0.9 version is worth reading as a signal rather than a number. It says the API is still moving, which for an engine means the interface a game is written against can change between releases, and it says the project is honest about not being finished. The COPYING file and the LICENSE field make the GPL-2.0 terms clear, and for a project whose output is a game engine that runs other people's data, that licence is the reason the project can be shared at all.

The community channels are numerous for a project of this size, and they are the practical route in. There is the homepage at gemrb.org, the GemRB forum on the Gibberlings3 site, an IRC channel on the Libera.Chat network, a Discord channel on the Gibberlings3 server, and a bug tracker on GitHub. The README also asks contributors to start with the list of options, tips and priorities in the CONTRIBUTING file, which is a useful thing to read before opening an issue.

For a newcomer, the sensible order is to build the engine from the INSTALL file, run the bundled demo, and only then look at the data formats. The project is at a point where the engine runs and the data is the interesting part, which is the reverse of most game projects and the reason this one is worth an afternoon.

Editorial conclusion

GemRB suits a developer who wants to write an isometric role playing game in the Infinity Engine's data formats, to mod the classic games, or to run them on a platform Bioware never shipped, and who is comfortable working with a 0.9 version and an ini file driven configuration. It does not suit someone who wants a modern engine with an editor and a tutorial, and it is the wrong choice for a commercial re-release of a Bioware title, since the game data is copyrighted and the licence is GPL-2.0. Verify first that you can obtain the original data for the title you want, since the engine without it is only the bundled demo, and read the INSTALL file and the list of supported platforms before you commit to a platform the project only claims to have built for.

Frequently asked questions

Official sources

1. gemrb/gemrb on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases