One of my favorite parts about Godot is that it gets away from those crazy load times / lockup you experience in Unity/Unreal. The .import file it associates with your asset is plaintext. Definitely running into fewer merge conflicts.
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)
Hi! I work on Godot Engine closely, improving the 3d asset pipeline.
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.
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.
I don't know, to me the choice of their own NotPython as the main language seems like an incredible misstep to me. It's lacking in features (last time I checked they didn't even support basic things like lambdas), tooling and libraries.
There's a reason why both Unreal and Unity moved away from providing their own language.
I thought it was a massive misstep until I started using it heavily.
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.
Coroutines and lambdas are orthogonal features. if the language supports it, a lambda can be a coroutine. Arguing that one will replace the other strikes me as nonsensical.
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
Im thinking of both lambdas and coroutines as techniques for asynchronous programming - like the 'complete' callback for a network call, for instance.
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.
All these things. GLTF and godot have been amazing to me, though I do sometimes struggle with the asset flow but I'm getting better.
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.
Have you tried it on a package of similar size? Yes I hate the Unity/Unreal start up issues. On the other hand they are doing a ton of stuff for you. Compiling 100s or 1000s of shaders for for particular GPU, compiling all the code, processing all the assets for your particular platform. Those all get cached but the first open is painful. But I can't imagine Godot is any different. Those steps have to happen and they are all heavy steps. If Godot is faster it's more likely because it's doing less for you than because it's actually faster.
