We all want the same thing from Godot

Anything game-shaped I make, I make in Godot, and have for years. So when I say the proposals repository is a slightly sad read, take it as the complaint of somebody who is not going anywhere.

godotengine/godot-proposals has over six thousand open issues. It is a feature request queue, a design forum and a public argument all at once, and it is far too large for anyone to have actually read. Which means everybody, me very much included, quotes the two or three proposals that agree with what they already thought.

So I pulled the whole thing and sorted it. What came back surprised me. The community is not divided about what it wants. It has been asking for one thing, politely, in about twenty different wordings, since 2019.

What I actually pulled

Open issues, sorted by thumbs up, through the authenticated GitHub API:

gh api "search/issues?q=repo:godotengine/godot-proposals+is:open&sort=reactions-%2B1&order=desc&per_page=100" \
  --jq '.items[] | [.number, .reactions["+1"], .title] | @tsv'

Use the authenticated endpoint or it truncates on you quietly, which I found out the slow way.

Reaction counts measure enthusiasm, not value, and a proposal from 2019 has had seven years to collect them. My favourite calibration datapoint is proposal #4485, “Calinou doesn’t sleep”, which sits at 162 votes and therefore outranks a great many real feature requests. Treat the numbers as a mood ring, not a spec.

The top of the list is one request, twenty times

Thirteen of the top twenty open proposals are GDScript language features. Not the renderer. Not the editor. The language.

Add the rest of the language cluster in the top thirty and you are looking at roughly four thousand votes pointing in one direction. No other theme is close.

Read the titles as a group and they stop looking like a wishlist of conveniences. Nullable types, structs, interfaces, traits, unions, generics, access modifiers, namespaces, method overloading, destructuring. That is not twenty features. That is one sentence, written twenty times, by people who have never met: the language cannot describe the shapes I am already writing.

Which is a good sign, if you squint. It means people are building things in Godot that are big enough to hurt. Nobody asks for interfaces on a game jam entry.

The two proposals at the very top of that list, the two with the most agreement in the entire repository, do not appear on the official priorities page at all.

Nullable types, seven years in

Proposal #162 was opened in October 2019. It has 872 votes and 280 comments and it is the most-wanted open proposal in Godot.

The most-liked comment on it is somebody worrying, which I think is genuinely to the community’s credit. Jummit, on the day it opened, with 393 reactions:

I’m also kinda scared that the whole type system will get even more complex.

Directly underneath, bojidar-bg sketched the Kotlin-shaped version, 234 reactions:

func whatever(v: Vector2?):
    print(v.x) # Warning or error: v could be null
    print(v?.x) # (if there is a null-checked dot operator) Prints null if v is null
    if v != null: print(v.x) # Does not print if v is null
    print(v.x if v != null else 42) # Prints 42

That was written before Godot 4 existed. It still reads fine. I would take it today.

In the meantime people wrote around it. Jummit again, in 2020, offering the workaround everyone eventually reinvents:

const NO_CHARACTER := Character.new()

func create_character(name : String) -> Character:
   if name.empty():
      return NO_CHARACTER
   return Character.new(name)

A whole allocated object whose entire job is to not be null. We have all shipped something like it.

Seven years of that thread later, dalexeev explained in March 2026 why it has not moved, and it is not the reason most of us assumed:

the main obstacle to nullable types stems not from bikeshedding on minor details, but from more fundamental problems like the lack of a unified type system

Plus the deeper one: in Godot, null does two incompatible jobs. It means “legitimately absent” and it means “you forgot to initialise this”, and the language cannot tell those apart. The same comment then asks people to stop posting:

Discussing the specific details of the feature is of little use until we can address the fundamental limitations in the core. Please refrain from adding new comments unless you are sure that they are highly constructive and actionable.

That is a maintainer politely closing the door on a room containing 270 people. It is also completely the right call. Both things are true, and the combination is what makes the thread hard to read.

People are still building it anyway. filipworksdev, August 2026: “I implemented unions in a test branch”, with var x : int | null = 1 falling out for free. In a test branch. Which is where a remarkable amount of this list currently lives.

Structs, and where it got difficult

Structs sit at 701 votes and are the second most-wanted thing in the repository. This is the section I found hardest to write up, so I will stick closely to what is on the public record.

In July 2025, IphStich opened a structs proof of concept against the engine. Eighteen hundred lines. As of today it is still open and unmerged.

In September 2025 they posted to the proposal thread that the design had been discussed in the contributors chat and that the conclusion there was to make Object lighter instead, on the reasoning that a cheap enough Object leaves structs with no problem left to solve. There is also a conduct complaint in that thread. I have read it, I am not going to pick it apart in a blog post, and whichever way it falls I hope both of them came out of it alright.

What I can say is what the rest of the thread sounds like afterwards, because that part is unambiguous. IntangibleMatter, replying the same day, laying out what people are actually after:

Having something which is just a collection of values and nothing else is exactly what structs would be nice for - and it’s something which nothing else in the engine does right now.

And in December 2025, after things had gone quiet:

There’s been multiple PRs with different implementations over the 2 and a half years since this issue was created. It seems like something that (almost) everyone wants, and the issues aren’t in the tech because there have been multiple implementations.

I’m willing to bet it’d be one of the most celebrated additions to GDScript since static typing or callables, maybe even moreso.

I think they are right about that bet, and I also think the maintainers are not wrong that a lighter Object is the more fundamental fix. Those can both be true and it still leaves you with the specific outcome here: somebody wrote the feature, and it is sitting in a branch, and the thing that would replace it does not have a date.

