The New Godot Development Fund | Hacker News Reader

The New Godot Development Fund

godotengine.org

233 pointsTomte95 comments

My opinion is that if you're already well into a project, it makes far more sense to donate to Godot's development and remain in unity while also developing as much as possible in an engine agnostic manner. Moving to Unreal makes about as much sense as moving from Microsoft Edge to Google Chrome. You're still beholden to a corporation's whims.

Godot seems to be at the state Blender was ~5-10 years ago. Many major features are ticked but on closer inspection, there are significant missing pieces or implementation bugs.

When I last looked, there were issues involving scriptable render pipelines, post-processing, lighting, maturity of 3D physics, feature completeness of AI components such as navmeshes, lots of QoL issues around shaders. Lots of individually small headaches around animations, transformation hierarchies, input handling, collisions, IK that add up. There are also of course the usually mentioned limitations around asset store, platform breadth, 3rd party support and tutorial/community size and documentation.

AFAIK, there is no Shader and vfx graph equivalent for non-programmers. A Jobs and burst equivalent for C# users would also be very useful.

As good as Godot is already, given it still needs work, you should seriously consider donating to its development even if you don't intend to use it. Also, if you're starting a new hobby game you should ideally choose godot over unity, it's the only way holes will get identified and filled.

The only way to make corporations accountable is for open-source alternatives to be a viable third option such that whenever cost of use exceeds a commercial offering's value proposition, switching to open-source is a no-brainer.

I hope this didn't come across as too critical of Godot. It is rather the opposite, I really want it to get to where Blender is today. If I'm out of date anywhere I'd actually be happy to hear that.

> AFAIK, there is no Shader and vfx graph equivalent for non-programmers

I'm not sure if you missed it or if you were referring to something else but there is a graph-based drag-n-drop shader pipeline tool in Godot today.

I am a long time Unity developer, I used to evangelize heavily for them. My past evangelism disgusts me. Use Godot if you can. Help them sand the edges. Any inconveniences that costs is worth the rug pull you avoid from what Unity will do to you.

> remain in unity while also developing as much as possible in an engine agnostic manner

You can't really work in an engine agnostic manner without drastically handicapping yourself, the whole point of engines is that they provide a large & coherent set of tools that interface well with each other.

Engine hops can and do happen, but if you're going to engine hop the best time was 6 months ago, and the second best time is right now. It's a lot of work, and for most cases deep in a project, the best bet is most likely to stay with Unity.

Rewriting the code is the easy part, if you're familiar with both engines & their languages you can copy & paste & fix errors, probably at a rate of 10,000 lines/day. The killer are all the level data, materials, prefabs, custom editor tooling and the entire workflow of basically everyone aside from programmers, that need to be rebuilt from 0.

I love the idea of a co-op game engine supported by hobbyists and studios relying on it. The blender of game engines (though blender tried this too it wasn't in their wheelhouse really).

Have Unity to thank partially for my career in Systems Engineering/SRE/Full-stack dev. Took comp-sci(C++) and Cisco CCNA in high school but didn't pick up programming again until about 4-5 years after; it was C# for Unity. That is what got me back into programming.

Kind of a shame where they are now but nothing lasts and they aren't the company they were; same as Hashicorp, same as always. Forwards is the only way.

> though blender tried this too it wasn't in their wheelhouse really Its my understanding that this was initially developed by one developer who was working on a game with his kid. Although my memory may be faulty.

I tried Godot for an art-pipeline tool (batch animating models in code & converting to optimised gLTF on a huge scale) - I was amazed actually coming from a Unity background, in fact it was the only tool that could do the job reliably (even ThreeJS didn't work - thanks GLTF standards ;-)

Can you go into a bit of detail please, or do you have a blog post about it perhaps?

Lol, no blog post. It was quite simple, various models were imported and parts on these models needed to be rotated over a number of frames, this constituted an animation which was then saved in GLTF format. There were 1000 animations with different rotation end points for a large number of models. The program was very simple to achieve the output and took me only a few hours to (a) understand how to do it in Godot and (b) write the code, which was remarkable to me. I'd tried for perhaps a day or two searching for solutions in ThreeJS - found bugs in the GLTF exporter, posted to the DRI, back and forth etc. Godot just worked.

Thanks for sharing!

interesting. So in this case did you output your scene as a single gltf file, or were the assets split out individually? Or does this distinction not matter much for gltf to begin with? gltf sounds like a very interesting file format for games, but so much of popular modeling formats veer towards singular assets and leaving scene management to the engine.

It'd be a dream if I could have a seemless two-way workflow throwing my blender scenes into an engine and vice versa, each tool able to mutate the scene file as needed.

GLTF is a very interesting format, it's a single file that can contain mesh, texture and animation data. In the case I wrote about single assets were created for each case, but it also could have been done combining all assets in a single file. The problem with GLTF (at least a few months ago) is that many importers or exporters in various libraries that roll their own aren't 100% compliant to the standard. Thankfully the Chronos group has a validator - and I've been vocal in reporting bugs to the various vendors in our art-pipeline toolchain (nearly all of them had various edge cases where they weren't 100% standards compliant). We were a case where we were using a lot of the functionality GLTF provides. Blender has good GLTF support and was a part of our pipeline as well - automated renders etc.

If small game companies/studios donate money and time in making Godot equivalent or greater than proprietary game engines.

The Unity problem disappears.

Good for them. Would love to donate at the $2/mo level but I don't see an option to do that unfortunately.

The world needs more software diversity. Open source brings freedom to computer enthusiasts. Freedom for game developers to choose to learn something that may be less polished, but it's open source and at least it's theirs to keep.

This is probably due to transaction costs, most of $2 might disappear before hitting the target. Perhaps you could donate $24 a year?

Good idea thanks

The prob with open source is that once the founding team is way over their head, they get insecure and the whole story shifts to how to retain their control of the project. And that point is reached quite fast these days as software complexity rises. So many open source game engines exist all rebuilding the same pieces cause people dont want to give up control. But control is an illusion in such a complex ever changing world.

The solution is to put code out stripping away personal connection to it. There is no other way for the ants to handle the growing complexity of the ant hill.

Right because the closed-source game engines with 10x the complexity are really struggling not yielding control.

Your claim is phrased like it applies to all projects.

In such case "the whole story shifts to how to retain their control of the project" is simply false.

You're adorable. The godot leadership has proven to me that they're shrewd and focused on creation, I'll follow them.

So now it looks like everyone is waiting for Godot.

https://en.wikipedia.org/wiki/Waiting_for_Godot

Great timing!

Ha, my thoughts exactly.

Perfect time to open up a Godot porting consulting business :)

Oh what do we have here: https://w4games.com/

I hope they will drop the funny little language in favour of first-class C# support.

Godot 4.0 has C# support. They're working on getting it up and moving for iOS and Android but it already works on Desktop

I think the emphasis is on "first-class" support. I don't think they'll be able to really pull over Unity devs until C# mobile is nicely supported.

I know every time I personally go to take a peek I see that C# support is still a good bit behind and decide to let it keep baking. I'm still very excited for it, though.

Partial support, there is nothing for game consoles and mobiles.

Seconding that Godot C# support is pretty alright and in motion, but also GDScript actually is rather nice for game jamming and quick prototyping.

Their funny little language is really close to Python so it's tapping into a huge base of Python developers.

Is there any background for why they chose to roll their own language, rather than harness Python or another, popular language?

There is indeed a section about that in the docs.

https://docs.godotengine.org/en/stable/about/faq.html#what-w...

It’s not that long ago when people were saying:

“Weird how Unity uses Microsoft’s enterprise Java clone. Why can’t they use C++ like real game engines? Nobody will develop a proper game on this language.”

One can still hope.

Only those that having been around for the history of game development.

Once upon a time the same was told about Basic, C and Pascal, all serious game development was Assembly.

Then the same was told about C++, all serious game development was in C.

Then the same was told about Java, and a couple of folks not paying attention got millionaires.

Then ...

Yes, this.

So many devs get caught up on which language is used. I have my pet languages that I prefer too, but at the end of the day a game engine is about creating games. So long as the language offered is reasonably usable and one can deliver a fun and engaging experience with it, the language bindings don't matter much. Everything I've read about GDScript indicates that it fills the need, is fun to use, and generally gets out of the way so devs can focus on creating fun and engaging experiences.

The only reason I see having C# support is critical is if a Dev is porting from another engine (i.e Unity) midway through development or if the dev/studio has lots of boilerplate code or libraries already written for prior titles. If starting from scratch, I don't see a good reason to stick with it.

I really hope Rust is the next iteration of this story. At least for the deep engine/rendering code. You can have a scripting layer on top of that for designer iteration.

Sure but the problem with gdscript is not that it's an abstraction or a high level language. It's that it's a weird dsl that isn't even really good at making games. I don't mind DSLs when they actually enhance the domain they are created for, but in this case having a game engine language not having interfaces or traits is weird...

That would kill unity and make godot the preferred engine over night for large indie communities.

I don't think that will happen until Godot has an asset store with as much content as Unity.

Not as hard as you think. just a few assets ported will be enough. - 3d player controller - dialogue system - vr kits - animation system in the style of mechanim

Those are what the vast majority of indies buy beyond 3d assets where they can get elsewhere.

I prototype Godot games with a small team that is less technical. They are able to handle (some) GDScript but not C#. I realize my use case is non-professional but I think it's good that a more accessible language is the default option.

I don't see why there cannot be both? GDScript is perfectly useful.

I prefer it. I'm not wasting a single second in C# until I have to.

For me it's not whether it's useful, it's whether the tradeoffs are worth it. I assume GDScript has some unique features that make it especially useful in Godot development, but the disadvantage is that the skills aren't transferrable to any other platform or environment. At least C# and C++ are applicable outside of the engines that use them.

I get what you're saying, but a good chunk of transferable skills are not language-specific. Programming in a video game environment is going to impress some knowledge upon you that is generally useful, regardless of the language you use.

The skills are transferrable enough. It's Python with a little syntactic sugar for Godot-specific things.

It's an easy language to pick up for beginners and powerful enough for experienced devs. Kind of the sweet spot for game dev, IMO.

Because as is C# is very noticeably a second class citizen. Something like Godot 4.0/4.1 missing C# support for android/ios/web shows that perfectly imo.

Why do you want them to drop it? Why is it not enough that you can completely ignore it and write your games in C#?

No way! The funny little language rules! It's a competitive advantage for Godot.

GDScript integrates so nicely with the Node/Resource refcount model. It fills the same niche that Unreal's Blueprints do, which is great! When you've found something performance-critical, it's not difficult to convert a GDScript node into a GDNative one.

I feel like a lot of the "GDScript, ick!" comments tend to assume that the scripting language is trying to be Lua/C#/Python tacked onto a C++ codebase. It's a lot more tightly-integrated with the runtime, and it makes organizing things a lot better in the long run.

The Rust bindings (crates gdnative for 3.0 and gdext for 4.0) also are pretty great. I've only used them a bit so far but once I got the hang of it it works well. They don't seem to teeth badly with Rust's ownership semantics like some attempts at wrapping GTK struggled with.

I haven't used Rust professionally, but have often wondered if Rust's RAII [1] meshes decently with the lifetime of a RefCounted in Godot. [2]

While Godot's profiling has a lot of room for improvement, I appreciate how intuitive memory usage is from both a design and technical standpoint.

[1] https://doc.rust-lang.org/rust-by-example/scope/raii.html

[2] https://docs.godotengine.org/en/stable/classes/class_refcoun...

The funny thing is that if you are looking for some GDScript call into the engine it oftern supports exactly the functionality you need for your use case even though other more common use cases are not supported.

It shows that the developers making it are also the ones using it for themselves.

Agreed, having C# be the default would also better incentivize former Unity devs to jump ship. Not to mention that learning C# has value outside of Godot, whereas GDScript is not exactly transferable knowledge.

Is there any way to donate individually?

EDIT: Found it: https://godotengine.org/donate/

Wasn't there an organization by Godot's main developer raising money for it already?

You mean W4 games? Their purpose is more about consoles, as far as I remember.

https://w4games.com/

I'm not sure why this just got posted (to Godot's website, not HN) today, I've been supporting them through their new fund for a month or two now already.

I am out of the loop. What's going on with Unity?

They decided to burn their trust with the people that use their tools for a hypothetical short term gain.

They're going to charge developers a fixed amount per install of their game. The amount varies based on license between $0.01 and $0.20 and they're applying it retroactively to all Unity games ever released.

https://blog.unity.com/news/plan-pricing-and-packaging-updat...

Great news! Given the Unity price changes that dropped[1] I hope we see Godot get more funding.

[1] https://blog.unity.com/news/plan-pricing-and-packaging-updat...

I assume you mean "dropped" as in posted? This is such a dumb slang word, confusing in the discussion of pricing.

Did Unity pricing go up? I assume that's what you're saying?

[edit] Just apologizing for the "dumb" statement. I meant it associated to the word. I should have just left it with "confusing", which is how I meant it. Sorry parent if that sounded directed at you.

It's also ironic that he is all for increased funding, but not paying increased prices.

It's ironic that I am cheering for a small open source team to get more funding in light of a $14.7B for profit company introducing what appears to be developer price gouging?

Arguably, more people benefit from funding open source project than paying for a license of a closed source program.

I agree that funding open source development is better than paying for commercial software in terms of 'making the world a better place'.

My point was just that the grandparent poster was acknowledging money is critical to success, yet griping about paying money toward something they use.

I don't know anything about Unity's price increases (and I am not standing up for them), but I think it is important to keep separate the concepts of 'free of charge' and 'open source'. Just because I am letting you at the code doesn't mean I can't be paid as well.

>My point was just that the grandparent poster was acknowledging money is critical to success, yet griping about paying money toward something they use.

retroactively changing the price of your product for no extra beneits has never been celebrated. Asking for donations can be positive or negative depending on the context.

>I think it is important to keep separate the concepts of 'free of charge' and 'open source'. Just because I am letting you at the code doesn't mean I can't be paid as well.

sure, unreal is "open source" but you need to sign into their developer network to even view the code, and have a strict license on what you can do and share outside said network. So not quite open source, just "readable source".

AFAIK, Godot is indeed free as in freedom, licensed under MIT. It's pretty much "open source" in the true spirit of the term.

The increased prices are retroactive which means if you agreed to one payment model you will be forced into paying another even if you finished your game 10 years ago.

>I assume you mean "dropped" as in posted

Yes, "dropped" is a highly overloaded word, but one definition is:

>set down or unload (a passenger or goods), especially on the way to somewhere else.

so it may be a stretch to call it slang. saying that news "drops" as it is unloaded onto the public makes sense.

But when the conversation is about pricing, the word "dropped" there sounds like it's saying that Unity dropped their prices, which is opposite of the fact.

Relevant discussion on HN: https://news.ycombinator.com/item?id=37481344

Godot is great, definitely donate to this project and we could get something like blender. To think of it, a Godot blender game engine would be sweet.

blender + godot is too powerful

They seem to be linking to gambling sponsors - I've notived most open source projects don't. Why is this?

Does Godot make enough money to be picky about sponsors?

