I agree that there could be further improvements made there but I've had good luck with .gltf.
Additionally, I've had problems with materials or animations importing into Unity as well. Seems like its a big, common problem.
Unity imports started getting smoother in recent years because marketplaces and artists started specifically targeting unity.
Versioning is the nightmare of Unity. So many assets and plug ins only work with certain versions.
They even have a blog article on why it's the future (like JPEG for images) and how many big companies have started supporting it.
Hands down the best install experience of any similar tool.
* Unzip one binary and run it. * The app auto-detects everything you need, and uses the best version it finds * Its project layout requirements are "open an empty directory" * The example projects install and work!
Seriously, the biggest difficulty I had was finding the "run project" button. It took me a little bit of hunting.
That being said, once those issues are fixed I think it'll be a hard choice to not use Godot (for what I do, more 2D work).
What bugs do you think hinder dev speed?
I am vastly more productive in Godot than in Unity.
Currently I think the only criticisms I have are the 3D renderer is bad (whoop 4.0 lets go!), and there is not a strong community/asset marketplace.
I _love_ the workflow, though.
The bugs that hindered my productivity were mostly "land mines" that I discovered along the way.
1. I thought having my scripts as internal scripts sounded good for a week until I realized there are all kinds of undocumented problems with storing your scripts that way. I had to refactor.
2. There is no selection outline around mesh in the editor window. Makes it impossible to build a 3D scene in Godot. My guess is that the developers expect you to build the scene in Blender then import it as one big FBX. (But that's not ideal for some things)
3. Then I hit the dangling reference bug and that was a heavy blow to my enthusiasm. The fact you can save a reference to an object in a variable, and that the engine can then change what object your variable is pointing to under the hood. It's such a fundamental bug it makes me wonder what other massive issues are there waiting for me to run into. My work around was to listen for signals for when object references were removed from the scene and manually clearing them, but its a real drag.
There were a few other things, but those ones stand out in my memory as examples of why I don't think I can work in it yet.
The reference bug won't be fixed until 4.0, so have another look at Godot then.
Update: Here are the bugs I logged.
https://github.com/godotengine/godot/issues/31758 https://github.com/godotengine/godot/issues/32383
Update: Although if I had continued with my project from September I would have shipped with this bug. That's quite a long turn around.
I have never used a built in script and agree it should be removed.
I have never hit the dangling reference bug, and I agree it is critical. Good thing its fixed now.
I have been laying out scenes in 3D without the selection outline. It seems like a good feature to add. What I truly love about Godot is that you or I can actually add that feature. I know that turns some people off, but it actually is very attractive to me.
I played with it about 2 years ago (even contributed some code to godot-cpp!) and it was pretty good, but it did have some gotchas and issues. Many are likely fixed now. You should just give it a try, its easy to get started and then you can judge for yourself.
I dived right into the Godot tutorial "Your first game"[0] and had something basic running really quickly and I understood most of it without any further reading.
[0] https://docs.godotengine.org/en/stable/getting_started/step_...
If you're a "work bacwards from a finished project" kind of person, this tutorial is quite great as well
https://docs.godotengine.org/en/stable/getting_started/step_...
There were a couple of typos in there that I ran into, it shouldn't be too hard with a little programming experience to notice these. I didn't download the finished files because I think typing it out is a much richer learning experience.
There is also a Humble Bundle out there right now where you can get some basic lessons as low as $1[1]
[1] https://www.humblebundle.com/software/learning-game-coding-a...
The scene file is actually _readable_!!!!
The node and resource systems are vastly more accessible than Unity IMO.
Workflow feels so much better in Godot than Unity.
Godot's problems are in it's 3D renderer. It's not very performant nor good looking and has some shadow bugs...
Godot 4.0 should fix all that stuff.
The renderer is fine for my indie/low poly style, but is pretty limiting for advanced post processing and realistic designs.
The particle system isnt very good in godot 3.x so far either.
Godot has some a noticable lag spike when shaders compile as well.
So, there's lots of issues related to rendering and advanced stuff, but for my purposes, godot is way more productive than Unity for me. And thats because:
- the scene hierarchy has a superior design
- the keyboard hotkeys are better
- compilation time is non existant
- hot reloading works
- gdscript is faster to write than C#
- scene & resource files are more git friendly
- documentation is local and in-editor
- gdscript has opinionated & accessible apis for things that other languages make hard (string manipulation, encryption, file system access)
Godot is the future. I promise you this.
There's a reason why both Unreal and Unity moved away from providing their own language.
Now I really like it.
As to lack of lambdas, yes there are no lambdas, but coroutines are a first class citizen in gdscript, and network libraries, like Nakama for instance, use coroutines heavily. I prefer coroutines to lambdas anyways, and I think the industry is moving towards coroutines.
There are a ton of good things about gdscript. I was a hater on it until I started using it, and then I realised how quickly it allows me to do stuff.
Besides, I'm staring at the worlds worst Unity project right now.
Languages dont matter as much as system design.
And I don't hate gdscript, I just think it's incredibly half-baked and feels very immature. It's understandable that they only have limited resources, but that doesn't make my experience with it better.
Languages matter an incredible amount because of how heavily they influence system design. You can design an awful system in any language, but if you have to treat everything like a nail because you only have a hammer, you're bound to make a lot of awful decisions.
Edit: also, good IDE support really is incredibly helpful for working on larger projects
For functional programming, yeah there's no equivalent to a lambda in gdscript, but again, I think it's exceptionally well suited for the kinds of things you do in typical, run of the mill, game dev.
https://github.com/godotengine/godot/issues/2684#issuecommen...
I've been using 4.0a and havent found anything with major breaks so far, and Vulkan really shines compared to opengl3.
It makes me so happy that I can have a game editor that aligns with my RMS-esque views (pro gpl). Now if I can just get my friends on board, many of them have invested so much time in unity or ue they don't want to switch. My goal is to have a prototype cool enough to draw them in eventually.
As a side note I like your comment ^^
[0] didn't say current because master branch to be the current branch and it already migrated to Vulkan [1] https://www.youtube.com/watch?v=HQYZBZybP9M [2] https://www.youtube.com/watch?v=cKtwW9yU6QU
Things move slowly in any large project.
Changes that were made for Godot Engine to make glTF2 import acceptable were done in October 2019.
However, a feature request to make the official glTF2 importer (Blender) import standard glTF2 properly will take until Blender 2.83 (LTS) to arrive in the next few weeks.
Three.js is also able to import standard glTF2. There is an amusing chart of failures on Github. https://github.com/KhronosGroup/glTF-Sample-Models/pull/243#...
FBX 3d asset import support in Godot Engine is the same struggle.
Supporting standard FBX is the goal because of the focus on open source ecosystems. Even when the current Godot Engine fully supports FBX (Godot Engine does not currently), it will take significant time to get Blender's incompatible variation of FBX to be patched in stable releases of both Blender and Godot Engine.
Other people are working on Godot Engine rendering for the next version, but I am joyed at reviews of the glTF2 work.
I hope for future success in Godot Engine projects.