Bladecoder Adventure Engine, a point and click engine with a visual editor

A story-first engine, deliberately not a general framework

The Bladecoder Adventure Engine is a set of tools to create interactive graphic adventures, which the project calls classical point and click games. The author frames the motivation in terms of medium and device: this type of game is a good way to tell stories, and mobile devices provide an opportunity to rebirth and evolve the form. The stated goal is to create a platform to tell stories, with interactive stories, modern graphics, animations and music.

That intent explains the shape of the project. It is not a general-purpose game engine with a scripting language and a large plugin ecosystem. It is a narrow, opinionated pipeline for one specific genre, and the whole thing is oriented around the author making the games rather than around a community of developers making the tools.

The project splits into two subprojects. `adventure-editor` is the graphical editor for creating point and click games, and `blade-engine` is the engine that runs the games created with it. The editor's own description is a graphical editor to create full point and click games with minimal programming, which is the correct framing for a tool aimed at people who want to make a game rather than people who want to build a game engine.

The implementation choice is LibGDX, and the documentation explains the reasoning: the project generates a layout similar to any LibGDX project, which lowers the learning curve and eases development and deployment on several platforms. For a Java developer, that is the strongest argument in the whole README. You are not learning a proprietary scene format and a proprietary asset pipeline, you are learning LibGDX with a game-specific layer on top, and the build you already know how to do works.

The audience is small and identifiable: a developer or a writer who wants to ship a point and click adventure, on mobile or desktop, and who is comfortable with Java and willing to spend time in a visual editor.

The editor and the runtime are separate artifacts

The two-subproject split has practical consequences that a single-application engine would not have.

The editor is where a game gets authored. You draw scenes, place hotspots, wire interactions, and set up the visual structure of the adventure. The engine is the player, the runtime that loads what the editor produced and renders it. Because they are separate modules in the same repository, the editor is a development tool and the engine is what ships to a device. The `blade-engine-spine-plugin/` at the top of the tree is a third piece, a plugin that adds Spine support to the engine.

The engine's feature list tells you what a finished game can do. Multi platform support covers Android, iOS and desktop across Windows, macOS and Linux. There are several animation techniques, specifically sprite and atlas animation and Spine cutout animation, which is the technique that gives a 2D character a puppet-like set of moving parts rather than a fixed sprite sheet. Multiresolution support is listed, described as handling different densities and screen sizes, which is the requirement for a single build to look right on a phone and on a desktop monitor. Multilanguage support is there, which matters for a story-first engine, since text is usually the bulk of the content. And the dialogue and puzzle system is built on Ink, the narrative scripting language from Inkle, which the documentation credits with making dialogs and puzzles easy to create.

The Ink decision is the most consequential one for the target user. A separate narrative scripting language means a writer can author branching dialogue and conditional logic without touching Java, and the engine handles the rest. For a tool that wants to be usable by people who are not programmers, that is the load-bearing feature.

The trade-off is a second toolchain. Ink files have their own syntax and their own tooling, and the engine's dialogue behaviour is bounded by what Ink can express.

The Goddess Robbery is the documentation

The project's own answer to its documentation problem is a game.

The Goddess Robbery is described as a test game created to show the features of the engine, and its source can be downloaded from a separate test projects repository, where the documentation says it is useful to learn how to use the Adventure Editor. The game is also available on the Google Play Store under the org.bladecoder.engine package, which means you can also install it and see what the finished result looks like on a device.

That framing is worth taking seriously as a design decision. Learning a visual editor from a screenshot in a wiki is much harder than learning it from a project you can open, modify and break. The test projects repository, the documentation says, is also where you can download and look into when the wiki falls short, and it lists the Venus project as the one to look at.

The documentation section is honest about its state. All available documentation is in the wiki page, and the project states directly that the documentation is not good enough and needs to improve, and that the maintainers are working on it. The workaround it offers is to download and look into the test projects.