Anyone maintaining a project this size has to say no vastly more often than yes. It is the least fun part of the job and there is no version of it that does not land on a person who spent months. I am not pretending I have a better process to offer. What I did instead was go around it: GATE gives you structs outside the engine, which is not a real answer, it is just one that gets me 98% of the way there without needing anybody’s permission.

Traits: promised, started, still waiting

Traits, 420 votes, opened March 2023. This one is different, because it is on the roadmap and a maintainer picked it up.

vnen, September 2023:

I already started implementing it. But I had some unrelated setbacks so I won’t finish it in time for 4.2.

Calinou, February 2024:

vnen already plans to implement this feature, but they haven’t started yet. It’s not planned for 4.3 but could be implemented in a future release.

It was not in 4.2, or 4.3, or 4.4, or 4.5, or 4.6, and it is not in 4.7. Nobody involved did anything wrong. Nobody overpromised in any way that would be unusual on a Tuesday. Somebody said they would get to it, and then two and a half years of everything else happened, because there is one small funded team and the everything else is not optional.

rule of thumb

A proposal open for six years with hundreds of votes almost never means nobody agrees. It usually means everybody agrees and nobody has the year.

What did ship

I want to be careful here, because it is very easy to read a list of unshipped features and conclude the engine is stagnating. That would be bullshit.

Godot is on a roughly six month release cadence now, which is predictable enough that you can actually plan around it. 4.5 brought abstract classes and methods, variadic functions, and a shader baker that cut load times by more than twenty times on some platforms. 4.6 made Jolt the default physics engine, rewrote screen-space reflections, and finally let you tear docks off and move them. 4.7 landed HDR output on every desktop platform, an AreaLight3D node, a built-in virtual joystick so that is one fewer addon, and the Vulkan plumbing for ray tracing.

Abstract classes are a nice small example of the process working end to end. Proposal #6973 asked for mustoverride in 2023, and this July it was closed with the least dramatic sentence on the whole tracker: “Closing since abstract classes were implemented in 4.5.”

The gap nobody votes on

Away from the language cluster, the clearest hole is authoring 3D worlds.

Replacing GridMap with a proper TileMap3D is at 223 votes and open since 2021. Terrain is at 181, with an older one at 147 underneath it. Neither appears anywhere in the official priorities. Godot ships no terrain system, and everyone building a 3D world uses Terrain3D or HTerrain or something they wrote themselves. For a hobby project that is an inconvenience. For anyone starting an open-world game it is a reason to open a different engine, and it never shows up as a single proposal because it is an absence rather than a request.

omagerio, on the GridMap thread, says it about as plainly as it can be said:

I stopped a lot of 3d projects due to this missing feature.

But the sentence that stuck with me is from a different thread. Portponky had proposed reworking the TileMap terrain system, got told the change was not going to happen upstream, and replied:

Well, that’s obviously very disappointing to hear for me, but I still hope for the best. I will look into making a plugin to implement terrains in a way which is useful for those who are struggling with the existing one.

That is the most Godot paragraph in the entire repository. Turned down, disappointed, immediately starts building it himself, and is somehow still nice about it. Half the ecosystem exists because of people reacting to a no like that.

The actual constraint

Here is the number that reframes everything above, and then I will stop with the numbers.

The Godot Development Fund runs at roughly €35.5k a month in recurring donations. With one-off giving, call it €660,000 a year. That is somewhere around six to eight full-time European developers, covering engine work, code review, production and community, for a general-purpose game engine competing with organisations that employ hundreds.

Against six thousand four hundred open proposals.

You can see it in the specifics. Rendering is stated as the number one priority, and the rendering team has been described by the project itself as very small with nobody working on it full time. The most encouraging recent development is EA’s Battlefield Studios becoming a sponsor, which is a real legitimacy signal, and which at the platinum tier is worth about half a developer. Commercial interest in this engine currently exceeds commercial funding of it by an embarrassing margin.

So the community’s loudest want is language features. The community’s actual need is throughput. Every gap in this post is downstream of that one, and it is the only item on the list that people reading this can directly do something about.

The floor is being replaced while we argue about the furniture

I said I would end this somewhere better than the middle, and there is a real reason to.

Remember dalexeev’s explanation for why nullable types have not moved: there is no unified type system underneath. That is the sort of answer that sounds like a polite forever-no. Except somebody went and started on it.

Over the last few months, GDType has been quietly turning up in merged pull requests. Method maps moved off ClassDB. Property maps followed, accelerating object property access by 1.6x. The property maps were then unified into one, saving about 12MB of runtime memory. This is the “make Object lighter” plan, and it is not a chat message any more, it is in the engine.

Two details I liked enough to check twice. The first is that on the day I pulled this data, a 2025 proposal called “Unify Types for GDScript” was closed with the note that there are now more concrete efforts in a similar direction under GDType. Closed because the real work started, which is the good kind of closed.

The second is that proposal #12928, “Unify the Godot type system by adding a new Type class”, sitting at 90 votes, was opened by IphStich. The same person whose struct PR is still parked. Told no on the feature, still working on the floor it would stand on. I find that genuinely moving and I would like it noted somewhere other than a GitHub thread.

None of this is on a roadmap as “nullable types” or “structs”. Nobody will get a release note for it. But it is the reason the answer to the top of that list might one day be something other than “the core cannot express that yet”.

I got impatient about all of it, personally, and went and built a compiler that fakes most of that list from outside the engine. That is not a criticism of Godot. It is the opposite: it is only possible because Godot is open enough to be worked around by one person in an addon, which is not a sentence you can write about most engines.

If the proposals repository reads as sad, it is worth remembering why. Six thousand people are arguing in detail about the type system of a free game engine they will never be billed for, and have been doing it for seven years without leaving. Most software would take that trade.