With 4.0 getting more and more advanced features [0] and Unity merging with an Ad company [1], Godot is looking like it could be an attractive proposition for a lot of Unity shops.
Godot is really cool, but a clear and publicly delineated path to console distribution (and not "go talk to these guys", as they currently do) is going to be necessary to get material interest out of most of the gamedev space.
Yes. This is the main and only major thing that is holding Godot back from mass indie adoption. I would choose GMS2 or Unity over Godot for a 2D commercial indie project even though GML is worthless on a resume and Unity has all the Unity problems, because they build to all the consoles. Or Defold, since it is really nice and at least can target Switch.
And I would choose Unreal or Unity or maybe even Cocos Creator (which recently added Switch support) for a 3D project for the same reason.
If you want mass adoption, you need to make it financially viable for commercial indies to use your engine, and good luck convincing those people if they know they need to hire a 3rd party company to port to consoles.
Since Godot can't really go the console route, though, they basically need to do the work of figuring out how their users can make enough money on just web, mobile, and/or desktop, and then articulate and successfully sell that solution to them. Steam Deck could help for sure, but it's a big ask
Wait, why not? I thought it was a deliberate choice on the devs' part not to prioritize native support for consoles, not something that's actually impossible (since obviously other third party engines do it).
- To develop for consoles, one must be licensed as a company. As an open source project, Godot does not have such a legal figure.
- Console SDKs are secret and covered by non-disclosure agreements. Even if we could get access to them, we could not publish the platform-specific code under an open source license.
1. This doesn't seem like a big deal. I'm sure there's some legal-fu you could do here to have a 'company' that's the primary contributor to Godot. Wikipedia has a company of some sort, does it not? And Mozilla's a company.
2. So what? Yes, the console-specific stuff has to be kept secret, that sucks, but it's better than not having support for consoles at all. I'd rather have a closed-source module to port to consoles than having no official method whatsoever.
Is there a practical difference between "Godot does not target game consoles" versus "Godot does target game consoles, but we can't tell you where or how or help you in any way"?
That's not what we're discussing. From another comment:
> MonoGame gets around it by having core team members that grant access to private trees for approved developers. It's not open source, but it's available.
Yeah I feel like there are definitely ways around this, technically and legally.
However, it seems they are not compatible with the goals and philosophy of the Godot project. That is their choice to make and if you don't agree with it, then your needs don't match with Godot and you should choose a different project.
I can understand where Godot is coming from. Getting involved with the corporate world is a slippery and corrupting slope and before you know it you'll be partnering with ad and malware companies like Unity is doing. Ok maybe not, but it's still not a decision to take lightly and in a world where everyone is motivated by money it is refreshing to see some communities like Godot and Blender who are doing things their own way.
If Monogame can do it, I don't see why Godot couldn't. Godot clearly wants to compete seriously with Unity at least in the indie game dev space, I don't see how you do that without a decent console solution. The more mature Godot becomes, the weirder it's going to seem that they don't support consoles.
I think just doing the minimal amount of cooperation to get SDK's or what have you for consoles would be fine, and very few people would object even within the open source community. A few diehards would no matter what, but as long as the cooperation is bare minimum I think it'd go okay.
> Getting involved with the corporate world is a slippery and corrupting slope and before you know it you'll be partnering with ad and malware companies like Unity is doing.
Godot's team isn't a for-profit company, that's the key distinction here. Unity's primary purpose is to make money, offering a game engine is just a means to that end. Godot's primary purpose is to be a useful and easy-to-use game engine, so much less incentive to blatantly sell out.
why is it only when an engine support console do it mean "serious" competition?
An indie game dev may make their game for non-console platforms, and if that game proves to be a hit, a separate development effort could be made to target a console. Or a re-implementation. If console is the first, or only choice, i would argue that the team is not really indie (by which i mean self-funded and small).
And who knows - may be godot's popularity would change the way consoles engineer their legal contracts and not hide behind NDAs and secrecy to become more open.
> a separate development effort could be made to target a console. Or a re-implementation
"Could." Sure. Or they "could" use an engine that doesn't require reimplementation to target Where The Market Is.
Which is why, even though people really don't like it much, Unity gets used.
> If console is the first, or only choice, i would argue that the team is not really indie (by which i mean self-funded and small).
This has not been a reasonable statement for at least five years. Indie games don't have lead platforms, but they do, as a matter of practice, need to be on all relevant platforms to have a chance of financial viability. (A grand strategy game might not need to deploy to consoles. Most other stuff really, really does.)
> And who knows - may be godot's popularity would change the way consoles engineer their legal contracts and not hide behind NDAs and secrecy to become more open.
Platform holders do not care about your engine and no indie developers, even en masse, have enough weight to make swing them. EA and Activision might not, at least not in a way that wasn't a special exception just for them, and they move a lot of product by themselves.
super meat boy was first released as a flash game on new grounds. The success there lead to the future release on console and PC (and i recall seeing it was rewritten for these platforms, rather than porting the flash version, but now i can't find a reference).
And while braid is indeed released first on console, there's at least one citation of Blow decrying the process:
https://en.wikipedia.org/wiki/Braid_(video_game)#cite_ref-xb... . Blow likely had no choice at the time because steam (in 2007) wasn't as big a platform as it is today.
I am still of the opinion that console-only releases are not good for indie developers, despite the apparent contradiction of it being more profitable. And the reason Braid had xbox live arcade release is more to do with the industry connection Blow has, rather than the merits of the platform. Even Blow himself initially thought he'd be making a PC release for this game (until the financial side-benefits of xbox arcade back then kicked in).
MonoGame gets around it by having core team members that grant access to private trees for approved developers. It's not open source, but it's available.
The consoles make this explicitly incompatible with open source though. That could possibly be a separate entity I suppose, or hopefully if Godot becomes big enough the consoles could arrange something.
I'd love official console support but it's not possible being open-source. Porting it yourself is an option, but not many will be inclined to do that and would have to opt for paying a third-party to do so.
The reason other consoles are not officially supported are:
- To develop for consoles, one must be licensed as a company. As an open source project, Godot does not have such a legal figure.
- Console SDKs are secret and covered by non-disclosure agreements. Even if we could get access to them, we could not publish the platform-specific code under an open source license.
- Consoles require specialized hardware to develop for, so regular individuals can't create games for them anyway.
1. This doesn't seem like a big deal. I'm sure there's some legal-fu you could do here to have a 'company' that's the primary contributor to Godot. Wikipedia has a company of some sort, does it not? And Mozilla's a company.
2. So what? Yes, the console-specific stuff has to be kept secret, that sucks, but it's better than not having support for consoles at all.
3. Okay? Godot isn't just being used by "regular individuals", whatever that means, it's being used by people who want to make games and then sell them -- including, yes, companies -- and those people want to be able to publish games to consoles.
That last one is just bizarre. Who do they think their userbase is, exactly? "People who want to make games for PC and mobile but have zero interest in any consoles ever"?
> People who want to make games for PC and mobile but have zero interest in any consoles ever
I don’t understand why you are surprised by this? By your own admission, nobody that wants to develop for consoles would use Godot, so logically, their entire userbase are people that don’t want to do that.
There are absolutely people interested in using Godot as a game engine, including using it to make games for consoles. But many don't, because porting to consoles is painful and expensive, apparently involving third parties as a general rule.
Obviously people for whom porting to consoles is a high priority are unlikely to choose Godot right this second, but we're talking about potential users as well, not just the current exact userbase.
I just don’t think that ‘potential users’ are a really strong consideration for what ultimately amounts to a hobby project (or a project with no corporate backing anyway).
I don't know what your objection is. They make a game engine, they support PC and mobile by default, console is the obvious missing piece of functionality. I can understand why it's lower priority because yeah, it's harder to support, but at least one of the devs works on this full time, and the two core devs have been working on this for several years now. I think it's a bit beyond hobby project, they're clearly trying to compete with Unity, even if it's not a for-profit company.
Granted, it's still small potatoes compared to Unity, no doubt.
edit: huh, looks like they have several people full-time, from the article
> Godot is developed by more than a thousand contributors, and coordinating this massive community requires a full-time involvement of several of us (and hopefully soon even more full-timers), which your generosity enables.
edit2: holy shit Unity had 5000 employees in 2021 according to Wikipedia. I knew they were fairly big but goddamn, didn't think they'd be that big.
Man, now I'm also confused at how they can have a successful, popular game engine with a flourishing asset store and yet still be losing money. Just hired too many people?
It's definitely Godot's opportunity to drive a lot of adoption, I'm seeing a ton of disgust from a lot of indie devs I follow, and looking for alternatives to Unity now.
FWIW, I'd bet I could replicate many of these games sans release polish in a weekend in Unity solely because of their expansive asset store. Building them from scratch would take longer, but not that much longer.
If Godot had even the beginning of an asset store, it'd be way more appealing to devs like myself migrating away from Unity. Especially with Unreal's recent megascans and Quixel integrations making their asset store look inspiring, I can't imagine many Unity studios (who, IME, primarily focus on rapid development and tooling over asset work) will be drawn to Godot.
Obviously context is important, though: the asset store isn't the end-all reason people use Unity and rarely the reason a studio chooses the engine, but it is still a big factor for both groups. Other factors will apply, YMMV, etc.
Carol Reed Mysteries[53] (since 2021)
Commander Keen in Keen Dreams (Nintendo Switch port only)
Cruelty Squad
Deponia (iOS and PlayStation 4 ports)
The Interactive Adventures of Dog Mendonça & Pizzaboy
Hardcoded
Kingdoms of the Dump
Sonic Colors: Ultimate
If I'm remembering correctly the new UI elements in the remaster were done in Godot, but the actual game was not. The new Godot menus are slow and unresponsive, so Colors isn't a great showcase for Godot.
As much as I'd like to use Godot, there are two features missing that I really don't think I could do without:
- Asset store. I totally get it, handling payments, curating, etc. are a huge task... but man, I'm a coder, and I don't have the funds to pay an artist or a musician full time. Being able to just go buy a pack of trees for $20 or something is a huge timer saver.
- Animation re-targeting. It seems like there's a 3rd party plugin for this but it also seems like it hasn't been updated in a year. In unity I can buy a big pack of animations for pretty cheap and reuse it on almost all my humanoid characters. That's huge. I think this can be done in Blender or Maya, but it's so seamless in the engine compared to using a 3rd party tool.
> - Asset store. I totally get it, handling payments, curating, etc. are a huge task... but man, I'm a coder, and I don't have the funds to pay an artist or a musician full time. Being able to just go buy a pack of trees for $20 or something is a huge timer saver.
Heh I mentioned this in another Godot thread a few days ago. It sounds like a potential YC funded startup for anyone inclined and something that could be with the knowledge and collaboration of the core maintainers of Godot as a simple means to fund Godot.
It would be good if Godot adopted it into its UI, it technically has the UI for it. Then the company donates a reasonable percentage to Godot. You might see them never need to ask for donations again.
I think people that spend enough time to learn to use a game engine will go to the trouble of finding the best site / source for assets. Unity and Unreal both have good sites for this, but that's partly because it is there business model. Godot is just not as much of a business. It seems like the two great potential business (attention HN types :) ) are:
- asset / plugin library stores
- simple libraries / frameworks for console ports that are not open source / or a port service.
Well, maybe it should be. I don't think anyone would begrudge the Godot team taking a small percentage as part of running an asset store, and that means more people who can work on Godot full-time, in addition to the convenience of the asset store itself.
I wouldn't want Godot to go full blown for-profit public corporation, but having more full-timers and more of a real business model like some other open source foundations sounds good to me.
I absolutely understand the upsides of the assets store. Although not as expansive as the asset store, there are lots of either free or extremely affordable; many of them with CC0 licenses or licenses that make them extremely easy to just use them. I wouldn't have been able to make my first game in Godot Puck Fantasy (available here: <https://www.lowkeyart.com/puckfantasy>) without them!
I would encourage you to try some of these! You'd be surprised how far you can get by using these, with and without modification.
These are my favorite resources, in order of preference.
- <https://www.kenney.nl/> is by far the best one and most expansive one. Everything he creates is CC0. A lot of great free assets available on his site. He also has a "Kenney Game Assets All-in-1" which can be bought on itch.io for $19.95. It has all assets he's ever made, neatly organized, and ready to use. All CC0. This also includes some music. The music and sound assets are much more limited than the 2D and 3D assets, but it's there, and it's solid.
- <https://kaylousberg.com/game-assets> has some fantastic assets also available for free, and has more available for a pretty affordable Patreon tier. Also has a CC0 license for the free assets. Mostly a specific style, which is great for consistency, but a bit more limited than the wide variety of Kenney; but I don't doubt that with time they'll build an equally strong library of assets.
- <https://quaternius.com/> has many free great assets. Also CC0. Has a high variety of styles and settings. Also has a very affordable Patreon to get easy access to everything they produce.
I second this. The variety on itch.io is a godsend. Godot is flexible enough that you can work with most of the assets available on itch. My experience is mostly with 2D and isometric games, but it was straightforward to import assets downloaded from itch.io and get going.
I also prefer the separation between the engine and asset store. I would rather not have a magic button I press in my IDE to have asset show up in the game.
If you're just talking about some models or sprites, can't you just buy them wherever in any file format Godot supports and import them? Ok, you might have to spend a bit of time wrapping them in Godot's nodes, but it seems like that would be quick and trivial
I mean, you can do that, but you have to consider a lot more things:
- Are these assets authored in a way that's friendly to my game engine of choice? IE, will the materials import correctly, will animations be correct, are things scaled properly, is the Z axis up or is it forward, etc. Having dealt with importing files between various engines and 3d modelers, seamless importing and exporting is no small thing.
- What's the license, and are the licenses standardized? Do I have to pay royalties or record attribution?
- What's the selection on these sites? Do I have to enter my payment info into like 20 different sites?
- This also only covers art/sounds. Unity has a huge selection of code assets that are incredibly useful.
None of those are insurmountable of course, but having one place that solves all those problems is great.
Sure, but there IS such an ecosystem. For example, for 3D, there are sites like TurboSquid, which shows up on the front page of a Google search for "3d model asset store"
Indeed. People think of Unity as a game engine and it's really not. Unity is a service provider, whose major services is the asset store, analytics, ad platform, and so forth. The game engine and editor is just the hook. Most long-term Unity developers have a toolkit of assets that massively overhaul the engine, anyhow; and Unity leans into that.
Godot is an interesting engine and editor, but that's not enough to make me switch. Show me the ecosystem of services and tools that surround it, and how _utterly trivial_ they are to access, and I might consider switching.
I've been using Godot for hobby projects on-and-off for a while now, and overall I vastly prefer it to Unity. The scene hierarchy of Godot is a better mental model (for me) than the GameObject/MonoBehavior ever was.
That said, I have a _few_ items that I think are absolute showstoppers for solo-dev side projects.
1. The asset pipeline is simply not as clean as Unity's. The ability to drop a .blend file in the project in Unity is so underrated. In Godot FBX imports are unreliable, texture imports misbehave frequently, and rigging goes wrong even in the recommended file formats. There's a lot less clarity around the path to getting real assets in game, which can be a major pain point for solo devs.
2. Along the same lines, there is no equivalent of Unity's mecanim. With Unity, if you can model and rig a character in Blender, you can pull free mocap or other animations from the asset store and get to work. In Godot you're still best off authoring your own animations for each character. This drastically increases the amount of time spent making assets.
3. Godot is in a weird spot version wise for anyone who wants to use C#; the beta version of 4.0 is rapidly approaching, and guarantees to break any project you start in 3.x --- but 4.0 still doesn't come built with C# support. Hopefully this gets resolved soon.
> One is an industry behemoth and the world’s most popular game engine, while the other is a free, 30 megabyte program developed by passionate developers in their free time.
I was under the impression that Godot had at least two full-time devs working on it. Between their patreon revenue and the grants they've received they can definitely afford a small team on payroll. It's still important to stress the comparison in scope between Unity and Godot, but the latter is definitely more than a hobby project at this point.
That's a good point, I can edit that for clarity in the article (especially since I mentioned Godot's Patreon support later in the article). I was assuming that the Patreon support didn't amount to full time support for all the devs that contribute, but I don't know if that's true or not.
Either way, it seems a lot of people have contributed without sponsorship, but the main devs are (hopefully) compensated.
There are at leasts two full time devs and a handful of other devs on paid projects (by way of Patreon and a few large donations of companies like Epic)
As I understood it reading the news, it is more like a grant for innovation, so just a PR opportunity for Epic. I don’t think they are worried that much.
I think Blender got the same grant as well, and maybe others.
The problem with Godot is still it's age, and the lack of proven projects which many people are working on at once.
Myself and plenty of others at small or above size studios would have to make a huge leap into Godot and hope you don't run into any scaling issues. Not just from a project point of view, but integration on the artistic side.
LTS versions of Unity despite the known "un-fun" of it, are stable in a sense. Godot is moving fast, that isn't always a good thing for stability.
I'd love to jump on the new shiny and fun engine! But having to make the definitive choice for a company to make their next project in? Unfortunately just isn't there yet. "It's fun as a dev" just isn't a compelling argument for literally everyone else who isn't the engineer, compared to the number of all size studio pumping out Unity projects(Some even being successful!).
Do you think Blender overcame this challenge, or is it still a sticking point in the VFX industry? I know they're at very different levels of maturity but I'm curious if the open projects ended up helping with ironing out these kinks.
I'm very much a hobbyist gamedev, mostly doing small personal projects or game jams when I have the time.
I switched from Unity to Godot in 2016 when 2.0 came out and I haven't looked back since. I find Godot fits so nicely with how I like to make things compared to Unity or Unreal. It has that comfy feeling like Aesprite, sxfr, and bosca ceoil where the tool itself has an artistic expression.
I agree with most downsides that people have in regards to Godot, lacking asset store, lacking in the amount of tutorials compared to other engine, lacking in completed titles at scale, etc.
However for my purposes I've never found these to be a deal breaker, and if anything I prefer being part of the smaller community that Godot has - it feels more grassroots and aligned with my personal values.
>You can also use C#’s events, which are strongly typed, but if you need to interface with node events, you should use Godot’s signal system.
Nope. Nope. Nope. Nope, I wasted 2 hours of my life trying to get these signals to work in GD script.
I'm going to try some other open source engines, but trying to jerry-rig an extra language on top of a relatively immature engine isn't a very good idea.
Now I imagine if Microsoft decided to come out of an engine, they could rationalize supporting six or seven languages. But if you're already a small project, what ends up happening is the other language support just isn't as good
Unity is suffering because it can't find a way to make DOTS/ECS first class without completely redoing basically everything.
That's my biggest complaint with Unity at this point. So much is built around the GameObject implementation that when you start using ECS you can feel the friction - you're writing a lot more code, you're doing things in a way that feel like swimming upstream, and there's less support + documentation.
How does Godot compare? Are highly threaded features out of the box? I would use Unreal but the C# Unreal interfaces I've seen are very immature.
If you're doing high-end 3D stuff, Godot 3.x will probably disappoint you anyway.
If you're doing graphically simple games with a complex simulation under the hood (everyone loves RimWorld as an example), then you don't really benefit from an ECS that's tightly integrated with the engine. You just do all that stuff however you want, and use the engine as an I/O layer.
Godot also seems to be built in a way that creates friction for ECS style game logic. It's built around scenes that are trees of nodes that each have associated behavior and signaling/message passing between nodes.
I haven't used it, though I've been curious about it. As far as better options for ECS game engines go, I'd go with Bevy (personally), but you'll have to learn Rust (which I'm a proponent of anyway).
But both of these are still in "Beta", if that's even the proper term for their development cycle, at this point. They work, technically, but they could use some help, to my understanding.
Godot uses a similar object oriented approach as Unity. For ECS, you might keep an eye on Bevy[1]. It’s still not mature but its team has been making progress. Even Unity and Unreal had to start somewhere.
ECS on its own doesn't always help - it's not a magic bullet for every situation: sometimes you need to use spatially-aware data structures / acceleration structures for those type of "queries", and vanilla ECS (i.e. similar to a DB in terms of queries) doesn't always help you in these type of situations.
What's wrong with .NET core? It's the future of .NET afaik and it has multiplatform support and it's open source.
> .NET (Core) -- A cross-platform and open source implementation of .NET, rethought for the cloud age while remaining significantly compatible with .NET Framework. Used for Linux, macOS, and Windows apps.[0]
I think gp is saying that since it switch from mono to core before you will be able to finish a game, you might have a bad time when they switch implementations.
It's certainly possible that that's the case, but I've seen a lot of projects go from Mono to .NET Core without much of a hiccup, too.
Probably worth pricing in some slack time to deal with it if it's a problem, but I struggle to think of changes from Mono to .NET Core which would be threatening to the ability to finish a project.
> At first glance, Unity is so laughably ahead of Godot in sheer number of features supported that it seems comical to compare the two.
> In practice, Unity requires 3rd party tools for tweens, timers, and networking, all of which Godot includes out-of-the-box. Still, I’d argue that it doesn’t actually matter for the vast majority of us indie game developers.
The quoted statement is 100% accurate. Unity is very slow. When I worked on Unity with a larger project, I'd often have to wait 10+ seconds for Unity to rescan the entire project every time I switched windows from my IDE to Unity, or every time I ran the project. In similar project sizes, Godot was always lightning fast.
> Godot looks like Unity from 2008, it's easy to boast efficiency when you have a limited product.
Unity does have more features - like more obscure 3D features - but that has nothing to do with how Unity deems it necessary to rescan the project tree all the time. Also, when I used Unity, I never used these extra features, so even if this were true, how come all users have to pay the price for features that only a few of us will use?
Honestly, core Godot is very full-featured, and in my experience the central abstractions are much better thought out than those in Unity. I feel a lot of the FUD around "Unity has more features than Godot" comes from people that like seeing a long list of features, not from people who actually need those features.
As someone who uses Unity professionally to make a 2D game, here are some key areas I find godot lacking vs unity:
- Scalable text support a la TextMeshPro (sdf-based rendering)
- the in-editor console is horrible. it frequently tells me "output overflow, print less text!". wtf? also, it doesn't let me click on a line to jump to the code
- the built-in tile editor is very painful in my experience. the UI is clunky and it's lacking important features I depend on in Unity, like tile rules.
- the built-in text editor is _very_ basic, and support for external editors is limited vs Unity (and hampered by lack of mature tooling for gdscript vs C#)
- gdscript's heavy reliance on "magic" strings and lack of type-safety throughout
- unity's UI system sucks, but it's still more capable than Godot's especially for things
> Scalable text support a la TextMeshPro (sdf-based rendering)
Agreed, this could be better.
> the in-editor console is horrible. it frequently tells me "output overflow, print less text!". wtf? also, it doesn't let me click on a line to jump to the code
Agreed.
> the built-in tile editor is very painful in my experience.
Agreed, but I hear it's better in 4.0
> the built-in text editor is _very_ basic
Actually, I disagree here. Fuzzy find, quick open, search in files, and autocomplete all work and are blazing fast. It is missing some things like a decent Vim mode, I'll admit. However, I tried both using vscode and the godot text editor, and I found that you saved so much time by not having to jump between IDE and Godot that it actually made up for a few of the more minor deficiencies.
> gdscript's heavy reliance on "magic" strings and lack of type-safety throughout
Agreed, but this improves in 4.0.
> unity's UI system sucks, but it's still more capable than Godot's especially for things
I honestly find Godot's workable enough. With Unity I would get into stupid issues because it was scaled 1000x larger than my game (who in their right mind thought this was a good idea?!?). Also, I remember Unity having 3 different modes for their UI, all of which were confusing and counter intuitive. Godot's UI is simple enough to hack.
Thanks for the detailed reply. I am super excited about 4.0, I eagerly read the alpha update blog posts when they appear in my RSS reader :D
I am probably most excited about the gdscript 2.0 features. As someone who currently maintains a fairly large codebase as a solo developer, I cannot imagine writing that in gdscript. I rely heavily on C#'s type safety and more "industrial strength" tooling — a strong standard library, huge ecosystem of tested open source C# modules (e.g. NuGet), great external IDE support (I use Rider), and a lot of language features like generics and interfaces.
Btw on the UI stuff... I definitely remember being very confused about that when I first got started. Now, I actually do see the benefits of having 3 separate modes — it "does the hard work for you" when you want to put UI in screen space vs world space. But yeah Unity's UI system isn't good... and, like seemingly everything else in Unity's, it's apparently deprecated yet it's proclaimed replacement (UI Toolkit) isn't production-ready. Sigh...
I believe I can address the first two points for you:
> Scalable text support a la TextMeshPro (sdf-based rendering)
Someone in our Discord recently found a way to scale their project UI correctly according to screen DPI, not sure if that solves your problem or not. Their project is also open source: https://github.com/derkork/openscad-graph-editor
> - the in-editor console is horrible. it frequently tells me "output overflow, print less text!". wtf?
> - gdscript's heavy reliance on "magic" strings and lack of type-safety throughout
Yikes. I was like "eh, I could get over that for a good dev framework" until I hit this one. Dealing with that kind of thing is like driving a car with hexagonal wheels.
It's actually not as bad as it sounds. There are generally 2 cases where these come up.
1. As a hack for not having functions as first class objects in GDScript - you'd refer to the function by string name. This definitely felt very hacky, but it's been resolved in 4.0, and now we have first-class functions!
2. For some things that other languages would handle as enums. This is also a problem, but it's not nearly as bad as you'd think, because it's generally fairly readable - stuff roughly like `is_key_down("key_left")` - and because Godot's autocomplete is good enough to suggest only the appropriate strings.
I love working with Godot but I can't help but feel like GDScript is a mistake.
I want better language support and community when working on a project. I want to use nice VSCode plugins that auto format my code (and give type hints... Untyped languages hurt me so much these days)
I can't wait for better C# integration for Godot. It's ok now but I'd love it to be rock solid.
Custom scripting language seems to be a common error - early on Unity emphasized a pseudo-custom scripting language (Boo) over C# and had to slowly extract it out of the product, documentation etc.
It makes sense as a risk management strategy early on in engine development, though, since integrating something like C# can be difficult and they may have been afraid that they would regret building around C# later on.
Normally I'd agree with you, especially as someone that's embedded a scripting language into AAA games, but I think GDScript is the exception to the rule. Or, it's very tightly integrated with the engine's way of handling memory and it feels refreshing compared to a VM that has some bindings to native functions.
On the one hand, Undertale, Spelunky, Hotline Miami and other popular games have been made in GameMaker and GML is much, much worse than GDScript. At the end of the day, the player isn't going to care.
On the other hand, GDScript is not that great a language. No one would use it as a general purpose scripting language outside of Godot, it's like a more awkward wannabe Python without many of Python's useful features, and outright frustrating features like "pass" and funcref and not actually being able to type-hint signals.
To each their own, but I've never enjoyed using GDScript, which is unfortunate because the framework itself is amazing.
Pushing people towards a non-standard scripting language is definitely not a strategy for long-term growth.
It needs a widely-known language with good performance and high quality debugging support (you can use the Visual Studio debugger with Unity C# or UE C++, for example)
> the central abstractions are much better thought out
Totally agree. Godot is the first engine I've ever used where I don't feel like I'm fighting with it the whole time to make it do what I want.
Godot is pretty clearly a solid choice for anyone making 2D games, and will eventually be a fantastic choice once we get a stable Godot 4.0 with .NET 6 and other nice features.
The only real FUD that has any basis is 1) The lack of good 3D support and 2) DOTS style architecture. These are things the community is addressing now for future releases.
I recently tried out unity with this tutorial https://www.youtube.com/watch?v=_Pm16a18zy8 and imported a sprite map. It took like 10 minutes to load. No idea why it takes so long
Yep. Similar numbers of assets, similar sizes of assets, etc. Things that would cause Unity to keel over and die were virtually instantaneous in Godot. I had a project with something like 10k game objects in Godot with no major issues.
Actually, there was one issue where saving was taking like 5 seconds in Godot instead of being instantaneous. I reported it and it was solved in the next point version. https://github.com/godotengine/godot/pull/49570
Hmm, it depends how much you're going to be using the 3D features that Unity provides. If you're going down the big list of Unity 3D features and you're thinking you need a whole bunch of them, then it's possible that Unity would be a time save in the long run. But honestly I like Godot so much that it would take a lot to tip the scales.
I would personally not use Unity at all because I find the developer experience so frustrating. I'd rather spend an extra couple of days enjoyably hacking something together rather than spending less time in more frustrating ways (like waiting for compiles). But I feel I'm more sensitive to these things than most people.
Anecdotally, there's something about Godot's structure that just "clicks" better for me. It's odd because they seem pretty similar on the surface (nested scene graph, nodes with scripts that have hooks, etc), so it's hard to determine what exactly makes it easier to understand.
The only two concrete things I can point to are better documentation (IMO), and the first-class signal/observer support in Godot. I'm not sure if that exists in Unity or not, but it's a really intuitive way to handle entity interaction, and I think that makes it way more easy for beginners to get started.
It is outrageously painful. Half of the craft of working in Unity is knowing which kinds of operations will trigger a 15 minute re-import and basically scheduling your day so that you have other things you can do while that’s happening. It doesn’t happen every day or every time you open a project, but sometimes you’ll be looking at your master branch in git, and then you go to check out a branch where something big has changed, and then you alt-tab back to Unity and… time to go make a fresh pot of coffee.
As someone who did I'd say it's a silly comparison. Godot has a decade of advancements in technology on Unity 2.x, things are generally "nicer" than when Unity started
I switched to Unreal after using Unity for many years, both at my day jobs and as an indie. If I had known what it is actually like to work in Unreal, rather than how the grapevine vaguely typecasts it, I would have switched a long time ago, or more likely never used Unity in the first place. Unreal is a delight.
It's unfortunate that Epic ever let Unity persuade people that it's better suited to anything or anyone at all.
It's very true; I remember one game I was working on, when you pulled down the code and new assets it'd take a long time to rebuild the "Library" (which is not something you can check in). And sometimes, if your version of the project was acting wonky and everyone else was fine, the solution was to delete the Library and rebuild it from scratch. If you were doing it from scratch, it could take hours. They've made some improvements but it's still a mess.
The editor itself always seems very buggy. If you have the "Console" open (which you will if you're coding), it's pretty much guaranteed you're going to see a lot of random errors that have nothing to do with even your code. A lot of them don't even make sense or could be ignored. Like you'll get weird asset import errors if you upgrade versions, but a lot of times they're just red herrings and not important. There's also a lot of QOL stuff that's very frustrating, like arrays being annoying to edit (I'm not sure if they've fixed this yet or not). It's also easy to accidentally brick your editor on your own, with debugger shenanigans or loops that don't end.
Also, if you're trying to build a an editor extension, omg was that a nightmare. Just getting things like Undo/Redo and object serialization working correctly are difficult and in some cases impossible. And frankly, you need extensions for a lot of things to actually be useful, like until recently the builtin terrain editor was basically useless, and you have things like Odin because the builtin inspector is a nightmare.
There's a lot to like about Unity, but there's also a huge amount of pain points with it.
This seems to be a cyclical thing. Every now and then a new solution shows up that is built on new development and UX practices, abandons some baggage that is no longer relevant to most users, makes assumptions in its design that are better suited to the era, etc etc.
Then ten or twenty years pass and it becomes the thing to replace.
I'd say that yes, at least in the last 5 or so years.
I decided to make a scene which would contain a single copy of every single model that I'd like to use in a project of mine, for checking the textures, how lighting works, the scale of everything etc.
By the time I got to around 200 different objects (no high poly ones, by the way), it took like a minute to just open that scene.
I’m in the midst of making a 2d game in monogame and was toying with switching to Unity, thanks for sharing this. Man I wish I could find some resources on how to do 2d shaders in monogame though, like making sprites wave in the wind/water without needing a ton of sprite frames, hard to find this kind of thing.
People are overreacting to Unity's acquisition (technically a merger) of ironSource and Riccitiello's comments on monetization. Many developers want to make money from their games, so I think it's positive and worthwhile for Unity to give them tools to do that. As for Unity's market cap, the market as a whole has taken a beating over the past few months. As someone who works with Unity and sees the enormous value it provides, it just strikes me as a great time to buy their stock while it's low.
Ironsource is a malware vendor. I'm not sure in what sense you think people are overreacting, but I think that fact alone is worthy of a raised eyebrow or two. Unity has merged with a malware vendor.
I tend to agree, but I do really worry about Unity's technical roadmap. There are so many half-baked systems that rarely get updates, 3 confusing choices of render pipeline, and there's not robust well-utilized implementations of common gameplay elements like Unreal has.
Excited to try Godot in a couple of years when it's more mature. Hopefully they can be the Blender of game engines – where it started rough and now is better than Maya or other alternatives.
Do you have an actual specific disagreement with c# or are you just venting because you are not familiar with the language?
C# is a robust language with a lot of features like lambdas pattern matching etc. I also find that most of the people who know Swift are Apple developers, so I feel like there isn't a broad enough appeal especially for game devs who are going to be more Windows or Linux centric.
Yes, I know C# reasonably well. I use it in Unity for game development, where it is the only option.
C# is better than many alternatives, but Swift is simply a better language in every regard.
C#'s GC is a constant issue for games, and it makes using things like LINQ nearly impossible since it does so much allocation. Swift is designed around automatic reference counting instead. C#'s structs work weirdly and are hard to use.
Swift is so much more ergonomic. C# has added a few nice things lately, but it's much more verbose than Swift.
Swift is also more focused on performance, and is always AOT compiled.
My experience with C# has mostly been working on a personal project WinUI desktop app, and my biggest peeve has been reaching for something I use regularly in other languages only to find that it doesn't exist, and the solutions offered up by googling are usually, "well you can write your own implementation", "[huge utility library] offers that", or "don't do that it's not idiomatic/performant/etc". While none of those are showstoppers they slow development down and act as a source of frustration.
@jayd16 No, they have dropped the Mono runtime for many cases (which causes some of the problems). The language itself is simply much less pleasurable to program in than Swift, and performs worse in key areas.
I can't speak for the grandparent, but using C# in Unity, the garbage collector is always at the front of mind and dissuades people from using some of the nicer features of C# (LINQ, etc.). Granted my knowledge of this is a couple years old, so maybe the situation has improved, but I'm guessing most Unity developers are still very careful about how they write loops and how/when objects are allocated and all that stuff. Automatic memory management can be more of a hindrance than a benefit if you have to babysit it to avoid GC pauses.
C# needs a fat runtime, has a slow JIT (say hi to micro stutters in your gameplay and increased input latency), has a slow GC and worst of all is owned by Microsoft with a proprietary debugger that you can only use on visual studio (licence they changed overnight because Jetbrains released a C# IDE)
There are much better languages for game scripting (LUA for example)
C# is really well suited to the task thanks to value types and structs, that gives you back control of memory that is lost in Java for example. It also has a lot of syntax sugar to avoid being too verbose and the memory safety and GC are desirable most of the time and can be avoided with well known tricks, like object pools, when performance needs are more paramount.
I don't know Swift very well, but I seem to recall the creator talking about using automatic reference counting instead of garbage collection as an intentional tradeoff. If that's still the case, I'd much rather use Swift over C# in a game (and I am using C# in a game!). The value types and structs are very limited compared to classes and reference types.
Yes ARC is definitely an intentional and well-chosen tradeoff. Swift has real first-class value types (strings, collections, etc are all value types) and copy-on-write semantics that make it all work quite well. C# value types feel like they are funkily bolted on and aren't really very useful in practice (at least in Unity).
Swift is entirely designed around value types and structs, and has a much more predictable ARC model instead of GC for game programming. Plus, an upcoming feature will add Rust-style lifetimes for more control (https://github.com/apple/swift/blob/main/docs/OwnershipManif...).
Godot's default language is GDscript, which is similar to Python. I'd highly recommend that to new people switching to Godot. I think C# is just cruft for people coming from Unity and stuck in old habits/frameworks.
I tried GDScript and hated it, ended up manually porting what I wrote to C#. GDScript currently only has partial support for static typing, which makes things a much bigger pain in the ass. Using C# was a breath of fresh air after that.
Yeah, I don't want a weird scripting language like Unreal Blueprint or GDScript or Lua. C# beats all of those by a mile. I want a robust, ergonomic, high-performance, compiled language like Swift.
C# isn't the worst but out of the newer languages I've tried it's probably the one I'm least excited to write. Swift or Kotlin would definitely be preferred.
You obviously know this since you linked a Swift bindings project, but for others reading who may not be aware: Godot officially supports multiple languages ("GDScript, C#, VisualScript, and C++ and C via its GDNative technology"[1]), but other languages are supported by the community.
I’ve actually read so many good things about C# lately here and on Reddit that I plan to start learning it in the coming weeks (other reasons include .Net and F# being an adjacent language)
C# hasn't been an issue for me at all bar a few oddities. Some things not working properly in C# (think some plugins or something back a while ago). Some code not directly mapping from GDScript to C#, causing huge object count issues. For reference, I've been using it since 3.1 in a hobby context.
Really, it's not the developers you have to worry about. It's everyone else. Godot is made with developers in mind, but there's much more to do than wiring signals and writing code. If you can't map things one to one from a different program or close to that through a plugin, you're either giving yourself more work, or forcing not just developers, but artists to relearn processes too.
> If you can't map things one to one from a different program or close to that through a plugin
I've only used Godot in a hobby context, but the full on C# support compared to other engines is pretty amazing. Just as a proof of concept I imported an open source C# library I've worked on that's designed to play old DOS music formats, created a small wrapper node with control functions, and I was able to control it as expected from within GDScript nodes right out of the box. Only issue I would have seen down the road would be cross-platform compatibility since the library itself was Windows only.
Caveat: I can't say I've ever got far enough in Unity to say if the C# support is of a similar scope. Godot just "clicks" better for me, so I've gotten way farther with it than anything I've done in Unity.
Yeah, that works well. Most libraries do work depending on target platform. With C#, you can write your entire logic outside Godot and just use Godot as a graphical interface if you so desire.
But that's the point. We're discussing things from a developer point of view. This happens almost every day by now. That's not the issue. The issue is how everyone else struggles with Godot compared to Unity, if at all. When even basic particle patterns require diving into shader logic in 3.4 or loads of trial and error, that's a pretty hard sell for non-technical people.
I'm so happy that I saw this coming and have been head first in master branch in order to be ahead of the curve. I have lots of things to learn still in 4 but I see clean piplines using latest formats like dynamic gltf in scene reload, meaning direct blender(et al)-godot pipelines. Global illum is so off the charts pretty. Perf is a pain point but when you start using multimeshinstances things make more sense. Updates sometimes corrupt scenes, keep your source of truth models in gltf 2. Shader language wizards are the future. Vulkan is the coolest thing since sliced bread.
Context: My game project has been going since 2013, on godot since 2018.
Seriously curious to those in the gamedev community: how does Unity acquiring an ad company materially effect the feature set and platform that Unity currently provides? Is it one of those "Unity has been going downhill in slow-mo for years now and this investment is proof that they aren't interested in fixing real issues that indie devs have--writing's on the wall..." type of thing? From the outside, just seems like business as usual to me... I genuinely don't understand the pull people feel to entirely retool simply because Unity wants to do ads better. What am I missing?
As a dev that uses Unity on a daily basis, here is my perspective.
If this was simply a matter of "Unity wants to do ads better" and they purchased an adtech company, I doubt there would be much discussion about it. That is not what happened. ironSource is not just an adtech company but a company that has built and distributed software that has been classified as malware by Sophos and Microsoft Essentials[1].
While this may be an overdramatic take, once ironSource is fully integrated with Unity and we update to the latest LTS version that includes ironSource software, I expect that we will want to virus scan our own executables built through Unity. I do not trust ironSource nor do I trust any software that integrates with it.
Now, putting the malware concern aside, I also see this as a step in the wrong direction for Unity. There are MANY uses for Unity that are not games, that will never have ads, and that will never utilize anything from this acquisition. The concern here is that recent updates of Unity have made some of these features such that you cannot disable them.
To me, this is yet another poor decision by the Unity team. As an aside, I recently started looking into their freshly released new Analytics platform and it is an absolute mess of a release. There are massive oversights in the implementation and bugs that prevent workarounds to those oversights.
Unity is not looking like software worth betting your company's future on. At best, it is looking more like prototyping software before using a better engine.
As someone who has a mortgage and children to feed ... Unity acquiring an ad company is encouraging. For years now Unity seemed to be lost and directionless; having them merge with an ad company shows that they're serious about focusing on creating a product that will help developers turn a profit.
But you won't hear many "indie" developers say as much, because making money is uncool.
That said, IronSource is sketchy as hell. I'm more concerned about _who_ they merged with then that it was an ad company.
I was really tempted to try out the c# support but I opted first for the rust godot bindings and then the nim bindings. Nim is working fantastically. I was a bit worried because the bindings are not really actively developed but from my experience so far I think they just don't need much work.
2 - On glibc/linux target: it should generate pure and simple ELF binaries (not C/c++ binaries). It has the following implications:
a - the static libstdc++ from gcc probably has to be forked that to "libdl" everything it needs from the glibc/posix libs.
b - everything else from the system has to be libdl-ed too, even the libc symbols.
c - third party libs must be libdl-ized too.
d - ofc, usage of "-static-libgcc" and "-static-libstdc++" build options to mitigate ABI issues (got hit again by that and recently, c++ ABI nightmare).
e - no C/c++ main() function, only the sysv ABI(ELF) entry point (which is basically main anyway).
f - usage of system TLS variable, like errno, must be handled only via the sysv ABI __tls_get_addr() ABI function (I have to admit, I did not dive that much into this issue yet).
g - proton is a money sink hole, massive and horrible software microsoft grade. To make it worse, it is said to include actual real software components from doz. Only consider it if your technical debt on doz OSes is too high (basically, you started to "think" "other platform ports" too late).
If not mitigating those issues above: games using godot must be build on the oldest glibc as possible, that to avoid GNU symbol versioning issues. They should static link as much as the can, even some glibc libs (libm static linking is mandatory since GNU symbol versions here are madness). And conservatively build using the "-static-libgcc" "-static-libstdc++" options.
rant on: Godot should not have been a c++ engine but a simple C/ASM one (should be able to compile with tcc/cproc/scc/pcc/etc), using the preprocessor for namespaces in order to avoid symbol collision, and using compile-time function tables and runtime function tables (for "fallbacks", like wayland->x11).
The really guilty ppl are actually glibc and gcc devs, not the game devs.
rant off.
Godot is a joy to use on its own, but when you also consider how it's licensed and doesn't require some awful launcher, it starts to feel like a breath of fresh air.
Any time a company tries to make me feel like I'm at work, I stop wanting to make games with their product.
Godot is really great, and the GDScript is something you don't really need to "learn". It feels intuitive and easy enough to be productive from day one. The performance, compilation speed, binary build - very quick. If was I writing a "game engine" that probably the system I would've come up with. The GUI feels flawless, responsive, very easy to work with. Online/offline help/documentation
is top notch.
Would I use it if I am serious about gamedev as a job? Probably not. Version 4 is supposed to bring a lot of improvements and this is awesome. I am not sure I would invest into building a product in version 3 (as it will be deprecated if not by its team then by the plugin makers). Version 4 is not ready yet and specifically mentions to have "tons of bugs" once it's out. As a hobby game developer this is an truly great product to work with. I started with a few 2d tutorials and probably after a week felt really productive. Also it feels like 1st class citizen on Linux (tbh Ubuntu also made great progress here).
The only really thing missing for me - in order to use my C++ simulation engine I need to re-compile C++ Godot sources along with my code? A bit too much for me at this stage. But didn't investigate it enough if there is an easier solution (version 4 is supposed to give more options). Using C# is as an option too. But they mention C# in terms of "support" is "secondary" whatever this means - without more experience it is hard to understand the implications.
Unity is too mature and skills are there if you need to hire or outsource. Mobile publishers, for example (from what I've seen) only accept unity games. You can buy great plugins/assets for reasonable amount of money. Obviously with the money they have it is the product you want to base your business on if you develop professionally. If anything Unity should be compared to Unreal engine, not Godot from the perspective of developing professionally.
Anyways it is really great to see an OSS product that is so close to the mature big commercial products that people have these discussions, run benchmarks and seriously consider switching to Godot. The quality of effort and skill I've seen people put into Godot development (and its plugins) is something unreal and too awesome be true. Go Go Godot!!!
Hopefully the async/await story gets fleshed out. Unity just made the default scheduler run on the main thread. That's pretty much all it takes but it would be nice if it was built in.
And formerly Paradox, if I'm not mistaken. It's one of the worst marketed game engines I have seen. Two rebrandings and practically zero social media presence. People are still starting more new projects with XNA than with Stride.
I would be promising asset compatibility with Unity and shouting about that everywhere if I were Stride.
Maybe it's because writing C# in Unity is really just using the Unity SDK and not writing actual C# code, but I wouldn't want to hop over to Godot just because it supports C#, as learning it was born out of necessity and was never an enjoyable experience. I'd be much more interested in their GodotScript or plugins for other languages I'm familiar in.
What if I want to create my own Roblox, how would I do that here? Is there a 3d engine/game engine where I can tweak the editor and distribute to my end users?
The point is so that I can lean on the community to create the content and I would just focus on maintaining game servers, and adding moderators.
The new MultiplayerSynchronizer and MultiplayerSpawner nodes in Godot 4 (still in alpha, beta soon) make life so much easier. I'm going to be submitting a demo for using them hopefully next week - but generally you just check some boxes for properties to be synced at spawn or continuously and set the network authority for each of them (aka Player 2 is master of his object, but Player 1 is master of the rest of the world) and it does the rest.
> Using async and await with C#’s Task can be a bit of a headache with Godot, especially if you don’t realize that that most ways of executing an async Task in C# starts a new thread (or recycles one from the task thread pool).
I use it on macOS and Windows, and it is lovely! I even have Steamworks.NET integrations working on both platforms with it. It can be a bit tricky to setup the `.csproj` correctly to resolve native dependencies, but not anything impossible.
If you don't mind me tooting my own horn too much, I have some docs about project setup in the readme for a test framework I made for C# Godot games. It has some notes about mac-specific things, since that's my primary machine. https://github.com/chickensoft-games/go_dot_test
You can also look at the way that project itself is setup, and the `.csproj` files. If you need more help, feel free to join our Discord (link in the blog)!
> Godot doesn’t fight you when you’re building scenes. Making a scene feels a lot like creating a class using composition, and scenes can even inherit from other scenes (using another scene as the the root node of a scene allows you to inherit from it and override its properties in the editor and in code), allowing you to express patterns you’re intimately familiar with from object-oriented programming.
I personally find the approach of nodes everywhere a bit odd.
In my mind, you'd typically use nodes for objects that are supposed to represent some sort of an object or concept within the scene, whereas the scripts would be the ones that actually give said object any number of behaviors, such as a certain group of functionality per script.
It kind of feels like it would be nicer to be able to attach a number of scripts to the object that I actually want to control, instead of having Nodes that I don't really see much of a use for, apart from them being script containers.
Of course, maybe that's just because I'm used to the GameObject pattern that Unity uses, an entity-component system (of sorts), though that implementation has gotten a bunch of critique as well, with DOTS apparently being a better ECS approach, though also unfinished in certain aspects.
Just felt like sharing my thoughts on that particular aspect, which some might find curious and which might take a bit of getting used to (though personally not having a separate "prefab" concept and instead having more or less everything be a node is also pretty freeing, I have to say).
With a bit of love, using C# could also be pretty amazing, since GDScript does have certain limitations (performance comes to mind, for when you need it to be decent for number crunching but don't want to/can't use C++ due to knowledge or other restrictions, C# has your back there) and curious design choices (the integration with the engine is super nice and the Python like syntax is great, but having to define singletons in the editor IIRC is a bit silly https://docs.godotengine.org/en/stable/tutorials/scripting/s...).
No, not at all. It unsurprising that an open source project has positive mindshare. I just think that the spree of articles, all with the same anti-Unity bent, being posted within hours of each other isn't a coincidence.
That doesn't mean people don't genuinely like Godot, just that it looks as if someone has an agenda to make sure that's the case.
Apart from one repost of this article, search tells me there have been five Godot articles in the last month, none of which have had anything that looks like an "anti-Unity bent," and no others were posted on the same day. The only ones that got any traction (besides this one) were about fog volumes and UI design.
I think maybe you're conflating pro-Godot comments in recent threads in reaction to news about Unity with articles being posted and seeing a hidden agenda that isn't there.
They don't allow re-selling the engine or editor, that's why.
Technically it doesn't meet the open source definition because open source should allow people to commercialize the source code. Defold allows you to see the source, modify it, and make contributions, but even those modifications cannot be commercialized.
You are free to use it to make paid games, or make and sell plugins, etc.
Riccitiello: Ferrari and some of the other high-end car manufacturers still use clay and carving knives. It’s a very small portion of the gaming industry that works that way, and some of these people are my favourite people in the world to fight with – they’re the most beautiful and pure, brilliant people. They’re also some of the biggest fucking idiots.
To be fair, the full comment is even more belittling than the sound bite. It’s almost dripping with contempt for those who have a different set of values than him.
It's ironic you say that because as someone who arguably fits in the category he's talking about (see: my bleeding heart comments about Unity's for-profit asset store from yesterday) it feels somewhere between belittling and insulting for people to act like grown adults would really miss what his point was.
There seems to be this "rainman-esque" infantilization of people who put craft before profit that I truly deeply hate. He spoke like he was having a frank, open, conversation. That relies on everyone involved being somewhat mature and not jumping to the worst possible interpretation of everything.
But I don't know, maybe people are right to treat "the creatives" with the kiddie gloves based on the reaction I've seen.
I'd love an alternative for 2D games to Unity but I haven't found one that has the breadth of features as well as demonstrated high quality games. It doesn't help that Godot fans constantly push their engine-of-choice every chance they get. We get it, you're excited... Show, don't tell. Build super high quality stuff and prove it's time to stop waiting.
[0] https://news.ycombinator.com/item?id=32003065
[1] https://news.ycombinator.com/item?id=32081051