Maybe those gambling sponsors didn't fund other open source projects?

So what?

You imply something, but what do you mean? You're asking this in an innocent fashion, but presumably there is judgement against linking to what is a legal activity. Just say it.

The higher tiers allow you to link to a domain of your choosing. Would you expect the Godot team to ban links to gambling companies?

Game engines usually charge a far higher license amount for using their tech in the gambling industry and because Godot doesn't charge anything and its programming model is pretty in tune for what gambling games need they get a lot more gambling sponsors then other open source projects.

Because gambling is a funnel that converts exposure into raw, unrefined, money, and sponsoring Godot has incredible value-to-money: naïve game developers generally have poor financial sense!

They have 1 from what I could see, Gamblify, what are the others?

It is sponsor platinum, so they are paying much more than that.

Great Question! They link to their exactly 1 Gambling Sponsor Gamblify because they are a sponsor who've chosen to utilize the benefit of their sponsorship to link to their website.

The reason why other OSS projects you've looked at don't link to Gamblify is because they don't sponsor them, thanks for your question.

I have a question, what motivated you into asking a misleading question?

How is it misleading? No one is forcing Godot to accept a sponsor and showcase them. Where do you draw a line? Would they also accept and showcase an adult website? A piracy website?

I sure hope so. I like piracy, porn, and gambling and would be extremely pleased to be directed to any business in those categories that chose to sponsor an open source game engine.

They've implied there are many Gambling sponsors, that most other OSS projects are either refusing to accept sponsorship from Gambling companies or refusing to link to them after receiving their sponsorship, that collectively all OSS projects are actively doing this, when it's simply the "most open source projects " being referred to simply aren't receiving logo-tier sponsorship from Gamblify.

IOTW It's making a misleading statement, phrased as an innocent question.

Are there OSS projects that have gambling based business sponsors that don't link them?

Genuine curiosity - I didn't mean for the question to be misleading (and I'm still jot quite sure how it is).

I know that historically gambling sites have paid to have oss projects link to them in order to make them look more reputable to search engines, but search engines use different heuristics now I know.

I've also read of projects actively rejecting gambling sponsors or taking their money but refuse to publicly acknowledge the sponsorship. Taking the money without linking to the gambling site kinda makes sense to the gambling site if they use Godot and want to support it, but then why would Godot still link to them in that case?

I'm just curious why Godot is willing to tarnish their reputation, and also what yhe gambling company stands to gain from being linked to by Godot.

> I'm just curious why Godot is willing to tarnish their reputation

A non-profit accepting sponsorship from legal corporations to pay for its developer resources to improve their free product to the benefit of all its users wont tarnish their reputation.

Obvious questions phrased to imply misleading statements is what would attempt to tarnish their reputation, thankfully it's a fairly transparent attempt so I expect it will be mostly ignored.

> why would Godot still link to them in that case?

Answered by TFA "Displaying your name or company is opt-in. You control it being public or private."

Whenever I see such links, I assume the website has been hacked, its always weird to see open source projects accept such dubious sponsors.

I don't get your point... you would rather they hide the fact by not linking ???

I much prefer the transparency.

I’ve actually seen several OSS projects that look like gambling link-farms. This is tame in comparison.

I think you should frame your questions a little less loaded in the future, but I do think you're also making a good point. Ethical sponsorship management isn't easy, and certainly not a set of trade skills I would expect to find in software development by default, because why would you? I think the main reason you see less "unethical" sponsorships in OSS projects in general is because a lot of OSS developers are rebels who have an innate hatred for corporate and evil.

I certainly get why gambling could make its way into game engine sponsorships since it's not exactly easy to gather money through sponsorships. It is a little like having a big game hunting company sponsor your national park though. I'm not even sure if I think it's wrong, but it's certainly a risk in terms of it potentially causing some PR issues down the line.

Reply on news.ycombinator.com