Why We Started the GDCC Project

Apr 29, 2026 Back to blog

You may be wondering: doesn’t the Godot engine already include a GDScript interpreter? Why do we need a compiler for scripts? In practice, compiling scripts is common in game development. Unreal Engine has Blueprints, Unity has IL2CPP, and similar approaches appear across the industry.

Why Compile Scripts

We need script compilation because there are urgent practical needs:

We need to prevent games from being unpacked into source code with one click by tools such as gdsdecomp, so competitors cannot instantly copy our work.
Some game logic should not be easy to inspect.
We need to improve script execution speed and avoid CPU bottlenecks.
We need to distribute games on platforms that strictly prohibit dynamic logic.
We want to remove the GDScript interpreter to reduce package size.
…

All of this needs a complete modern compiler: one that can support the modernization of the Godot community’s language tooling, and carry the use cases behind these needs.

Looking Back: The Road to GDScript Compilation

Building a GDScript compiler is not a new idea. In fact, the community has been waiting for this for a full decade:

2016.06: JIT discussion enters a Godot issue

Godot issue #5049 proposed adding a JIT to GDScript, and discussed directions such as LLVM IR, DynASM/LuaJIT, and converting GDScript to C++. The early discussion quickly reached a core problem: JIT availability differs across platforms, and making a dynamic language fast often also requires reliable type inference.

References: godot#5049, Calinou on portability, reduz on type inference and JIT difficulty.
2017.09: The idea of compiling to GDNative/C during export appears

Issue #11068 proposed compiling GDScript into GDNative C code when exporting a game, avoiding interpretation at runtime. The discussion focused on whether Godot would need to ship a C/C++ compiler, whether LLVM was too heavy, how cross-platform export toolchains should work, and whether static types could help generate more efficient code.

References: godot#11068, karroffel on LLVM and toolchains, vnen on transpiling to C.
2018.03: The community experiments with GDScript to GDNative C++

The community project gds2gdn began trying to convert GDScript into godot-cpp compatible GDNative C++ code and generate matching .gdns files. At the time, its README also made clear that it was still in an early stage: it mainly parsed GDScript and output syntax trees, with many limitations before it could produce complete usable C++ output.

References: danielytics/gds2gdn, gds2gdn README.
2018.07: Godot 3.1 introduces optional typing for GDScript

The official Godot blog introduced type hints for GDScript. They were first meant to improve error checking, completion, and readability, but the end of the article also described them as a foundation for later performance work: future versions could add faster instructions for code with known types and do more optimization during compilation.

Reference: Optional typing in GDScript.
2019.03: Godot 3.1 is released, and the performance path shifts toward typed instructions

The Godot 3.1 release article explained that optional typing in 3.1 was still mainly a parsing and checking feature. The later plan was to add typed instructions to the GDScript runtime so code with type information could run faster. This was an important moment where the direction moved from “build a JIT directly” toward “first use type information to optimize the interpreter.”

Reference: Godot 3.1 is out.
2019.09: The official blog publicly mentions typed instructions and future C compilation

In the article announcing George Marques’s full-time work on Godot, Juan Linietsky wrote that George’s GDScript plan included typed instructions, and mentioned that scripts might eventually be compiled to C. Later, the community often treated this passage as one early public source for GDScript’s performance roadmap.

Reference: George Marques will be working full time for the project.
2019-2020: Community AOT and interpreter optimization experiments

In discussion, pchasco mentioned having done many experiments around GDScript to C/GDNative, but in practice ran into GDNative call overhead, the difficulty of reusing old bytecode reliably, and other problems. The work then shifted toward experiments closer to the existing runtime, such as control-flow analysis, dead-code removal, and jump cleanup.

References: pchasco’s summary of AOT attempts, optimizer branch notes, pchasco/godot optimizer directory.
2020.05: The GDScript 2.0 rewrite publicly begins

In a GDScript progress report, George Marques explained that he was rewriting the GDScript implementation to make its overall structure closer to common language implementations, improving maintenance, error reporting, and later optimization work. The first report started with the tokenizer, and also showed that this rewrite was not just a syntax change: it was a reorganization of the whole processing pipeline.

Reference: GDScript progress report: Writing a tokenizer.
2020.06: The new parser, annotations, and await enter GDScript 2.0

The second progress report introduced the new parser, multi-error reporting, annotations, and await replacing yield. These changes established the surface of GDScript 2.0 and made it easier to connect later type checking and optimization work.

Reference: GDScript progress report: Writing a new parser.
2020.06: The official project largely gives up on JIT as a priority

When closing the old JIT issue, vnen said that adding a JIT was very unlikely and that related ideas should move to the new proposal process. Later discussion also pointed out that iOS, Web, and some console platforms do not support JIT. After this point, official discussion clearly leaned more toward AOT, offline compilation, or continued optimization of the existing runtime.

References: vnen closing the JIT issue, neikeq on iOS/Web/console limitations.
2020.07: Type checking, warnings, and constant evaluation return

The third progress report explained that the new type checking had been moved into a separate analysis stage. GDScript does not force every variable to have an explicit type, but it tries to infer expression and variable types where possible. This can catch more errors early and provide more reliable information for later performance optimization.

Reference: GDScript progress report: Type checking is back.
2020.08: GDScript 2.0 is merged into master, with a codegen abstraction plan

The fourth progress report announced that the new GDScript code had been merged into Godot master. The article also mentioned work on a code generation interface abstraction. The target at the time was still the GDScript VM, but this structure could make room for changing the output target and adding optimization stages in the future.

References: GDScript progress report: New GDScript is now merged, godot#40598.
2020.10: Typed instructions land, fulfilling part of the performance promise

GDScript 2.0 added typed instructions: when types are already known while processing code, the runtime can skip some dynamic lookup and take faster paths directly. The official report’s synthetic tests showed improvements ranging from about 5% to 150%, depending on the operation. But this was still an optimization inside the interpreter, not compilation of GDScript into native binaries.

References: GDScript progress report: Typed instructions, godot#43004.
2021.06: GDScript 2.0 becomes feature-complete for Godot 4.0

The sixth progress report announced that GDScript was feature-complete for Godot 4.0, including typed arrays, lambdas, built-in type static methods, fewer addressing modes, a typed temporaries stack, and a test suite. The report still mentioned planned runtime performance improvements, but native AOT/JIT did not make it into Godot 4.0.

Reference: GDScript progress report: Feature-complete for 4.0.
2021.07: The community proposes GDPP / GDScript++

Proposal #3069 introduced GDPP / GDScript++: a language inspired by GDScript 2.0 that outputs C++ and GDExtension. It was not an official Godot core feature, but a community exploration of keeping a GDScript-like style while gaining C++/GDExtension performance.

Reference: godot-proposals#3069.
2021.09: A WebAssembly runtime approach is proposed

Proposal #3370 suggested compiling the GDScript AST into WebAssembly bytecode, then running it through a WASM runtime with interpretation, JIT, or AOT. The attraction was cross-platform behavior and reuse of existing WASM technology, but it remains an open proposal and has not entered Godot mainline.

Reference: godot-proposals#3370.
2023.03: Godot 4.0 is released, and GDScript 2.0 officially lands

The Godot 4.0 release article summarized GDScript’s new abilities: stronger static typing, typed arrays, lambdas, first-class signals, new property syntax, await and super, better error reporting, and more. The article also said the runtime was faster and more stable, but that came from the language backend rewrite and VM optimization, not native AOT/JIT.

Reference: Godot 4.0 sets sail.
2023.01 to now: Official discussion returns to VM performance, AOT, and offline compilation

In proposal #6031, Juan Linietsky summarized that GDScript 2.0 had given the VM more type information, function pointers, and a better code generation structure, but because the parser/compiler rewrite was a large effort, VM optimization itself had not been fully explored. The proposal compared JIT, real-time AOT, and offline compilation, and said the ideal direction might be compiling scripts into a shared library during export, shipping that library with the game, and accessing the engine API through GDExtension.

Reference: godot-proposals#6031.
2023.12 to now: Discussion of an intermediate GDScript format and binary export

Proposal #8605 suggested saving GDScript in an intermediate format closer to processed code during export. This would reduce repeated parsing during loading, avoid shipping direct .gd source, and allow export templates to omit the full GDScript compiler. It is not native AOT; the proposal also explains that if GDScript is truly compiled to machine code in the future, this format may be replaced.

Reference: godot-proposals#8605.
2024.02: Godot 4.3 reintroduces GDScript binary token export

PR #87634 reintroduced the ability to export GDScript binary tokens for Godot 4.x and enabled it by default. This feature can improve loading and source readability concerns, but at its core it is still a tokenized source-level format, not compilation of GDScript into native code.

Reference: godot#87634.
2024.02: The community project GdScript2All

GdScript2All was created with the goal of converting Godot 4 GDScript to C# and C++, while providing both an editor plugin and a command-line tool. Its README also clearly lists limitations: generated code may need manual fixes, pattern matching is not supported, lambdas and parts of C++ output are imperfect, and so on.

References: Lcbx/GdScript2All, GdScript2All README.

Looking Forward: GDCC’s Goal

We want a powerful GDScript compiler. That is why we started GDCC. We want a compiler that is:

Easy to migrate to, able to compile GDScript into a native binary library with almost no script changes.
A blend of dynamic and static typing, letting us keep the convenience of dynamic types while also enjoying the efficiency of static types.
Secure, making it almost impossible to recover source code from compiled output when that is needed.
High-performance, producing compiled code that runs faster, with fully statically typed parts able to approach handwritten C++ code.
Fast, able to compile an entire project in a very short time without long waits.

At the same time, we want more than a compiler. We want a full toolchain for GDScript development, so GDScript can truly become a Swiss army knife for game development. We also want:

An efficient code formatter, so code always stays clean and elegant.
A fast LSP implementation that can provide basic code assistance and diagnostics without starting the engine.
Smart AI-oriented tooling, so programming agents can write, debug, and diagnose GDScript code faster and more accurately.
…

A journey of a thousand miles begins with a single step. May this journey finally reach the stars.