[Uehreka]

Idk that I’d say it’s in 3rd place. My guess would be that something like Source Engine is 3rd.

Having worked with Unreal, Unity and Godot, Godot is extremely rough. It has a terrible scripting language, an abysmal script editing UI, all while lacking the sophistication of Unity and Unreal’s rendering. It gets way too much benefit of the doubt because it’s open source.

We desperately need an open source engine that can compete with Unity and Unreal, but we need to stop kidding ourselves that Godot is serious about filling that role. If they were they would’ve grabbed Lua (or JS, or Python, or anything well established) off the shelf, told devs to use the code editor of their choice, and focused on either building the best rendering pipeline they could with their limited resources, or focused on some sort of clever differentiating feature that Unity/Unreal won’t implement. As it is it’s clear Godot’s team is more interested in reinventing wheels for fun than in making a real contender.

[999900000999]

Source isn't really a publicly available engine. Valve doesn't appear to have much interest in licensing it.

You're not wrong about Godot, but;

1. You can always fork/modify it. Getting a source code license for Unity is a 6 figure proposition.

2. Being open source is a big deal. No phone home spyware(Unity). Keep 100% of your revenue.

3. C# support is OK. Its very slowly getting better.

I'm not a Godot zealot, one if it's biggest weaknesses is a community incapacitated of criticism. But still, your getting something very capable for small scale projects for free.

Unity, if Microsoft brought them out and fixed the business side, would easily be my engine of choice.

I learned to program in it. But I don't trust Unity the company. Every time you turn around they're laying off more people or doing something else strange.

Unreal is very bad for the smaller scales projects I actually build.

Lately I've been making weird prototypes using niche engines. I like Raylib, but it's just a rendering system. It's a much harder path to getting a game made.

If you know someone building a better Godot let me know. I'll try it this weekend.

[Rohansi]

A modified Source 2 is kind of available right now with S&box. It uses C# with the latest .NET, no Mono. Not open source but licensing should be better than Unity.

https://store.steampowered.com/app/590830/sbox/ https://sbox.game/give-me-that

[Uehreka]

> If you know someone building a better Godot let me know. I'll try it this weekend.

Three.js is better than Godot. Yes, even though it doesn’t have a real editor. Yes, even though it’s exclusive to the web. It is a useful and functional tool for building 3D experiences. It has compatibility with almost every file type under the sun. It supports modern/cutting-edge features like WebXR. It has a talented and disciplined maintainer (mrdoob) who has steered the ship for almost 15 years through many big changes while maintaining the same solid core. It has hundreds of easily browsable examples that are kept working and up-to-date.

I wish we were in a better place, but honestly this is where we’re at. If you want to build 3D games/experiences and want an open source stack, use Three.js and stick to the web. There are no good options for native.

[SunlitCat]

Three.js is no game engine, tho.

It can be used to create one and being all Javascript / HTML makes it totally approachable for a task like this.

[npinsker]

In 2025, Godot games are being released at 40% the rate of Unreal games. This number is growing for Godot at +100% Y/Y, while Unity + Unreal are growing at +15% (https://steamdb.info/tech/Engine/Godot/?max_release=2025-12-...). By this metric at least, it's a very secure 3rd (with GameMaker in a distant 4th), and could take 2nd in as few as 3 years.

I mostly do agree with what you said, but the project seems (slowly) headed in generally the right direction, and as time goes on, the space of games that only Unity can make will diminish. It's a totally defensible choice for almost any 2D indie game -- which wasn't true just two years ago -- and it's working towards being a viable alternative on XR and consoles too.

[CactusRocket]

> We desperately need an open source engine that can compete with Unity and Unreal

I think this is a pipe dream. There's a lot of money behind Unity and Unreal, that buys a lot of developers.

Actually I think it's amazing how far Godot has come, and what kind of amazing and big updates they regularly do given how little money they get, and being open source.

It's seeing a lot of active development, so it's definitely not in its final form yet. It can still grow to be serious about filling that role...

> As it is it’s clear Godot’s team is more interested in reinventing wheels for fun than in making a real contender.

This is just a bad faith attack on the Godot's team, and not very much appreciated I'm sure.

[Uehreka]

> I think this is a pipe dream. There's a lot of money behind Unity and Unreal, that buys a lot of developers.

I don’t think it’s a pipe dream. I watched Blender slowly build up from a “nice thing for hobbyists” to “actually kind of professional grade” to “the tool used to make an Oscar-winning film”. Blender and its Foundation provide a blueprint for how open source projects can mount a meaningful challenge in a highly complex and cutthroat space, and anyone looking to do the same for game engines should study their moves.

> This is just a bad faith attack on the Godot's team

I may have been rude, but I was not arguing in bad faith. The decisions they’ve made and their fumbled execution (I could rant for an hour about GDScript’s copious footguns and bad design choices) do not comport with what I expect from a project that wants to one day take on Unity and Unreal.

If Godot is in fact just a fun little hobbyist thing, then yeah, they don’t deserve this level of vitriol from me. But if that’s the case, their community needs to stop overhyping them and suggesting Godot every time people have complaints about Unity/Unreal.

[BobbyBrownGD]

As someone who has barely dabbled in GDScript, I'd like to hear about these design choices and footguns.

[danbolt]

> It has a terrible scripting language

Curious, could you elaborate on what you find terrible about it? I’ve been toying around with GDScript for a little while, and I think it’s actually quite well-suited for developing 3D games.

Or, they get a lot right with gradual typing, reference counting, and low-cost marshalling between native code and the script VM. The language authors know it’s a DSL, so they add specific features such as `$` and `@export` that are idiomatic to the engine’s architecture.

[ImprobableTruth]

I think the concept of a game DSL is cool, but it just feels so undercooked to me.

Like, I'm a huge fan of gradual typing, especially TypeScript's, but gdscript's is just so primitive. Not even to speak of something like intersection or union types, even something basic like an interfaces mechanism is missing. has_method is an awful substitute - in general way too much relies on strings, making even simple refactoring a headache and breaks autocompletion. Lots of things also just aren't typable e.g. because generics are missing, pushing one to Variant. These aren't deal breakers, especially for the small-ish projects I've done, but it just feels bad.

A 'fully realized' version of gdscript would probably be great, but as is I'm just really not very fond of it and progress currently isn't exactly happening at a rapid pace (which is of course understandable).

Also - and this is definitely a lot more subjective - but I find its C++ FFI pretty ugly, even for basic stuff like working with structs. In theory using gsdcript as glue and C++ for the more core things would be a great approach (like unreal with its blueprints), but in practice I just want to avoid it as much as possible.

[npinsker]

Ironically, both features you mention are ones that seem questionable. `$` feels like a bit of an anti-pattern to me because it encourages hard-coding strings, so if you move, rename, or switch components around, it silently breaks. Unity's encouragement of pointers feels cleaner.

Godot has `@export`, but also `@export_multiline`, `@export_dir`, `@export_global_file`, etc. which produce slightly different behaviors. Unity supports true metadata through C# attributes (https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...) -- with all the power of C#, so you can freely add multiple attributes with parameters (which themselves are type-checked) and even program your own custom ones. You can add custom C# attributes, then use those attributes to drive the display of the inspector, which is a perfect little DSL solution that -- because of GDScript -- feels very far away from Godot at the moment.

[archievillain]

Can you please elaborate what you mean by Unity "pointers"? As far as I am aware, in Unity, either you find the node by name via `GameObject.find` or you assign a reference via the inspector. Both of these features also exist in Godot. Actually, thanks to unique names (the `%` notation), I'd say Godot wins overall. But I haven't used Unity in years, so I don't know if they've come up with a better solution (in which case Godot should, obviously, copy it).

[npinsker]

Just a reference in the Inspector. I like unique names too; I was just pushing on `$` specifically.