Botcraft builds Minecraft bots with a behaviour tree and vanilla physics

A protocol library, not a script that sends chat

Botcraft is described as a cross-platform C++ library to create bots that connect and interact with Minecraft servers, with an optional integrated OpenGL renderer. The topics list adds bot, client, cpp, minecraft and opengl.

The feature list shows how much of the game is actually implemented. There is connection to a Minecraft server in both offline, described as cracked, mode and online connection with a Microsoft account, and DNS server name resolution with and without an SRV record. All official releases from 1.12.2 to 26.3 are supported. Compression is there, along with the signed chat system for 1.19 and later versions.

Then the world simulation: vanilla physics and collisions with a wiki page explaining the details, world data, and full entity support covering type, data, metadata and attributes. Rendering is optional and covers all the blocks, including entity blocks such as chests and banners, and entities with bounding boxes only.

What makes this a library rather than a script is the physics and the entity model. A bot that can walk, fall, take damage and interact with blocks is a bot that has to solve pathfinding, and the behaviour set that comes with it reflects that.

Behaviour trees drive the bots, with a debugger UI

Bots are programmed with a behaviour tree system, documented on its own wiki page, and the included gifs show what that looks like in practice.

One of those gifs shows ten survival bots collaborating on a pixel art build. The README makes two points about it: they are all in survival, so they have to pick the right blocks in the chests and eat food, and they obviously cannot fly. There is no global supervision, and the bots cannot communicate with each other. That is a description of emergent behaviour from independent agents, which is the point of shipping a behaviour tree rather than a script.

The other gif worth reading is the integrated behaviour explorer UI. It supports navigation with translation, zoom and subtree hiding, shows current and previous node status indicators, and has breakpoints and a step by step mode for debugging.

A step mode with breakpoints on a behaviour tree is the feature that makes this usable for real work. When a bot fails to reach a goal, being able to pause the tree at a node and inspect its state is the difference between debugging and guessing. The behaviour tree is also what makes the built-in behaviours composable, since each one is a node you can sequence or condition.

The built-in behaviour set covers the everyday server chores

The list of available bot behaviours is a catalogue of what the library does out of the box.

Pathfinding comes first, and its wiki page notes that it includes ladder and scaffolding climbing, with a separate gif showing a bot climbing through various blocks and falling into water or vines. Block breaking is included with correct tool and haste effects, and block placing works either vanilla or mid-air. Inventory management covers interactions with chests, anvils and brewing stands, and item use covers fishing rods and food eating. Block interaction covers buttons, levers and beds, entity interactions are supported, crafting is supported, and villager trading works for versions 1.14 and later.

The effect of that list is that a server operator can cover most routine automation without writing the low-level protocol code. A farm that involves placing blocks, breaking blocks, moving items between chests and a brewing stand is expressible with the pieces the library already provides.

Bot control with mouse and keyboard is also in the feature list, and the Examples directory shows how that is meant to be used: 0_HelloWorld, 1_UserControlledExample, 2_ChatCommandExample, 3_SimpleAFKExample, 4_MapCreatorExample, 5_MobHitterExample, 6_DispenserFarmExample and 7_WorldEaterExample. The naming is a decent map of the range from a first program to a bot that consumes the world.

Anti-cheat evasion is out of scope, and the README says so

The Not supported section is the most important part of the documentation for anyone deciding whether to use this, and it leads with anti-cheat evasion.

The README states that Botcraft actions and movements are most of the time vanilla-like, but not human-like, and that you should only use Botcraft on your own servers, or ask permission first if you do not want your account to be banned. That is a narrower and more honest position than a library that advertises how well it slips past detection.

The second unsupported area is modded servers. Botcraft aims to be compatible with a vanilla server first. Where possible, modded servers are also partially supported, but given the large diversity of servers and mods, the project does not aim to work on every possible server and mod combination, and the mod support section is linked for the details.

The third limitation is platform specific: rendering and the UI may not work on macOS due to platform incompatibility. Everything runs fine even with the GUI enabled, but macOS will not display the rendering window, which the author says makes it pointless. The recommendation is to use BOTCRAFT_USE_OPENGL_GUI=OFF on macOS.

For a library aimed at server automation, that scoping is a feature rather than a weakness, and it removes the main question you would otherwise have to ask.

Building: C++17, CMake and dependencies that fetch themselves

The code is cross-platform and needs a C++17 compiler, plus git and CMake. The README is explicit about keeping the number of external libraries for the core part of the library very low, currently only one mandatory plus two optionals for additional features, and says this is less true for the rendering part or for testing.

The dependency handling is the part worth knowing. Dependencies are included either directly or as git submodules, and libraries marked as optional are automatically enabled or disabled based on CMake options. You do not have to clone recursively, download or install any of them, because the CMake build system does that for each dependency not already found on your system. The only exceptions are Java, needed to launch the test server if enabled, and doxygen to generate the documentation, and those have to be installed manually.

For the core, that is asio for low-level TCP, marked as a submodule. The optional protocol features are openssl for encryption and zlib for compression, both submodules. The rendering group is larger: glad for OpenGL, glfw for window creation, glm for math, imgui with the node-editor extension for the UI display, rectpack2D for texture packing, and stb_image for texture loading and screenshot saving. The testing group starts with catch2.

The repository layout matches this structure, with a botcraft/ directory for the library, protocolCraft/ for the protocol implementation, 3rdparty/ for the vendored dependencies, Examples/ with the numbered examples, tests/, cmake/, doxygen/ and Assets/.

A shared private repo more than an open source project

The author is direct about what Botcraft is. The README describes it as a learn-by-doing pet project developed on free time when there is a feeling like it, shared with people who might be interested, but more a shared private repo than a real open source community project.

The practical consequence is the release cadence. The author usually tries to push updates on master every first week of each month, and as soon as they are ready for new Minecraft version support updates. The listed release is a rolling tag named latest, published on 2026-10-02, and the last push to master was on 2026-10-03.

That monthly rhythm tied to Minecraft versions has a second effect. Since the feature list claims support for all official releases from 1.12.2 to 26.3, the library has to be updated whenever the game changes, and the value of the library to you depends on it tracking the version your players use.

Precompiled binaries of the library and the examples are published in the latest release for both Windows and Linux, and there is documentation at adepierre.github.io/Botcraft. The licence is GPL-3.0, which matters if you intend to link the library into a closed-source tool, since the copyleft obligations of the GPL apply to the combined work in that case.

Editorial conclusion

Adopt Botcraft if you run your own Minecraft server or have permission to automate against it, and you need more than a script that sends chat commands, since the library implements the protocol, physics, world data and entity model rather than wrapping a headless client. Do not adopt it to automate a server you do not control, because the README states plainly that Botcraft actions are most of the time vanilla-like but not human-like and that only your own servers or explicit permission are appropriate. Before you commit, read the mod support section, because the project targets vanilla first and only partially supports modded servers, check the client version range against the servers you run, and note the release picture, where the latest tag was published on 2026-10-02 and the last push was on 2026-10-03.

Frequently asked questions

Official sources

1. adepierre/Botcraft on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases