Scene composition differences with other engines

Just as a precaution given we've had trouble with comparison topics in the past...

###A note to anyone posting comparisons:

Please stay polite and respectful in your comparisons. It is fine to make comparisons, but keep in mind that not everyone shares the same opinion and that is totally, 100% fine and normal. We do not want to start a heated "Game engine vs Game engine" topic were feelings get hurt, so please stay respectful of the opinions of others. Thanks! :smile:

With that out of the way, I haven't used Lumberyard so I cannot say on how it compares to Godot. It is one of those engines that one day I want to sit down and try, I just haven't found the time :lol:

I have used Unity's nested prefab systems though! I'd say that both have their strengths and weaknesses, which I wrote below. It's a bit of a long read, but hopefully it will be helpful.

In my opinion, Godot's node and scene system is very much structured around the idea that you break functionality down into multiple nodes to get complex behavior. You can only have a single script in a node, and many times you need to access and communicate with other nodes, generally children nodes, to get things done.

This keeps Godot nice and lean. For the most part following this pattern allows for quite a bit of code and node reuse throughout a project. I find it is also fairly easy to debug scenes/nodes in Godot since there is generally a more compartmentalize structure in how the scene is setup, so when you need to debug you can generally focus on one part at a time until you find the problematic node(s).

However, at times I have found that Godot's compartmentalized structure can make things a little more difficult when communicating with non-children nodes. Signals and groups can certainly help with communicating with other nodes, but it can also quickly lead to a tangled mess if not managed.

This is not necessarily a bad thing or something exclusive to Godot. Many times this enforces a better thought out structure and composure, but I have found it easier to have more of a mess of signals and/or exported NodePaths in my Godot projects in comparison to my Unity projects.

Many times I make one or more controller/relay nodes whose sole purpose is to hold references to nodes so I then I can cross communicate with nodes simply by holding a reference to the relay node. This works fairly well and gets the job done and I use this system in both Unity and Godot projects, but I find I rely more on the relay system in Godot than Unity. Whether that is a plus or downside and/or whether it is just something I do, I have no idea.

Unity's nested prefab system seems more geared around the idea that you can take a single element in your game and reuse it in other parts of your game. This allows you to make changes to the nested prefab and the changes work their way up, as expected.

However, unlike in Godot where the focus is more on making nodes that do a single (or small amount) of things that work in your project and can be reused when needed across your project and project(s), Unity's system seems to be more designed to have prefabs tailored around reuse specific to your game, not multiple projects (at least in my experience).

This has its advantages and disadvantages.

One advantage (or disadvantage) is that you can add a lot more complexity to a prefab faster than you can in Godot. Since Unity allows for multiple components and scripts on a single object, you can add more cross-script/cross-component behavior that is expanded on as you add layers in your prefabs.

Another advantage with Unity's prefab system over Godot's node is that you can add/remove functionality a little easier than in Godot. In Godot, you can add nodes onto a instanced scene, but you cannot remove them without going to the base scene and removing them there (or at least, I think so). In Unity, you can both add and remove components to and from a nested prefab. I feel this is more of an advantage (especially with polymorphic code), but as with anything you have to be careful to not trip yourself up as you work on your project.

One disadvantage I've found that nested prefabs are not quite as shareable and reusable as Godot's nodes and scenes. Nested prefabs generally tend to stay in the project they were created in simply because they are generally fairly tailored specifically to the needs of that one project.

Finally, Unity's nested prefab system is still fairly new and so has some issues here and there that, by comparison, Godot's more mature node system does not. I've not found anything major or deal breaking, but sometimes you can get "huh, I wonder why this did that" moments in Unity with the prefab system, which are much more infrequent in Godot.

TLDR: both systems are different and have their own strengths and weaknesses. Whether one is 'better' than the other really depends on the project, how you set things up, and which works best for you.

Personally, I'd say Godot's scene and node system is really easy to get started with, is great for prototyping, GDScript is nicely integrated with the scene system, Godot is easy to learn and fun, and for many projects will work great and be pleasant to use.

With Unity's scene and prefab system, I'd say it is also fairly easy to get started with, is good for prototyping (though not quite as nice as Godot in my opinion), for more complex projects you have the advantage/speed of C# (Godot has C#, but it's not quite as stable as Unity's C# just yet), there is a bit of a learning curve but nothing too major, and for many projects it will work great and be pleasant to use.

So all in all, I'd say it really depends on the project, how you set things up, and which works best for you. Both scene systems are useful and powerful in their own right, at least in my opinion. :smile:

@DiegoBM said: Thank you for bringing the warning up @TwistedTwigleg, you are completely correct in that, more often than not it becomes a war from what it was originally a honest request for objective similarities/differences. Hopefully nobody will take it the wrong way :).

No problem. It is just a precaution in case.

Thank you for such an elaborate response, I appreciate your personal opinion on the matter. From what you say, unless I misinterpreted it, it sounds to me like both unity and Godot allow you to do pretty much the same with their systems, but developers usually take a more generalist-ish approach on Godot and a more specific approach in unity, but feature-wise are more or less equally capable? Definitely useful to know.

Yup! Your interpretation is correct and that is a good way to summarize what I was trying to say. :smile:

In this particular case I'm curious specially about Lumberyard since I've seen them claiming their approach is unique (and I've also seen that claim on Godot's side to be honest), and from what I've seen I couldn't feel they were that much different at all in terms on what both systems do, about creating some sort of "classes"(/scenes/slices) that you can instance afterwards, and changes to the "class" will propagate to the instances, being those "classes" able to be saved in files in shared among projects. That's why I wanted to get a more specialised view, from more expert people than me , since I must be wrong, and they really are quite unique and different? :)

Yeah, I dunno. I am definitely not a expert in the field or anything, so I'd take what I say with a grain of salt :smile:

That said, I also have noticed similar claims among game engines and haven't been able to really find what makes the features they are claiming unique truly very different than what is already out there. I imagine it is because in some specific uses cases they are unique, or maybe it is a marketing thing? But I'm just guessing to be honest.

Hopefully someone with some Lumberyard experience can help explain the differences in comparison to Godot, as on the surface both approaches seem very similar. :smile: