Hacker News new | past | comments | ask | show | jobs | submit login
Godot Engine Awarded $50k by Mozilla Open Source Support Program (godotengine.org)
335 points by wyldfire on Apr 11, 2019 | hide | past | web | favorite | 43 comments

This is heartening news especially in the wake of the licensing that Unity and Unreal have rolled out in recent years. Sure, the terms aren't too onerous, but it's always great to have at least one truly open source foundation in your corner.

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.

If you want to dabble with prototyping games, Godot is the way to go in my opinion.

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.

What are your thoughts on Lua Love [1] ? I have done some Unity, Unreal, Pygame, Processing, etc. And Love has always had the shortest time from idea to running sketch.

[1] https://love2d.org/

I've found Lua engines like Love to be great for prototypes and gamejams but when it comes to implementing a full game its not as good as the full blown engines like Unity/Godot.

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.

I've always thought Love looked good, but I've never tried it myself.

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.

It is more for quick sketches that are interactive, or designing animation that would be too difficult in Blender or After Effects. While folks do make full blown games with it, for me it is more of a interactive animation workbench.

Thanks for the tip. Did you have a chance to compare with gamemaker?

Godot doesn't enforce any structure like game maker does. Additionally Godots default language (Gdscript) is awesome and intuitive, whereas gml doesn't really feel like a real language (argument0-15. Come on)

>Additionally Godots default language (Gdscript) is awesome and intuitive, whereas gml doesn't really feel like a real language (argument0-15. Come on)

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.

from Godot's documentation:

>Finally, one of our brightest additions for the 3.0 release: GDNative allows scripting in C++ without needing to recompile (or even restart) Godot.


Given that Unreal only now added such support via https://molecular-matters.com/products_livepp.html partnership, I wonder how Godot is actually doing it.

Well... scratch one complaint, then.

>Godot can support different languages (unlike Unity or Game Maker), but IIRC that requires recompiling the engine and may break the editor.

Personally i've been using this for godot:


It's been working well for me.

I compile my code and include it as an .so in my project. No recompiling the editor.

Godot has three kind of languages integration :

- 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))

<not the original commenter> It's a bit more advanced and complex then gamemaker - when I used it a few years ago a more direct comparison would have been a 2d specialist Unity (although it does 3d as well, and this may have significantly advanced since I last used it)

I did some youtube tutorials on it and also have a repo with a dictionary if you want to start translating some of your knowledge https://github.com/coppolaemilio/gamemaker-godot-dictionary

I have used both. You can easily prototype games with either, but Gamemaker becomes more difficult as the game scales up. Both use proprietary languages, but you can go around that in Godot with a little know-how. Also, Godot does 3D, its UI is a bit cleaner, it’s free and runs on Linux.

Nice one! Such a great project.

Every time I go and have a play with Godot my mind is blown that the whole program is a single ~45MB executable.

Godot approach to game development with nodes is superior to other solutions IMO.

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.

Yes, if you come from Unity like me you will find Godot amazingly intuitive and clean compared to Unity. No more weird workflow, no more prefab. Just nodes in a tree and scenes.

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

Isn’t there IK now? I’ve used it on 2D skeletons in Godot.


Yup, most gamedev will talk about performance as a reason to prefer Unity, when asked about Unity vs Godot.

> The WP also includes work to make the editor work on mobile browsers, such as touch screen gestures, responsive UI, etc. This should also make it possible for us to port the editor to Android and iOS natively to tweak your projects on the go.

That sounds very ambitious, UI and UX wise. Wonder how that will turn out in practice

Used Godot 3.1 for a game project recently, really surprised at how good it is.

FWIW, there's a semi-official Godot-SpatialOS integration by an Improbable engineer: https://improbable.io/blog/godot-spatialos-and-engine-integr...

So happy for these guys. Met them at GDC 2019 and their project is wondeba!

I was thinking "why not use bgfx?", thankfully it's already been discussed: https://github.com/godotengine/godot/issues/19602

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...

> However, the arguments against bgfx seem to amount to "I want to do it myself", a classic "not invented here" issue.

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:


> 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.

It maybe reasonable at first glance, but when you start using a library you will hit a roadblock eventually especially if you are working on the lower-level things.

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).

So much of a game engine is how it's rendering works. It interacts with everything else. I don't think it's an unreasonable thing for a game engine to want to implement themselves.

Fantastic - whilst I need to run before I can walk with the dev I'm doing with it, increasing the focus on multiplayer work using web tech should make it easier to achieve some of the ideas that have been laying in notebooks for years.

Congrats to the team!

This is great news. I recently just found out about this and have tried a few things with ease. I can see this going as the standard game Deb for open source if you don't want to or are unable to create your own engine / libraries.

Godot is my game engine of choice. As a patron, I am now in very good company.

Godot is growing to be quite interesting. Hopefully they'll implement well parallelized Vulkan support in some near future.

Yes, but hard to say how soon it will be implemented.

Late reply here, but in a recent post Juan said that he would begin working on the Vulkan port in May.

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?

Notably, the article being from February 2018 tells a lot.

Godot is great and im glad they secured some funds they will put to good use. Right minds in the right place

Great news! Love the PROJECT <3

Godot is ABSOLUTELY great, especially if you are a python developer! Thank YOU!

Godot is a very impressive project.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact