Introduction to engine contributions

The possibility to study, use, modify and redistribute modifications of the engine's source code are the fundamental rights that Godot's MIT license grants you, making it free and open source software. As such, everyone is entitled to modify Godot's source code.

Contributing changes upstream has two big advantages:

  • Your code will be reviewed and improved by other developers. It will be further maintained in the upstream project, so you won't have to reapply your own changes every time you move to a newer version. On the other hand it comes with a responsibility, as your changes should be beneficial to all users; so in some cases it might still be better to keep your changes only for your own project by maintaining a fork.

  • The whole community will benefit from your work. Other contributors will behave the same way, contributing code that will be beneficial to you. At the time of this writing, over 2,000 developers have contributed code changes to the engine!

To ensure good collaboration and overall quality, the Godot developers document rules and guidelines for the contribution process. You can find these in the Pull request rules and guidelines and Engine contribution guidelines.

You can contribute changes using the PR workflow. We value all contributions; however please note that PRs may take a while to be reviewed. Critical bug fixes, as well as simple, relevant changes are reviewed with priority. Read the section below to find meaningful changes to contribute.

What can I contribute?

See also

This section explains how to make contributions to the engine as a C++ programmer.
See How to contribute to find other ways to contribute to Godot.

You can theoretically propose and implement any kind of change to Godot. The community will discuss whether the change is needed and appropriate, and will make suggestions for how to improve it. Area maintainers consider community demand, priority, and complexity, and make a decision about whether to accept it.

Even if you already have some specific change in mind, in many cases you should report a bug or propose the change first. These are useful for maintainers to understand the change, and proposals especially are used to gauge community interest and challenge your solution idea.

If you would like to contribute, but don't have anything specific in mind, we recommend looking for simple, relevant, and uncontroversial changes to contribute, especially at first.

A great place to start is by fixing bugs. Issues labeled as good first issue are issues that maintainers think should be good for newcomers. However, these issues are claimed pretty quickly, so it is possible you won't find anything actionable here.

If you are knowledgeable or interested in a specific area, you can browse its bug reports using the associated labels or by looking through trackers. Some teams also maintain a triage project. This can be an especially effective way to make meaningful contributions. Find triage projects linked in Areas and teams.

Many contributors are interested in contributing improvements or new features. This kind of contribution can be more difficult than fixing bugs, because changes need to be evaluated for priority and complexity, and because they need to receive a healthy amount of discussion before they can be considered for merge. You can learn more about our guidelines for new features in Best practices for engine contributors. New features also have a lower priority than bug fixes, so they can take longer to review. To find meaningful improvements to contribute, you can look for accepted improvements in the teams' triage projects, or you can browse the proposal viewer to find proposals with community interest. Keep in mind that, until a proposal is accepted, your pull request might not be reviewed. It can often be better to engage with the proposal discussion before starting work to implement something.

Once you start gaining more experience, you can help with the review process. You can find pull requests to review by browsing each team's review requests and triage projects, by browsing pull requests and filtering by label, or by exploring the Godot team reports and PRs by file websites.

Checklist for new contributors

By reading this list, you can make a great first impression as a new contributor:

  • Test your pull request. The code you submit might be used by tens of thousands of users. At the very least, please test it to avoid any surprises.

  • Disclose the use of AI. If you use AI, you need to tell us. AI-written code and descriptions have risks, so if you care about the long-term health of Godot, please be transparent about how you created your contribution.

  • Set up local style checks. The tests will fail on your pull request if it does not pass a style check. Save yourself some time and set up local style checks.

  • Keep it simple. We intentionally avoid using complex C++ features unless necessary. In most cases, avoid using clever solutions if a simple solution does the trick.

  • Adapt to the style of surrounding code. Observe the code you are changing, and avoid changing it to suit your own personal preferences unless there is a tangible benefit.

For everything else, we have the pull request rules and the engine contribution guidelines. To become a proficient contributor, continue reading at your own leisure.

Setting up a dev environment

You can learn how to work with our source code using the Engine development section.

Additionally, we recommend you set up style checks locally. For example, we use clang-format and clang-tidy to format our C++ code. The easiest way to set them up is via pre-commit.

You can install pre-commit in your local Python installation using pip using the shell code below. Depending on your system, there may be other ways to install it which you may prefer.

pip install pre-commit
pre-commit install

IDE integration

Learn how to configure an IDE in respective Godot docs section.

You may also want to set up style checks with your IDE. Most IDEs or code editors have beautifier plugins that can be configured to run clang-format automatically, for example, each time you save a file.

Here is a non-exhaustive list of beautifier plugins for some IDEs:

(Pull requests are welcome to extend this list with tested plugins.)