Up to date

This page is up to date for Godot 4.1. If you still find outdated information, please open an issue.

Frequently asked questions

What can I do with Godot? How much does it cost? What are the license terms?

Godot is Free and open source Software available under the OSI-approved MIT license. This means it is free as in "free speech" as well as in "free beer."

In short:

  • You are free to download and use Godot for any purpose: personal, non-profit, commercial, or otherwise.

  • You are free to modify, distribute, redistribute, and remix Godot to your heart's content, for any reason, both non-commercially and commercially.

All the contents of this accompanying documentation are published under the permissive Creative Commons Attribution 3.0 (CC BY 3.0) license, with attribution to "Juan Linietsky, Ariel Manzur and the Godot Engine community."

Logos and icons are generally under the same Creative Commons license. Note that some third-party libraries included with Godot's source code may have different licenses.

For full details, look at the COPYRIGHT.txt as well as the LICENSE.txt and LOGO_LICENSE.txt files in the Godot repository.

Also, see the license page on the Godot website.

Which platforms are supported by Godot?

For the editor:

  • Windows

  • macOS

  • Linux, *BSD

  • Android (experimental)

  • Web (experimental)

For exporting your games:

  • Windows (and UWP)

  • macOS

  • Linux, *BSD

  • Android

  • iOS

  • Web

Both 32- and 64-bit binaries are supported where it makes sense, with 64 being the default. Official macOS builds support Apple Silicon natively as well as x86_64.

Some users also report building and using Godot successfully on ARM-based systems with Linux, like the Raspberry Pi.

The Godot team can't provide an open source console export due to the licensing terms imposed by console manufacturers. Regardless of the engine you use, though, releasing games on consoles is always a lot of work. You can read more about Console support in Godot.

For more on this, see the sections on exporting and compiling Godot yourself.

Which programming languages are supported in Godot?

The officially supported languages for Godot are GDScript, C#, and C++. See the subcategories for each language in the scripting section.

If you are just starting out with either Godot or game development in general, GDScript is the recommended language to learn and use since it is native to Godot. While scripting languages tend to be less performant than lower-level languages in the long run, for prototyping, developing Minimum Viable Products (MVPs), and focusing on Time-To-Market (TTM), GDScript will provide a fast, friendly, and capable way of developing your games.

Note that C# support is still relatively new, and as such, you may encounter some issues along the way. C# support is also currently missing on Android, iOS and web platforms. Our friendly and hard-working development community is always ready to tackle new problems as they arise, but since this is an open source project, we recommend that you first do some due diligence yourself. Searching through discussions on open issues is a great way to start your troubleshooting.

As for new languages, support is possible via third parties with GDExtensions. (See the question about plugins below). Work is currently underway, for example, on unofficial bindings for Godot to Python and Nim.

What is GDScript and why should I use it?

GDScript is Godot's integrated scripting language. It was built from the ground up to maximize Godot's potential in the least amount of code, affording both novice and expert developers alike to capitalize on Godot's strengths as fast as possible. If you've ever written anything in a language like Python before, then you'll feel right at home. For examples and a complete overview of the power GDScript offers you, check out the GDScript scripting guide.

There are several reasons to use GDScript, especially when you are prototyping, in alpha/beta stages of your project, or are not creating the next AAA title. The most salient reason is the overall reduction of complexity.

The original intent of creating a tightly integrated, custom scripting language for Godot was two-fold: first, it reduces the amount of time necessary to get up and running with Godot, giving developers a rapid way of exposing themselves to the engine with a focus on productivity; second, it reduces the overall burden of maintenance, attenuates the dimensionality of issues, and allows the developers of the engine to focus on squashing bugs and improving features related to the engine core, rather than spending a lot of time trying to get a small set of incremental features working across a large set of languages.

Since Godot is an open source project, it was imperative from the start to prioritize a more integrated and seamless experience over attracting additional users by supporting more familiar programming languages, especially when supporting those more familiar languages would result in a worse experience. We understand if you would rather use another language in Godot (see the list of supported options above). That being said, if you haven't given GDScript a try, try it for three days. Just like Godot, once you see how powerful it is and rapid your development becomes, we think GDScript will grow on you.

More information about getting comfortable with GDScript or dynamically typed languages can be found in the GDScript: An introduction to dynamic languages tutorial.

What were the motivations behind creating GDScript?

In the early days, the engine used the Lua scripting language. Lua can be fast thanks to LuaJIT, but creating bindings to an object-oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with Python, that also proved difficult to embed.

The main reasons for creating a custom scripting language for Godot were:

  1. Poor threading support in most script VMs, and Godot uses threads (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).

  2. Poor class-extending support in most script VMs, and adapting to the way Godot works is highly inefficient (Lua, Python, JavaScript).

  3. Many existing languages have horrible interfaces for binding to C++, resulting in a large amount of code, bugs, bottlenecks, and general inefficiency (Lua, Python, Squirrel, JavaScript, etc.). We wanted to focus on a great engine, not a great number of integrations.

  4. No native vector types (vector3, matrix4, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).

  5. Garbage collector results in stalls or unnecessarily large memory usage (Lua, Python, JavaScript, ActionScript, etc.).

  6. Difficulty integrating with the code editor for providing code completion, live editing, etc. (all of them).

GDScript was designed to curtail the issues above, and more.

What 3D model formats does Godot support?

You can find detailed information on supported formats, how to export them from your 3D modeling software, and how to import them for Godot in the Importing 3D scenes documentation.

Will [insert closed SDK such as FMOD, GameWorks, etc.] be supported in Godot?

The aim of Godot is to create a free and open source MIT-licensed engine that is modular and extendable. There are no plans for the core engine development community to support any third-party, closed-source/proprietary SDKs, as integrating with these would go against Godot's ethos.

That said, because Godot is open source and modular, nothing prevents you or anyone else interested in adding those libraries as a module and shipping your game with them, as either open- or closed-source.

To see how support for your SDK of choice could still be provided, look at the Plugins question below.

If you know of a third-party SDK that is not supported by Godot but that offers free and open source integration, consider starting the integration work yourself. Godot is not owned by one person; it belongs to the