A community-maintained list of Language Support Projects for Godot Engine.
We are in the midst of transitioning from Godot 3 to Godot 4. For this purpose, will Godot 4 become its own section or website, to show all the differences and advantages of the language bindings.
If you want to help, or if you are a language maintainer, see here: https://github.com/Vivraan/godot-lang-support/issues/46
The engine and modules are developed in C++. For those topics, please start with the official docs for contributing to the engine and understanding engine development.
In contrast, the languages provided here are for making scripts in Godot projects. Godot has many methods for granting language support:
Script, ScriptInstance, and ScriptLanguage types in a module. Users add the module to the engine source code and compile the engine themselves (or a developer may provide precompiled binaries). Now you have a new built-in language.ScriptLanguage. Users should only need to download the addon. Powered by Godot's GDNative C interface module.PluginScript and the Script API).NativeScript).GDScript is actively maintained and documented and is stable. It is the primary language, has the most tutorials online, and has deep in-Godot editor support.
VisualScript can be considered as a secondary scripting language with blocks-and-nodes. It too provides rich support, although there is a community effort to make it more intuitive to use as a design tool instead of what users describe as a one-to-one mapping of code with terse programming jargon where it should be more humanized.
These languages are documented and stable. Some people use these in production.
C# support is an official module. If you have a Mono-version of Godot Engine, it comes built into the engine. Most people are using the VSCode extension.
JavaScript support is a 3rd-party module. Modules add built-in support (like GDScript) but require compiling it into the engine. With JavaScript, you also get support for languages that transpile to JavaScript, like CoffeeScript and F# Fable.
This version of Lua uses PluginScript, so you dont need to recompile the engine.
Nim has standard NativeScript features for the moment, but wishes to go beyond that by improving its user experience to automate repetitive boilerplate tasks.
You can find the project homepage here.
The same project that supports JavaScript, also supports TypeScript. In contrast to other 'compile to JavaScript' languages like Fable, does that mean that you get in-Editor support in Godot. It is also implemented as a 3rd-party module. Modules ask you to compile them into the engine.
Stable and not documented yet.
Based on Mono. No API documentation. Usable and community supported.
Maintained by Sheep. Available in the official Discord channel. It is feature complete, performant and pretty much without any documentation.
Maintained by the SimulaVR folks. Feature complete and rudimentary documented.
Provides Haxe/C# bindings to the mono module, exposing almost all of the C# API. It has a small editor plugin to help attach a Haxe script to nodes.
This version of Lua is currently undergoing a rewrite of its parser.
In active development, comparable to being in beta stage.
With C#, you also get support for integrating other Mono-supported languages, e.g. F# or VisualBasic. But, Godot currently hardcodes C# usage. Any class attached to a Node or Resource must be a C# script. For tools to automate the use of F# with Godot's C# scripts, see Godot F# Tools.
Go bindings from godot-go are a recent project in alpha. There is decent documentation of the build workflow and example scripts. It is actively being developed.
Currently in Alpha. More or less feature complete with a few missing targets and some limitations, but with documentation and good performance characteristics. Their Discord is nice and friendly.
Python is the language for which PluginScript, the API that provides Godot-editor support, got designed for. It provides editor integration as GDScript does - it's still in beta. Currently, the bottleneck to its stability is its flawed export system. PyCharm is another way of doing Python for Godot, and this one supports visual debugging
Provides bindings and a Swift Package Manager-powered build system for creating Godot native libraries from Swift frameworks. GDScript APIs are written in terms of Swift protocols and generics, allowing for seamless Swift-to-Godot interoperability. Automates nearly all of the process of registering types and members with the Godot runtime, and ships with an expressive, SIMD-accelerated math library. Has comprehensive API documentation and tutorials.
Bindings for wasm. Implemented via the Rust bindings.
Almost feature complete, with room for some improvements, quite usable as is, except for some issues that root from the Zig compiler and C ABI code gen compatibility.
Potential skub.
C++ is a bit of a hot potato anywhere, and it is here as well: some people like to use it, but it could use better documentation in places. Some peeves such as not being able to use modern C++ features starting from C++11 dwell in this API.
Comparable to being in alpha stage.
This isn't documented or (probably) stable, but it is still very new.
Uses Godot's C# API to make calls to Dart script code. Has code for generating scripts.
Used in production, still certain core features missing. Uses a custom C# VM to interpret arbitrary bytecode from a Pharo Smalltalk library. Cuis Smalltalk support planned. Discord server available.
AngelScript was @Geequlim's first forray into GDNative, before making the ECMAScript bindings.
Mentions nothing about its usability, unmaintained since over 2 years.
Go bindings from ShadowApex haven't been updated since 2018. Not documented or stable enough for production.
Kotlin Native bindings are declared unready for production use and deprecated due to performance problems. Although, it was feature complete at the time of the drop. Here is the old documentation of it.
Ruby bindings haven't been updated since 2018. It's an attempted PluginScript system, but it's designed poorly with ~15x performance loss vs. GDScript. Not documented or stable enough for use.