Godot Engine Awarded $50k by Mozilla Open Source Support Program
godotengine.org
godotengine.org
Interesting that Phaser was also a recent recipient of a Mozilla grant. Even though it targets a completely different developer audience, it's cool to see Mozilla take game making seriously.
I've played with Unity and Unreal a bit, each with their own pros and cons, but for me Godot is the one I found most intuitive and easy to test new ideas with. Worth checking out.
I agree with the comparison to GML, but whether one finds Gdscript intuitive depends on one's existing background. I personally found it frustrating because I was used to C/C++, but with time I can see getting used to it. It's not a bad language by any means.
Also, both Game Maker and Godot share the problem of their scripting language being essentially a form of lock-in, since no one is going to use Gdscript anywhere else, and any code you write it in is no longer portable. Also, they use their own shader script rather than GLSL, which means your shaders aren't portable either.
Godot can support different languages (unlike Unity or Game Maker), but IIRC that requires recompiling the engine and may break the editor.
- GDScript : included by default
- C# : you have to download the Mono version of Godot (and install the Mono SDK)
- Any other language (Rust, Python, C++, D, etc...) : using GDNative
(- And of course you can also directly modify the engine source code in C++ if you need super low level modifications (like writing your own render engine))
>Finally, one of our brightest additions for the 3.0 release: GDNative allows scripting in C++ without needing to recompile (or even restart) Godot.
https://docs.godotengine.org/en/3.1/getting_started/step_by_...
Personally i've been using this for godot:
https://github.com/GodotNativeTools/godot-d
It's been working well for me.
I compile my code and include it as an .so in my project. No recompiling the editor.
If your game has more than trivial amount of UI, particle-systems, 3D, etc then it becomes very time consuming. To write and tweak a full blown responsive UI like in-game windows, alerts, animations etc with code-only is not trivial. With a full-featured editor like Unity and Godot, UI, particles, tweened-animations and such becomes much easier as you can keep interactively tweak things around until its perfect without the edit-code & recompile cycle.
There's also King's "Defold" engine which uses Lua and has a visual editor but the last time I used it over a year ago, I found there was almost no in-game UI libraries so although making the prototype was fun and relatively easy adding UI became difficult.
Do you only use it for quick prototyping of ideas and then move over to a different engine if you like the idea and want to expand?
I imagine the answer could come down to the scope of the game.
Every time I go and have a play with Godot my mind is blown that the whole program is a single ~45MB executable.
I think the biggest blocker for wider adoption is 3D performance and Inverse Kinematics now. Without it, nobody will ever produce high profile game on Godot.
With Unity you have many features, a big asset store that allows you to very quickly prototype, the render engine is powerful, but the architecture & organization is just a massive mess. It's really the kind of editor were you can do everything because the dev added all the popular shiny features to make fancy trailers but nothing is planned & well organized, all features are just put one of top of another with no coherence.
Not only the the architecture feels complicated but the editor itself is super heavy : mandatory Email & account, installation size of several GBs, etc.
Godot has less tools and the asset store has almost nothing on it right now. The current render engine is not powerful but it is temporary, everything will get re-written with Vulkan to be on par with other engines.
While it has not as many features as Unity, the foundations of Godot are really solid & clean, I think this will be a huge advantage on the long term
That sounds very ambitious, UI and UX wise. Wonder how that will turn out in practice
However, the arguments against bgfx seem to amount to "I want to do it myself", a classic "not invented here" issue.
EDIT: found this too https://godotengine.org/article/godot-3-renderer-design-expl...
> Added to that fact, Vulkan still has years to go until it's properly supported in most desktop and mobile platforms, which makes it unattractive to implement for us (as it means considerably more effort to write, debug and maintain).
And then they're talking about the Vulkan PI in TFA which probably won't be ready for some time too...
If you need something from the library that it doesn't have you will either implement it yourself, create a PR, wait for it to be merged or work around it (which defeats the purpose of using a library).
I disagree. It has been 9 months since that post. bgfx still does not list support for Vulkan. They already implemented DX12 and Metal. They still claim support for Windows XP and Vista. Godot says it will get Vulkan support in 3.2 which comes out in a few months. Otherwise they would have to wait and work on bgfx to get it working. DX9, XP, Vista, feels like a lot of baggage for what Godot is right now. A very quick and easy to use game editor that easily deploys on both Win and Linux.
Also, your edit links to a pretty outdated article (2017).
See Godot's about face on Vulkan here:
https://godotengine.org/article/abandoning-gles3-vulkan-and-...
> Vulkan was always a tempting alternative to solve them and to ensure we are much safer from driver bugs (after all, this is what the API was intended for). Still, the lack of support on macOS made it unappealing. Having to write a Metal backend to support this OS is a lot of effort for a platform not used very much.
> in a completely unexpected turn of events, it seems Valve has found an arrangement with the developers of MoltenVK (the commercial and proprietary Vulkan over Metal wrapper), ported Dota 2 to it, and got it open sourced.
> It seems to be a mostly complete Vulkan implementation that runs on macOS and iOS. This pretty much lifts the only barrier we had for moving Godot to it.
Congrats to the team!
https://godotengine.org/article/godot-32-will-get-new-audio-... (at the bottom)
In the post I previously linked he said he expected the port to take a "couple of months", so we could expect it in any release made in the 3rd or 4th quarter this year, maybe as early as July?