Godot Improvement Proposals
Welcome to the official Godot improvement proposals repository!
Here, the Godot community shares and discusses
ideas to improve the engine.
Everyone is welcome to participate. If you have an idea, please read the introduction below
to get started. We also encourage you to browse existing proposals and participate in their discussions.
[!TIP]
Use the Godot proposals viewer
to browse proposals, and the discussions tab
to browse ideas.
Bug reports are not a subject of the proposal process. If you experience
an issue while using Godot that cannot be attributed to a missing feature,
please file a bug report instead.
How to suggest improvements
You have two options to suggest improvements for the engine: issues and discussions.
To create a proposal issue,
you should have a well-developed idea of the change you're suggesting, and put effort into a highly
detailed description of it. Please read the rules below before
you create a proposal issue. You may also wish to read about our evaluation process
to improve the chances of your proposal being accepted.
If you have a more general idea for an improvement without specific details, please start
a discussion instead.
We also encourage you to iterate and expand upon ideas of other contributors and try to formulate
proposal issues (with appropriate attribution to those other contributors). This helps
the ideas come to fruition by giving the community something specific to discuss or implement.
All proposals, both issues and discussions, will be discussed and evaluated by the
community, and may even end up being implemented by a fellow motivated Godot contributor.
Keep in mind though that all changes need the approval of Godot maintainers before they can
be merged.
Rules for proposal issues
Note: The following points describe requirements for a proposal issue.
A discussion,
on the other hand, can be started in any form.
-
Do your research. Before you post, discuss your idea with the community,
to find if other people are experiencing the same problem and brainstorm solutions together.
Search existing proposals and
ideas for potential duplicates.
And search the internet and asset library for
addons that can solve your problem without an engine change.
-
Use your own words. You are not allowed to use AI / an LLM to write your proposal.
AI-written proposals are hard to read and often invent facts and solutions that won't work.
If you aren't comfortable with English, write your proposal in your mother tongue and use
dedicated translation software (not a chat bot) to translate it into English.
-
Give context to your problem. To give an example in cooking: Say you wanted to bake
a cake and found a recipe. Don't write your problem as "I need flour", write "I want to bake
a cake". To add flour is the proposed solution. You should also describe which workarounds
you tried and link related proposals. If you do not provide a well-founded motivation, your
proposal will be closed.
-
Be specific with your solution. It is not enough to describe just the idea; your proposal
should make all the necessary design decisions such that they can be discussed by the community.
Include images, mock-ups, diagrams, code, if applicable. If your solution lacks in detail,
is ambiguous, or otherwise unactionable, your proposal will be closed.
-
Use one issue per proposal. Do not cram multiple feature requests into a single proposal,
as this makes it harder to discuss features individually.
-
Have patience. Godot is community-driven: if no other users are interested in
your proposal, it will not be added to Godot. Remember that the more effort you put into your
proposal, the more likely it is to gather attention. You could also share and discuss it in
Godot's community channels to draw attention to it.
What to do if your proposal is closed
We usually only close invalid, duplicate, and rejected proposals. We do not close proposals
lightly, but we can make mistakes: If you think we should re-open it, please join us in the
contributor's chat and describe the situation.
-
If your proposal was closed as invalid, please review the rules above and put more
effort into your next proposal.
-
If your proposal was closed as a duplicate, please review the linked proposal. If it is
truly duplicate, or more detailed than yours, we encourage you to support that proposal and
contribute to its discussion. If you think your proposal is sufficiently different to stand
on its own, please appeal this decision by making a comment.
-
If your proposal was rejected, please review the stated problem and see if you can find
another solution. Often, solutions that are rejected for Godot can be implemented as a
plugin or
GDExtension.
How we evaluate proposals
The following is a list of considerations that Godot maintainers use when deciding to
accept,
close, or leave a proposal open.
These considerations are in balance; no one is more important than another.
Godot maintainers have discretion to weigh the factors as they see fit.
In addition, consider reading this article
which describes technical considerations of Godot maintainers for new features.
1. Does the proposal comply with the rules?
Read the proposal and check to see that it complies with the above-stated rules.
If it does not, close the proposal.
2. How much support is the proposal receiving?
Evaluate the amount of support the proposal is receiving. This is an ongoing
analysis. If a proposal receives little support at first, it may receive
additional support later on.
3. Can this proposal be implemented with an addon or GDExtension?
Evaluate whether it is possible for the solution to be implemented as an addon
or GDExtension.
If it is possible for the proposal to be in an addon, it is less likely to be
accepted.
4. Does this proposal benefit most users?
Determine whether this proposal benefits all users, or just certain users.
For example, a feature that can only be used for 3D FPS games is less
likely to be accepted than a feature that benefits all 3D games.
5. Can this proposal be implemented in a robust, general-purpose way?
Determine whether the feature can be implemented in a robust way that benefits
all use-cases. For example, many games use an inventory system, but every game
implements inventory differently. Accordingly, a proposal for an inventory
system will likely not be accepted because it would be impossible for us to
implement an inventory system that works for most users that need an inventory
in their game.
6. Does this proposal help users overcome a limitation?
Proposals that overcome a specific limitation are more likely to be accepted
than proposals that are just helpful. In short, need-to-have features will be
prioritized over nice-to-have features. Further, the core developers prioritize
changes that enable users to implement features themselves over implementing
those same features in core.
7. How complex would the proposed change be?
A highly complex new feature involving substantial changes to core is less likely
to be accepted than a feature that can be contained within a single node, or a
group of nodes.
8. Can the limitation be easily worked around?
If the feature is only intended to save users a few lines of code, it is unlikely
to be accepted.
