Experience from other engines, what to do with it in Godot?

General
1

As this topic has been tackled by a bunch of people on YouTube and various forums, I thought it would be interesting to ask it here—where so many people are active and have landed on Godot for different reasons (such as no fees, lower hardware requirements, and easier scene organization).

I should mention one of the reasons I stepped away from Godot for a bit. While I feel comfortable using it, I find it lacks the built-in tools needed to make a nicer environment by default.

What do I mean by “environment”?
In my view, it’s the terrain, lighting, fog, and horizon. All three major engines (Godot, Unreal, and Unity) have these features. However, Godot and Unity keep them lightweight by default. The latest versions of Unreal have added a lot more weight to their environment tools thanks to advanced light sources, reflections, and light bouncing. While that’s cool, it often ends up making the scene incredibly bright—especially if you use sRGB vertex colors instead of Linear for FBX files. As for GLTF, forget it; it’s way too complicated.
One thing I would highlight is that Godot misses a basic, built-in First/Third-Person template to let users test these environmental aspects right away. I know demo projects and the Asset Library exist, but having a built-in “Gym” style template would be great for getting hands-on experience without having to create everything from scratch.

Collision
In my opinion, Unreal’s default system is amazing because it lets you quickly scatter foliage and easily choose collision presets (Block All, Pawn, Dynamic, etc.). In Unity and Godot, this feels more like building a component from scratch and saving it as a prefab or inherited scene. It’s nothing special and requires a fair amount of work to get right—even when using plugins like Terrain3D.

Animations
For basic use, the workflow is fairly similar across all three engines, though Unreal has slightly better retargeting tools.

Code Complexity
GDScript: Very intuitive with a great built-in documentation reference.
Unreal (Blueprints): Saves a lot of repetition for basic things, but can become incredibly time-consuming for advanced systems.
Unity (C#): It has a bit of a learning curve when it comes to getting used to all the different classes.
Overall, Godot has made the biggest push and gained a massive number of new users over the last year.

What do you think about the current state of these three engines?

Do you exclusively use one, or do you still jump between them for personal or professional development?

1 Like
2

If you know how to code, how to learn tools and how to make art, you will learn godot and gd script way faster!

And most things are kinda equal in most engines.

Like in Unety U add a collision component and in godot U add a CollisionShape node and set up your collider shape.

Sorry for my bed gramar english is not my native.

3

Learn C++ well. It will cleanse you of the analysis-paralysis mode you seem to be stuck in. It’ll also make your thinking platform/language agnostic and your coding skills highly adaptive.

4 Likes
4

TBH I feel your post is very high-end 3D-focused. Most of the things you brought up if you’re not making a high-fidelity 3D game in Godot.

Unreal is a great engine if you want beautiful graphics. It’s not for single person or small indie developers. It’s also not the choice for most AAA companies who have, or make, their own engines. Epic is trying to make their store a choice for developers by charging nothing if you post your game on their store. This seems ethically poor to me.

Unity lost a TON of market share by trying to charge per install, and they’re never getting those customers back. I expect they will continue to lose market share to Godot and Unreal until they go out of business. They may stay around for a while longer for mobile games.

Godot is gaining ground because it’s good, and improves at a prodigious rate that Unity and Unreal cannot keep up with. Godot gains ground with every release because it’s open-source. It’s a team of about 10 paid people managing a massive project and a lot of FOSS volunteers. This discussion changes every few months because that’s how fast Godot changes.

4 Likes
5

I always find the UE to Godot questions a bit up my alley, having professionally (like, for a living) developed on UE and Godot at the same time.

Here’s my high level “this maps” vs “beware” migration advice:
Maps well:

  • Blueprints per actor → Scenes per actor
  • ORM/Substance Materials/Material Instances → Still materials, and you can use a shader graph that’s very similar. Heck, ORMs are actually easier than UE
  • Builds/Exports → Holy cow, the build export process is WAY easier, distribute a pck file + the prod template file, no big directories, no big long bake times
  • Animations → Actually, VERY similar. DO NOT USE Godot’s SKELETONS. Holy cow, they suck I lost so much time because I tried. Just export the existing rigged stuff from Fab/CG Trader/UE, etc, use an autorigger for new anims, import as is. Otherwise you’re in for a nightmare of renaming and joint issues and incredibly crappy IK, etc.
  • Camera work/rigs → Pretty much an identical mapping, though the cameras are vastly simplified in Godot, for good or bad. I rarely used all the super over-the-top stuff in UE designed to match physical lenses (mostly just exposure tuning, etc) so YMMV
  • Input mapping → Pretty much the same, though I find Godot’s easier and more flexible
  • Texture size management → Rather than groups, you have to do it manually (or via importer config), but still quite similar
  • State machine → Animation tree. Really really similar, differing only in the UI. It’s a bit clumsy, but nothing too bad.

Does NOT Map well:

  • Classes/Inheritance → This one really caught me out recently, so it’s worth pointing out that the actor/camera/control model from a physics standpoint is backwards compared to UE.
  • Performance Tuning → Performance is performance, really, but you’ll find you’re missing so many things that UE has. The upshot, it is a heck of a lot lighter weight, so you may not really need them.
  • Skymap/Environment → Quite a lot different, really, but YMMV.
  • Baking/dynamic lighting → Different, and in a lot of ways, you’ll have a bit of a struggle. SDFGI does a lot to bridge the gap, but you’ll need to trial and error
  • Cutscenes → That’s SO different. I often find myself missing UE’s super advanced (well, feature-film tier) cut scene stuff. Can’t help you here.
  • 2D/UI, UMG vs native 2D UI layer → This one is such a win for Godot I don’t even know what to tell you. It’s drastically different, but just so much better.

Anyhow, that’s my 2 bits from the trenches on both sides.

6 Likes
6

I thought the actual UI was similar … you still have anchors in Unreal, theres a draggable interface … i guess the coding is different.

Unreal really wins for graphics, simulation and animation, but Godot is actually quite easy to script and can be super powered for certain scriptable activities …

Have you checled out Lumberyard or the gihub DX11 Cryengine? Great deferred rendering and after KCD2 probably worth checking out …

But yeah i think its pretty clear that Unreal blows the competion out of the water for next gen AAA level quality and component support … If you know what you are doing and have plenty of funding :slight_smile:

7

AFAIK Blueprints are dead with the latest UE6 update.

1 Like
8

Theyre phasing them out … but people who have blueprints will probably continue to maintain bluepront libraries … i mean Unreal 5.7 is still competitive with the rest of the technology even if support dwindles over the next year or so.

2 Likes
9

I wouldn’t be surprised if the sole reason for killing it in favor of a scripting language is that Blueprints are simply not textual enough for LLM based agents to handle them.

5 Likes
10

Have you ever used Blueprints ?

They can be very clean cut, yet very rigid and unflexible, especially if you dont know all the tricks. The nodes can help with error checking and correctness - there are no typos. With script its easier to find a flexible workaround to problems that have not been documented and solved previously. And yeah i am sure script is becoming easier to work with.

Theres a recent video on youtube showcasing that Claude can “actually” use Blueprints.

1 Like
11

Yes, blueprints in UE and GeometryNodes in Blender are just code in the background. LLMs can handle them fine. They are more spaghetti than human made ones , some node chaos, but the logic thy can handle.

12

Geometry nodes were harder to understand than blueprints … i just couldnt see the logic in some of them.

1 Like
13

I wouldn’t bet on it. Blueprints don’t have intermediate source code representation (like e.g. Godot’s visual shaders). They compile directly to bytecode. While I’m sure an agent could be coaxed to do something with Blueprints, the lack of textual representation would severely limit it. And Epic is clearly more than aware of that.

1 Like
14

To be fair, I have only tested Geometry nodes in Blender. I thought there would be more parallels to UE Blueprints.
In Blender I was impressed what an LLM can build with nodes.

15

Geometry nodes and Blueprints serve completely different purposes. They are not really directly comparable.

1 Like
16

Maybe here they are more distinct than I see them. I have used visual scripting in Virtools and Hudini. It all mushes together in my view on visual scripting.

17

Geometry nodes are not really a generalized scripting tool. While they are turing-complete and can theoretically compute anything, they can get quite cumbersome if used outside of their primary purpose as a vertex data transformation graph.

2 Likes
18

Sometimes, running a Python script is way cheaper than building Geometry Nodes, which can easily bottleneck your memory.
I’m not sure how this conversation ended up here, but would you mind elaborating on this?

What does it actually look like to know C++ well?

19
  1. Ability to read a large codebase and make changes/additions to it (e.g. Godot source code)
  2. Ability to read and understand most of the standard library documentation without scratching your head.
  3. Being able to implement your own template library
  4. Knowing what a rvalue reference is when someone suddenly wakes you up in the middle of the night :slight_smile:
  5. (optional) Thinking that Bjarne Stroustrup interviews are actually interesting.

As to why I said this; C++ forces you to learn many fundamental concepts in computer science and computer architecture. Those translate extremely well to almost anything you do with computers in any other language/platform/api be it high or low level. In other words, it’ll cast a wide net for you, increasing your versatility and the ability to quickly adapt to different development environments. With that, the nagging question of which engine does it pay off the most to sink time in - becomes pretty much meaningless. Things like that wouldn’t matter at all when your fundamentals are strong. And learning C++ well is a solid way to get there. Plus, it’s still considered an industry standard language.

3 Likes
20

These fundamentals are quite deep.

Do they come naturally over time from just working with code, or do you have to deliberately build projects to extend specific aspects of your programming skills?

If you already have a basic knowledge of C++, what specific steps would you take to achieve milestones 1, 2, and 3?