Godot's Creator Advice to Unity Users Switching Explained!

[ThantiK]

Composition is something in Godot that I feel like I've been greatly underutilizing.

[adomadeira]

I strongly believe that just explaining godot without comparing to anything is already crystal clear, godot is incredibly simple to understand!

[nixellion]

2:12 In Unity you don't need to create a new class to combine 2 behaviours. You can add 2 components to an entity, just like you did in Godot.

EDIT: Godot even has a full article written an linked in their very first pages of documentation comparing ECS to Inheritance, in which it explains that philosophically Unity is built around ECS and Godot is relying on more classic inheritance, and how its composition is actually done on a higher level. Which, according to Godot docs, is overall less performant, but is otherwise easier to work with etc.

[MrEnvisioner]

2:12 Just for people's clarification: the primary advantage of Godot's approach to "composition" (as Lukky puts it) here is twofold:
1. Godot's reliance on inheritance allows it to offer a large library of built-in tools for specialized use cases using a SINGLE, common API (everything is a Node basically). This runs in contrast to Unity having 3+ different APIs for every little thing. When Godot DOES offer multiple APIs for the same task, it's because they each solve very distinct, separate use cases.
2. Godot's node hierarchy isn't actually "composition", but rather "aggregation". Each node can exist independently of an owner, unlike Unity's MonoBehaviour type which depends on GameObject. This then allows Godot's 1:1 mapping between scenes and nodes via a root node. The aggregation allows easy refactoring of subtrees into their own scenes, the attachment of other scenes into the current scene, and choosing multiple options for customizing nodes (scripts vs scenes vs GDExtensions). They all follow the common Node API and thus make everything simple and intuitive.

3:28 "So that it stays clear in the composite" If you are not familiar with the Composite design pattern: that is what is truly being showcased here. The Node API is an implementation of that pattern and allows each one to serve as an abstraction of and/or aggregation toward a given subtree of nodes. There are also more interesting applications of this idea featured in the Godot source code. For example, whenever a Control node is added to the SceneTree, it will search up the tree for the Viewport node above it and add itself to a SceneTree group (like a Unity tag) specific to that Viewport node. Then, whenever the Viewport node detects an input event, it will get that SceneTree group and iterate over all the nodes inside it to call various virtual input handler methods on them (such as `_gui_input()`). This is how every single node in the SceneTree gets access to the different input handling callbacks. It isn't that every node is listening for input. They just each register themselves with the ancestral Viewport and the Viewport does all the listening/triggering logic. In this way, the nodes are aggregated into the Viewport subtree's logic.

6:34 While the documentation focusing on GDScript is an important aspect, the bigger reason to use GDScript is really the tight integration with the engine that it offers you and its lightning-fast compilation speed. When you use GDScript, you are able to iterate on logic INCREDIBLY fast, and that is honestly the most important factor WHEN IT COMES TO GAME DEVELOPMENT. In other industries, there are established patterns and solutions for most things that you'll need to do to achieve your goal. In game development, however, you're constantly tweaking things left & right to pursue an abstract ideal of "fun" you imagine in your head. Before you ever decide to code things up in a heavier language like C++ or C#, it can often be far simpler to work out what concrete logic you ACTUALLY want to have using a scripting language built with iteration in mind before then porting that logic to a more long-term, stable implementation that can contribute toward your own reusable framework. That is, in fact, how many Godot features will be implemented. Someone creates a prototype using GDScript and showcases it directly via a running scene or an EditorPlugin, and then with that demo approved/supported by others, they get to work on a concrete implementation in C++ to submit for a PR.

[Lythowastaken]

For 2:15, thats not true. You can just simply create multiple scripts and attach it to one GameObject to modify it. There is no need to use an inheritance approach in unity.

[JingIeFett]

0:30 and 2:15 No, in Unity you would generally NOT create a character class and then inherit from it. You can do it that way, it's an option, but that's generally not how it's done. That's how you'd do it in Unreal. In Unity you'd break things up as components. You'd make a movement component, a behavior component, etc. and then use composition to create different prefabs by attaching different combinations of components.

[samach]

There are multiple ways in Unity and C# to do what you are doing here in Godot without writing a new enemy MonoBehaviour class in order to get a modified movement (or other type) of behavior. My enemy could implement the IMovement interface and inherit from different base classes. Or I could simply put all movement functionality into different component classes, again using an interface, and attach them to my enemy game object as desired.

[NightFoxZero]

This video was actually very helpful. In the little bit that I tried Godot previously I hadn't really thought of making different behaviors be their own nodes. Doing it this way makes it really easy and modular and is just easier to locate rather than digging through tons of lines of code on a single script

[dsteveo]

Thanks for taking your time to put this together. I've just begun making progress in Unity with playmaker but will now always be waiting for the next shoe to drop, the need for Unity to shovel money to shareholders instead of the engine. Maybe next they decide personal isn't worth it for the bottom line at all. It's good to have alternatives.

[GeorgeNoiseless]

GDscript has more documentation right now, but if GDscript vs C# Godot tests here on Youtube are anything to go by, the community has to start working on C# documentation _stat, _ because those test show a significant performance advantage for C#.

[leonpijudo]

i start to use a composition approach in Godot using nodes as components and signals, and its great, so scalable

[kritik_mb]

Somewhere in that twitter thread he answers someone about how to use interfaces in GDScript which is hard to understand/visualize in a practical way.
Can you make a video explaining that, please.😅

[sziklamester]

I am totally new to coding and game making. I am trying to figure out and make something working in Godot but I have little to no time to do it but regardless of this I value the tutorials.

[RayOfSunlight]

5:04 "The window's window" 😂

[nexxogen]

1. As many have already pointed out, in Unity, you would just add a script for the desired behavior. You don't need to create a new class.

2. How does having to add a node for every script you want to add make it clearer? It clutters the scene with extra nodes each of which already has a bunch of components. It's much clearer to just add another component. If you prefer Godot’s approach, you can always create a new game object for each script in Unity—but in Godot, you don’t get the option to work like Unity.

3. Unity’s prefabs are simply superior to Godot’s packed scenes. In Godot:
- You can’t see a packed scene’s hierarchy in your main scene without opening a separate window.
- Modifying properties on a packed scene instance’s root node doesn’t persist back to the packed scene (at least I couldn't make it work).
- There’s no equivalent to Unity’s "prefab variants" (correct me if I’m wrong).
- Unity also lets you make a prefab local with "unpack, " so that’s not a unique Godot feature.

4. The lack of scene settings in Godot? Not sure how that’s helpful—maybe it’s just meant as a guide for Unity devs.

5. "In Unity, you design in code; in Godot, you design in the editor." As a Unity dev with nearly 10 years of experience, this statement makes no sense to me. Scene composition in Unity is very similar to Godot, but Unity doesn’t force you to add nodes for everything. You can if you want, but you’re not limited. And when it comes down to game logic, you have to do it in code in both engines.

6. GDScript has great compile times and nice integration of await. But basic features like rename refactoring and being able to inspect variable values easily without having to jump through a bunch of hoops while debugging are missing. For instance, renaming a variable requires "find and replace, " which is useless if the variable doesn't have a unique name across the whole project. These are such basic code editor features, and they still don't exist in Godot.

I'm sad to say that Godot is simply not a replacement for Unity yet, and based on the direction it has taken, I doubt it ever will be.

[gass-tube]

good video. it has taken me some time to digest the idea that scenes are pretty much classes. also to mention - from my experience - I definitely like using GDscript within Godot for a number of reasons which where mentioned in the video. but there is still space to grow in terms of the type system, interfaces and autocompletions (helpers) ... e.g it is still not possible to specify a Dictionary interface for the return value of a function.

[FuzzballStudios]

I’ve heard it’s actually better to use the `owner` keyword instead of `get_parent()`. Less prone to error that way, as reparenting at runtime or rearranging in the editor could cause a crash if it’s looking for a property or method on a node’s parent; the node’s owner doesn’t change unless you change it.

[shodanargie]

I didnt know Godot's creators were Argentinian or that the engine was made here. Nice

[puzzud]

Thanks for making this video. It's a good supplemental to Linetsky's posts. However, it's a better practice for the parent to relay what it wants to have manipulated by its child to its child rather than a child always calling get_parent. And if it can be done with signals--but sometimes it's not so easy or nice.

[zendraw]

2 questions.

1-how can one handle IK in GOdot? Unity has Animation Rigging, the goal being, make a character that can pick and return weapons from his back, aim them at a point, while at the same time retaining his baked animations to the skeleton. Basicly i want to make a GTA character, aim the guns, when i pickup items, he reaches out and his arm actually connects with the item regardless of wwhere it is.

2-which godot version is stable and usable long term, 3 or 4?