A test project is a better teacher than a wiki for the editor, but it is a poor substitute for reference documentation on the engine's API. There is no in-repository API reference in the top-level entries, and the `docs/` directory that some projects carry is not present here. If you need to script against the engine directly rather than through the editor, expect to read the source.

One more thing to note: the test projects live in a different repository, bladecoder-bladecoder-adventure-tests, on its own master branch. A sample that lives outside the project you are reading is a sample that can drift.

Building with Gradle and packaging a distribution

The build documentation is short and assumes a Java developer with the standard toolchain.

The project states that in order to compile, build and run the engine, the Java platform is necessary, and that the project uses Gradle to build and package. The three commands are the whole toolchain.

    $ ./gradlew build

That compiles everything. To run the editor itself, the project documents a second target.

    $ ./gradlew run

And to produce something you can hand to someone else, there is a distribution task.

    $ ./gradlew distZip

A zip package ready for distribution is created in the folder bladecoder-adventure-engine/adventure-editor/build/distributions, according to the documentation. That path is worth noting because it tells you the editor is a Gradle subproject with its own build directory, and the multi-module layout matches the two-subproject structure described earlier.

The repository layout backs that up. There is an `adventure-editor/` directory, a `blade-engine/` directory, the `blade-engine-spine-plugin/` directory, and Gradle files at the root: `build.gradle`, `settings.gradle`, `gradle.properties`, a `gradle/` directory and both `gradlew` and `gradlew.bat` wrappers. The presence of the Windows wrapper is a small signal about who the tool is for, since a game editor is a desktop tool and the platform list includes Windows, macOS and Linux.

For end users there is a different path that skips the build entirely. Prebuilt releases are on the release page, and for Linux users there is a Flatpack package with all the dependencies included, listed on Flathub. A Flatpak is a meaningful choice for an editor that pulls in a game framework's native dependencies, because it means the person installing it does not have to solve the shared library situation themselves.

A version gap that the sample game has to cross

The release history shows a project that moved quickly and then slowed.

The recorded releases are v4.4.0 on 2026-06-08, v4.3.1 on 2023-11-11 and v4.3.0 on 2023-10-19. So the engine sat on the 4.3 line for roughly two and a half years and then moved to 4.4 in mid-2026. The last push to the repository was on 2026-10-22.

The interesting question is not whether the code changed between 4.3 and 4.4, it is what that means for the sample project. The Goddess Robbery was written to demonstrate the engine, and the documentation invites you to download it to learn the editor. If the engine's internals, its asset format or its project layout moved between the version the sample was written for and the version you install today, then the sample may not open cleanly, and learning from it becomes a debugging exercise rather than a tutorial.

The documentation does not state which engine version The Goddess Robbery targets, and there is no compatibility table in the repository. That is a concrete thing to check before you commit time to this tool, and the CHANGELOG.md at the top of the tree is where the answer will be if it exists anywhere.

The project describes itself as currently under continuous development and ready for production, and there is a CHANGELOG file, an AUTHORS file, a CODE_OF_CONDUCT.md, a.github/ directory and a.gitignore. The licence is Apache 2, and the documentation states what that means in plain terms: you can use it free of charge, without strings attached, in commercial and non-commercial projects.

For a game engine, permissive licensing is a real advantage if you ever want to ship a commercial title on it.

Editorial conclusion

Bladecoder Adventure Engine suits a developer or writer who wants to make a classical point and click adventure, particularly one who already works in LibGDX or wants dialogue written in Ink, and who is prepared to learn the tool from the sample game rather than the documentation. It does not suit a team that needs well-maintained documentation, since the project states plainly that the documentation is not good enough, and it does not suit a browser-first project, since the supported platforms are Android, iOS and desktop. Verify first that the test projects still build against the current engine version, since the documentation does not state which engine version the sample game targets, and make sure the version of the engine you take matches the editor you plan to work in.

Frequently asked questions

Official sources

1. bladecoder/bladecoder-adventure-engine on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases