Godot is only the best open source engine because Bevy is not ready for production, Lumberyard/O3DE is hard to set up and everything else is ancient or 2D only. one eyed man among the blind type shit
> Godot is only the best open source engine because Bevy is not ready for production
I would argue that even if Bevy was ready for production it would not really compete with Godot.
Godot's performance is plenty for the vast majority of small to medium games. Plus they're starting to work on features like texture streaming for bigger games. It also has an editor which is a big plus for most teams.
Bevy would be objectively better for expensive CPU simulation stuff but realistically what percentage of games need that? Maybe 1%?
For Bevy to catch up on the indie game scene it needs an editor plus a scripting language and/or something like Unreal Blueprints. If it only wants to target the hardcore Rust dev that does everything by code it will never go mainstream.
No. If you try Bevy, it feels different from ECS and ordinary OOP. So it's hard to get used to. But Godot, although GDScript has performance issues, if you use GDScript it's easy to port to mobile and web games, and the syntax itself is OOP, so it's easy to adapt to.
A lot of people complain about OOP, but it's a paradigm very well suited for rapid development.
Godot is the best open source engine because it is dead simple to use, comes bundled with its own IDE and documentation, the editor runs on any platform that Godot runs (including the web) and the performance benefits for something like Bevy only apply to a handful of games that really need it.
Godot gives GDScript simplicity for the vast majority of use cases which is that iteration boon, provides C# for games that need the additional guardrails. For performance critical game scripts you can just jump to C++, Rust, Swift, etc.
But most game scripts are not performance critical. Clair Obscur: Expedition 33 swept the game awards last year as an Unreal Engine game made using almost entirely visual scripting (blueprints).
It still bothers me that game engines come with their own bespoke languages like GDScript. Godot is a bit better than others for having C# support and forks in other languages but really no other language will ever be as integrated with the framework as GDScript, And GDScript is never going to be a general purpose programming language, and that necessarily creates lock-in.
I'm currently messing with some old projects written in Game Maker 5 and let me tell you it would be so much easier if I didn't have to do internet archaeology just to figure out how GML worked 20 years ago.
Because it is much easier to have a custom language, than try to subsetting an existing mainstream language, while having to deal with all the mess of people trying to use random stuff on the engine, that naturally isn't supported.
Example, see all the bad rep .NET and C# get from devs that only know them from Unity, full of legacy stuff and restrictions, instead of using the real product.
That seems like more of a feature than a bug to me. Using C# in Godot means you have all of the Nuget libraries at your disposal, whereas no one is writing libraries in GDScript, because no one is using it outside of Godot.
Meanwhile to extend Godot usefully you have to use C++ and a plugin API that's arguably no less complicated than adapting an existing language as the scripting language would have been.
But that is the thing, you don't have access to all the NuGet libraries, or even CLR/MSIL abilities, it is a hit and miss depending on what platforms are being targeted.
Sure if you only want to target desktop/laptop computers, you're safe.
I always do not understand why defold is never put into the fold [sic!] of those sentiments/discussions.
You can learn a clean & fun language (lua) and its JIT is maybe/probably running laps around something like GDScript, which in itself is proprietary and has no other uses for you than, ehh, Godot??
You can integrate C/C++ extensions natively, neatly exposing them through lua APIs.
Its mobile and web target footprint is unbeatably (?) small, desktop at least 10x smaller than Godot or Unity.
It is Open Source.
Maybe it's the "ancient" part, because more recent is always better ;)
Starting with absolutely nothing but a compiler is always going to be a worse experience (and less likely to result in anything released) than a GUI-driven and aided solution. If Defold developers had produced a fraction of the libraries that Godot has, it might have had a chance. As of now, it's worse than other abandoned engines like Solar2D (was CoronaSDK) for people entering the space. As most people know, the vast majority of games are net-losses, so engines live and die by the ease of adoption by newcomers.
> Starting with absolutely nothing but a compiler
I don't understand what you mean by this -- Defold has a graphical editor?
> If Defold developers had produced a fraction of the libraries that Godot has, it might have had a chance.
What do you mean by libraries in this context? It has a robust plugin system with a reasonably active ecosystem, if that's the sort of thing you're talking about: <a href="https://defold.com/assets/" rel="nofollow">https://defold.com/assets/
And it covers all the systems one would expect in a 2D game engine natively -- tilemaps, physics etc.
> As of now, it's worse than other abandoned engines like Solar2D (was CoronaSDK) for people entering the space.
I definitely disagree with this -- it's certainly not abandoned, and though it does have a slightly steeper learning curve than Godot or other popular engines, that's also how it gets such impressive performance and slim builds; feature, not a bug.
Good news, they've been working on adding C# support for a year or two now. I think it's still experimental, but from what I understand they already had a robust extension system that supported C/C++/Java/etc., so fitting C# in wasn't much of a stretch.
(it is only extension support -- not scripting -- but the extension system is such that it can be used for any game logic AFAIK)
voodooEntity · · focus · HN ↗
Than started to move alot of heavy logic to c++ simulation : tedious indeed but the results speak for themself.
Basically allows me to use godot for things like menus dialogues and similar stuff while running the true heavy work in a c++ simulation.
momocowcow · · focus · HN ↗
the hierarchy and physics api isn’t great either, it’s easy to hit heap allocs even from a gdextension
a lot of things wrong with this generic engine, but at least it’s lightweight
tancop · · focus · HN ↗
stackghost · · focus · HN ↗
pier25 · · focus · HN ↗
I would argue that even if Bevy was ready for production it would not really compete with Godot.
Godot's performance is plenty for the vast majority of small to medium games. Plus they're starting to work on features like texture streaming for bigger games. It also has an editor which is a big plus for most teams.
Bevy would be objectively better for expensive CPU simulation stuff but realistically what percentage of games need that? Maybe 1%?
For Bevy to catch up on the indie game scene it needs an editor plus a scripting language and/or something like Unreal Blueprints. If it only wants to target the hardcore Rust dev that does everything by code it will never go mainstream.
jdw64 · · focus · HN ↗
A lot of people complain about OOP, but it's a paradigm very well suited for rapid development.
pjmlp · · focus · HN ↗
tapoxi · · focus · HN ↗
Godot gives GDScript simplicity for the vast majority of use cases which is that iteration boon, provides C# for games that need the additional guardrails. For performance critical game scripts you can just jump to C++, Rust, Swift, etc.
But most game scripts are not performance critical. Clair Obscur: Expedition 33 swept the game awards last year as an Unreal Engine game made using almost entirely visual scripting (blueprints).
pjmlp · · focus · HN ↗
krapp · · focus · HN ↗
I'm currently messing with some old projects written in Game Maker 5 and let me tell you it would be so much easier if I didn't have to do internet archaeology just to figure out how GML worked 20 years ago.
pjmlp · · focus · HN ↗
Example, see all the bad rep .NET and C# get from devs that only know them from Unity, full of legacy stuff and restrictions, instead of using the real product.
krapp · · focus · HN ↗
Meanwhile to extend Godot usefully you have to use C++ and a plugin API that's arguably no less complicated than adapting an existing language as the scripting language would have been.
pjmlp · · focus · HN ↗
Sure if you only want to target desktop/laptop computers, you're safe.
subhero · · focus · HN ↗
Maybe it's the "ancient" part, because more recent is always better ;)
valorzard · · focus · HN ↗
Supermancho · · focus · HN ↗
Starting with absolutely nothing but a compiler is always going to be a worse experience (and less likely to result in anything released) than a GUI-driven and aided solution. If Defold developers had produced a fraction of the libraries that Godot has, it might have had a chance. As of now, it's worse than other abandoned engines like Solar2D (was CoronaSDK) for people entering the space. As most people know, the vast majority of games are net-losses, so engines live and die by the ease of adoption by newcomers.
ksymph · · focus · HN ↗
I don't understand what you mean by this -- Defold has a graphical editor?
> If Defold developers had produced a fraction of the libraries that Godot has, it might have had a chance.
What do you mean by libraries in this context? It has a robust plugin system with a reasonably active ecosystem, if that's the sort of thing you're talking about: <a href="https://defold.com/assets/" rel="nofollow">https://defold.com/assets/
And it covers all the systems one would expect in a 2D game engine natively -- tilemaps, physics etc.
> As of now, it's worse than other abandoned engines like Solar2D (was CoronaSDK) for people entering the space.
I definitely disagree with this -- it's certainly not abandoned, and though it does have a slightly steeper learning curve than Godot or other popular engines, that's also how it gets such impressive performance and slim builds; feature, not a bug.
[deleted] · · focus · HN ↗
[deleted]
vor_ · · focus · HN ↗
ksymph · · focus · HN ↗
(it is only extension support -- not scripting -- but the extension system is such that it can be used for any game logic AFAIK)