Godot developers have a new packaged route for bringing C and C++ libraries into games without maintaining every dependency inside the project repository. Conan has published godot-cpp 10 in ConanCenter, allowing the engine’s official C++ bindings to be resolved alongside other native packages through the Conan dependency manager.

Godot projects are commonly written in GDScript, but native libraries remain useful for workloads such as simulation, networking, databases and machine-learning runtimes. Godot’s GDExtension interface lets the engine load compiled code without rebuilding the engine itself. The godot-cpp bindings wrap that lower-level interface and allow a C++ class to appear in the editor as an engine class, including its exposed properties.

The build process has historically been the more complicated part. A project must compile compatible bindings for each operating system, architecture and build target it plans to ship. Third-party libraries need corresponding builds and flags. The Godot documentation’s established submodule-and-SCons approach works, but it can leave each project compiling its own copy of godot-cpp and separately managing every native dependency.

The ConanCenter recipe turns godot-cpp into a standard package with selectable API-version and target options. According to Conan’s technical guide, godot-cpp 10 supports Godot versions from 4.3 onward. Developers can choose the oldest API they need to support; an extension built against Godot 4.3 can load in newer compatible releases, though not in earlier ones. Conan can cache each package configuration and reuse it across projects.

Conan demonstrated the workflow with flecs, an entity-component-system library, in a Godot extension that registers a custom Swarm node. The example simulates 100,000 particles, updates their positions through flecs and draws them through a MultiMesh rather than creating a separate Godot node for every particle. The shared extension links the bindings and flecs statically, leaving one native library for the sample project to load.

The example does not eliminate platform work: developers still need profiles and builds for every intended export target, and the extension’s descriptor must map Godot feature tags to the correct binaries. Its practical change is centralizing dependency versions and compiler settings. Package reuse can also shorten repeat builds across multiple extensions, while explicit options make the selected engine API and build target visible in dependency configuration. The workflow remains aimed at developers comfortable with native toolchains and does not change Godot projects that use only GDScript. Teams that already use Conan can now treat Godot bindings and a catalogue of more than 1,900 ConanCenter libraries as one reproducible native dependency graph instead of a collection of separately vendored builds.