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.
“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.”
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...
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.
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.
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.
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.
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.
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 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?
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 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 ;-)
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.
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.
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.
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.
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!
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.
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."
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.
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.
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.
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.
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.
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.
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.
99 comments
[ 5.2 ms ] story [ 224 ms ] threadI 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.
https://docs.godotengine.org/en/stable/about/faq.html#what-w...
“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.”
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 ...
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.
Those are what the vast majority of indies buy beyond 3d assets where they can get elsewhere.
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.
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.
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...
It shows that the developers making it are also the ones using it for themselves.
[1] https://blog.unity.com/news/plan-pricing-and-packaging-updat...
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.
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.
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.
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.
https://w4games.com/
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.
https://en.wikipedia.org/wiki/Waiting_for_Godot
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 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?
IOTW It's making a misleading statement, phrased as an innocent question.
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.
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."
I much prefer the transparency.
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.
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.
The Unity problem disappears.
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.
In such case "the whole story shifts to how to retain their control of the project" is simply false.
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.
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.
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.
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.
https://blog.unity.com/news/plan-pricing-and-packaging-updat...
EDIT: Found it: https://godotengine.org/donate/