About making a cube, in Godot you can just make a CSGBox3D and tick Use Collision.
@D0mD6v10 ай бұрын
Sheshhh can't believe I missed this. I'll pin this comment. thanks :))
@Hietakissa10 ай бұрын
And why can't it just be called a cube, like in every other program in existence?
@Soremwar10 ай бұрын
@@HietakissaTo discourage it's use. I don't agree with it, but they really want people to use custom meshes instead of using geometry for building 3D scenarios So they are "encouraging" you to use the better option by hindering the use of the least performant one
@OminousHvh10 ай бұрын
i havent used godot long but i think you can just CTRL click and select multiple children or nodes and they will resize together also
@pythonxz10 ай бұрын
@@SoremwarCSGs serve this purpose, but I think the workflow needs work to make it smoother to use.
@itsMapleLeaf10 ай бұрын
Godot fan here! I work primarily with 2D. love to see videos like this, but I'd like to add some comments and clarifications 0:34 - Agreed that the editor workflow is confusing in some ways that aren't even mentioned in the video, but for the example with making separate collision shapes, you can right click on the "Shape" property in the inspector and click "Make unique". You _definitely_ don't have to make a new separate scene for each one. The default behavior of copying the reference vs. the values is probably not that intuitive here, but this probably has some reuse and efficiency benefits 1:41 - like you said, the multiple scripts thing is preference. I can see the appeal, but I personally haven't felt a strong need for this ¯\_(ツ)_/¯ 2:02 - On the scene tab on the left, you can click the "Remote" tab for the live scene tree 2:59 - In GDScript, you can do `get_tree().create_timer(0.5).timeout.connect(my_func)` and there's probably a C# equivalent likewise, you can use the `await` keyword: `await get_tree().create_timer(0.5).timeout; my_func()` but I'm not sure what that looks like in C# 3:22 - Look into resources, that might help here 3:39 - Fully agreed here 🫠 the use of a dictionary over a typed object is especially horrifying 4:17 - This plays a bit into the "composition" thing you mentioned earlier: Godot really wants you to think on a piecemeal basis when it comes to nodes and containment. Instead of making nodes reach for their parents, it's more maintainable (in complex games especially) to use signals, pass node references or paths via export vars, and making use of unique identifiers in the editor to reliably get nested nodes (search "Scene Unique Nodes" in the docs - not enough people know about this!) 7:19 - I know there's a Line2D node, surprised to see there's not a 3D equivalent 🤔I wonder if you could retrofit it though Also, particle systems have trail functionality, but I haven't used it myself
@D0mD6v10 ай бұрын
Alot of useful points. Thank you! :))
@turquoise781710 ай бұрын
@@D0mD6v definitely the biggest one here is signals; they're super easy to use in most cases and you can connect signals within the scene tree, so you would likely not run into any reference errors. would recommend
@briandawley780810 ай бұрын
For calling a function when a timer expires, I believe you could: instantiate a timer, connect a signal from that timer to your method, then start the timer. When the timer expires, it'll send a signal that'll trigger your method.
@croeusjawad974425 күн бұрын
You can also do this in GDScript to call a function after a certain time: await get_tree().create_timer(.2 *time you want to set it to in seconds*).timeout the_function_you_want_to_call()
@GamesUesu10 ай бұрын
1:19 Go to CollisionShape 3D or 2D in the inspector, shape, and with the right mouse click, select Make Unique, you can edit individualy.
@RenceAsANoob10 ай бұрын
And with Godot's open source nature, it may even be able to catch up to Unity thanks to the community. It may be plugins at first, but seeing the number of updates that is going to be added on Godot 4.2, it's a staggering difference.
@D0mD6v10 ай бұрын
Very true :)
@maxave74488 ай бұрын
The advantage of open-source is that some 30-year-old programmer or uni student somewhere is going to get tired of some bug eventually so much so that they will just go ahead and fix it themselves. With stuff like Unity you first have to write a bug report, then pray for someone to read it, then wait until a developer gets a ticket to fix the bug and decides to complete it, then wait a few months until the next update… At least thats what I heard
@ivanonlyone71607 ай бұрын
@@maxave7448 Sorry to disappoint, but hundreds of pull requests from many experienced contributors are being rejected for no reason. From bugfixes to full features. Re-add removed 3.5 fog to 4.x versions? Optimize render? Implement official obfuscation for game's security? Fix ancient bugs? Nah, let's add a cinematic mode!! So, Godot is not objectively better, it has very bad shits too.
@cryelectric10 ай бұрын
When the next American CEO goes crazy, you too will know: Godot is better than unity!
@D0mD6v10 ай бұрын
hahaha love this
@madjunir10 ай бұрын
The CEO is like 30% of the problem and is usually the sacrificial lamb . The Board is the one to actually approve or run everything behind the scenes
@basicgamedev2 ай бұрын
nope unity is way better than godot in optimization and 3d etc .....
@pietraderdetective895310 ай бұрын
loved the well-balanced review. Yeah I agree there are still work to be done with Godot, but with the current state of development I'd say it's going to be much improved by next year..and hopefully will accommodate Unity users better as well.
@D0mD6v10 ай бұрын
Well said!
@liolyne10 ай бұрын
Also coming from Unity to godot and using C#. I agree on a lot of points but you forgot to mention something important that Godot has over unity : Signals. It is way easier and way less verbose to use Signals than Unity Events.
@thecodec10 ай бұрын
I've never used Unity but I'd like to give some alternative solutions and explanations to some of the issues shown in the video: - Creating a mesh with collisions: There are two ways of doing this. The way shown in the video or using the CSG (Constructive Solid Geometry) nodes (CSGBox3D, CSGSphere3D,...) The second option (CSG) is more suited for prototyping levels in the editor and it let you enable collisions to the created meshes without needing to create a CollisionShape3D or CollisionPolygon3D. There's a tutorial on how to use these nodes in the Godot documentation. Also, the reason the CollisionShape3D shares the assigned Shape3D resource when duplicating it is because Resources are reference counted in Godot (Shape3D extends Resource that extends RefCounted), meaning that they point to the same object in memory, so editing any of them will edit the same object. If you want one of the resources to be unique, right click over the resource (or press the v icon next to the resource) and select "Make Unique" this way it will create a new object. Almost everything that isn't a Node is a Resource in Godot (textures, meshes, shapes, sounds, animations,...) - Invoke a method after time: There's a couple ways of doing this in Godot. One of them is using a Timer node and listening for its timeout signal. Another one awaiting for a internal timer created from the SceneTree. The second method is a bit cleaner in GDScript but it can be done in C# too: In GDScript: await get_tree().create_timer(1).timeout print("I waited for 1 second") In C#: await ToSignal(GetTree().CreateTimer(1), "timeout"); GD.Print("I waited for 1 second"); There is more info and differences between GDScript and C# in the documentation. - Not able to edit custom types in the editor: This can be done by making your class extend Resource. It's similar to ScriptableObject in Unity. So, for something like the example in the video it would be: using Godot; [GlobalClass] // This will let you create the Resource from the editor public partial class Fruit : Resource { [Export] string name; [Export] int amount; // Add needed methods, ... } If you then want to add this Resource to a node and be able to create/edit the resource from the editor you'll need to export it as: [Export] Fruit MyFruit; Again, more info in the documentation. - Raycasts are over-complicated: The preferred method in Godot is to use a RayCast3D or ShapeCast3D node that simplifies raycasting. - There's no root node: In Godot, this is not generally needed if you follow a simple rule of thumb: Call down, signal up. If you need to communicate with a child node use GetNode("child") (or similar) and call a method in it. If you need to communicate up the tree to some parent node use a signal. This way you'll be able to self-contain the objects that make up your game (scenes) into smaller units that can be tested by themselves. - Rotate GPU particle: You can make particles rotate in the Y direction by enabling Particle Flags/Align Y in the ParticleProcessMaterial or by changing the transform align of the GPUParticles3D node under Drawing/Transform Align. You can also change the angle and rotation for meshes changing the Billboard mode of the mesh material to Particle Billboard - AnimationTree state machine transitions: I only tested this using GDScript so I'm not sure if it will work in C# but you can have complex expressions to enable or disable transitions. To do this you'll need to use the Advance Expression field of the transition in the editor. You'll also need to point the Advance Expression Base Node of your AnimationTree to the node which has the values you use in the expression. For example, you'll point that to your CharacterBody3D which has the isRunning bool value and set the Idle -> Running transition Expression field to isRunning and the Running
@SirRichard9410 ай бұрын
Good comment. Gj
@adelsalem154410 ай бұрын
Your so talented when it comes to modeling and coding id love to see more of the game, im a godot fan but i only work with 2D so its nice to know what the engine is capable of
@D0mD6v10 ай бұрын
Thanks :)
@kartopod10 ай бұрын
4:27 Godot actually does have something for this! Its a property or method called 'owner' or 'get_owner',i cant remember off the top of my head, but it does exist!
@wellhellotherekyle10 ай бұрын
Wow, you're super talented! This quick project is looking super polished already. :)
@D0mD6v10 ай бұрын
Thank you! :)
@JoeSondow10 ай бұрын
I don’t have much Unity experience so I don’t know what I’m missing in Godot. I’m glad folks like you can enumerate the things you miss so Godot devs can prioritize adding more of those features.
@TechCowboy9 ай бұрын
I've only just started with Godot and I was a beginner with Unity. I left Unity because I have trust issues now that they've been caught twice changing the EULA after a release. I agree with most of your comments, especially moving of scripts! Thank you for letting me know how to fix this annoying problem.
@Klayperson10 ай бұрын
It looks like what you're looking for when you talk about Root nodes is the root of each individual scene instance, which would be the Owner property. It comes in quite handy. However, seeing what you're doing on 4:44 tells me that you have yet to adopt the signal-based philosophy of how things should be done in Godot: instead of having this function that detects a hit *and then has to know about the tree structure of another object*, you should just have this function cause BarrelCollider emit a signal, and have what I assume is its owning Barrel scene connect to that signal, so that it can respond appropriately when the barrel collider is hit. e.g.: // I assume this is the callback connected to some body_entered signal public void HitObject(Node3D other) { // do nice type checking instead of string name if (other is BarrelCollider barrelColider) { // TakeDamage would be a custom signal declared in the BarrelCollider class // The barrel scene root node connects to its BarrelCollider's TakeDamage signal for functionality barrelCollider.TakeDamage.Emit(100); } }
@Klayperson10 ай бұрын
in general you will hear the Godot mantra "Call down, signal up" meaning - Parent nodes call methods and access properties on child nodes direclty, because parents know their children - Child nodes emit signals, because they do not know their parents; it is the parents' job to connect to child signals in order to respond to information and events from them
@trickster7215 ай бұрын
4:19 I think the equivalent of "root" is the "owner" concept in Godot. By default the owner is the root node of the prefab. Godot encourages you to make things into prefabs and variants a lot earlier in development, rather than keeping a lot of unique ad-hoc objects in one scene file and just imagining them as separate entities, which Unity sort of enables.
@surplusking24254 ай бұрын
You don't actually need a timer because you can just use _delta value at _process method. If you want separated 'function' to do something in interval just use signals instead.
@syphonunfiltered2 ай бұрын
Which version of Godot was this? I see that @export allows you to export variables to the UI so you can easily tweak it, in Godot 4.2.2
@theCursedKiro9 ай бұрын
Hello. Just to clarify some thing To make a cube there a two ways that I am familiar with (applies to other objects) 1. You create a CSGbox (or appropriate object) which gives you the box and you can enable collision and be done and scale to your liking. 2. Add a mesh instance, in the properties menu add a Box mesh, in the top panel press the mesh button and select the 'add triplanar' This will generate the other nodes as children of the mesh instance node for you, but you have to do this every time you change the mesh in question and delete the old nodes you generated previously. You are not exactly force to work in a modular manner, but if it is what you want you can set it up early on, such as a placeholder floor mesh that you can swap out later when needed without having to redo the nodes it makes it possible. In regards to the scripts, you can have a script that other scripts can inherit from. Say you have a gun script, you can have a shotgun script, a pistol script, and so on each with its own set values such as damage range, clip size, bullet mesh and gun mesh. Same can be done with states, while for beginners can be a bit to wrap your head around, but it does allow you to keep the scrip shorter where there really s no need to lump everything into a single script file, but you can still do that as well.
@TheDiamondCore10 ай бұрын
Holy crap, 2 weeks of Godot and already making something like the scene you made is impressive imo, good job!
@seth-blank10 ай бұрын
Agree with all these points. And from a person who favored Godot before Unitys downfall. Great vid as always :)
@D0mD6v10 ай бұрын
Glad you agree. Thanks :)
@martinchya25462 ай бұрын
I think you might be a bit Unity biased. That is, you seem to seek an "Unity way" in your workflow, thats why you might not like Godot. 1. I agree you cant easily add simple cubes, but that would be a little bit against Godot workflow. How it should work? Should we have a "special" node for this case? Or a possibility to add a preconfigured bunch of nodes with a single click? It just doesn't seem to fit there. 2. Custom property editor - this is a feeling I shared with you, before I dived deeper into Godot. Actually, Godot allows you to do this but you must extend Resource class. It MIGHT seem limiting, but I actually like that. Because in Unity, serialization is full of quirks and you must learn how to make it (simple class is serialized in owner object, scriptableobject is an asset, some fields are serialized, some are not, public fields go serialized as default, you cant serialize dictionaries, etc.). In Godot its very simple - in order for something to show in inspector or be saveable, it must inherit Resource and it is very explicit about what is serialized and how. And you might nest resource in resource if you want. Also, you can write/read resources in runtime. It is very explicit and simple and after some time, I like it. Also, you can either inline resource inside other container (like scene) or you can save it to disk so it will act as ScriptableObject in Unity. Its actually very clean solution. 3. Root Node - this is good in longer run. You should not use GetParent().GetParent() etc; instead your parent should either reference its children or listen to its signals. Usually, you would want your global scene to be singleton, like you could have Root->Game and Game should be singleton. Everything related to game should be in Game node. Look at "Game" node as a Scene in Unity. Again this is workflow difference, but it makes stuff more clean in longer run, in Unity everything is in some sort of "global scope", Godot forces you to keep your node hierarchy intact. 4. Component vs Nodes - Unity is component based but you can do it in Godot as well. Its just that in Godot, you program a bit different. In Unity, GameObject is a bunch of components glued together, while in Godot your Node is your "main" class that has its own helper nodes (either built-in or your domain-specific nodes) encapsulated in itself. Usually, you should not access child nodes of your Node outside of it. Everything you need should be exposed in your node, and it should keep its internal details inside. See child nodes like "private members" that are not accessible outside.
@l.halawani4 ай бұрын
Really enjoyed this video! I've been working on game development, focusing a lot on prototyping and trying out different concepts. Finding the best ways to use the GUI and workflow in both Godot and Unity for 3D has been a bit of a challenge. This video hit all the right points for me, clearly highlighting the important aspects and making comparisons easy to understand. It's super helpful and exactly what I needed. Thanks for sharing such valuable insights!
@retrowave6915 күн бұрын
You can drag and drop items into your script in order to have the engine instantly give the path to the object. It's much faster than typing all that mess out.
@tudor748610 ай бұрын
godot needs to get stronger so no proprietary engines try again to pull an unity move (glad the Unity CEO got fired for it) . Unity needs to get stronger to keep godot community sharp and focused to make it the best it can be - like blender evolved I guess . Im new to this game dev thing but love godot so far . Competition is great for everyone .
@D0mD6v10 ай бұрын
Agreed Competition is good :)
@RenceAsANoob10 ай бұрын
There are still the board of directors, the CEO is just a scapegoat.
@zORg_alex10 ай бұрын
I had my doubts in Godot, but on 4:00 I realized, that I'm not touching it. I am too used to neat and optimized code. I'm not writing this kind of shit. All my professional strings are screaming in agony from sight of this.
@D0mD6v10 ай бұрын
Haha I totally get where you coming from
@husseinkobeisi50225 сағат бұрын
I recently moved from Unity to Godot after Unity crashed a ton. And I have to say, other than suffering to make cubes and 2D sprites Godot is really smooth sailing. My dude here nerfed himself by not using GDSCript, i grew to like it very fast, instead of having several scripts attached to each object, in Godot you already have a node to do anything (eg raycast) even set a timer. And connecting your main script to these nodes is made so easy.
@Alexander-mk4qf10 ай бұрын
i like godot more then unity for 2d unity is still my favorite in 3d unreal is weird for me, i start from unreal 4 when its came out ...didnt see anything new from 5 years ago...so godot is go up, unity is go down...unreal stand still for years and have money problems now because trying to do to much..like movies ...unreal not even try to progress in 2d..people do plugins...its so lame this is why i go godot for my mobile 2d game..i will switch to unity if they change course for my 3d game..if godot made no progress in ver 5
@matrixfull10 ай бұрын
One can always suggest improvements to Godot community. Developers of Slay The spire (Megacrit) did that recently so this way engine will improve. It's community project that is in strict legal terms protected against greed aka Unity situation ( coz of how their special licence work ; it's quite unique in marketshare of game engines ). So yeaa on long term I believe if everyone does something to contribute either by spreading the world, suggesting solutions and so on it's gonna snowball and it'll become game engine of the future. Sorta what Blender has become in its field or well OBS. Future is exciting and free.
@icecrystals285510 ай бұрын
7:46 - Moving Scripts caused an error with scenes It turns out that if you have any scenes open, and you move a file that that scene uses, it won't update that scene, and will cuase it to crash, so just make sure all scenes are closed before moving any files.
@jamolov_xoja10 ай бұрын
JUST WoW
@D0mD6v10 ай бұрын
Thanks!
@aryantzh202810 ай бұрын
unity is popular since 2014, unreal is popular since 2016 and godot being popular since last 2 years ago. its a great start, just wait for another updates because every updates has a big update
@aryantzh202810 ай бұрын
yes, i know unity existed since 2005 and unreal existed since 1998. but in 2014 and 2016 they announced something big that the engine is free for all users so in that time many indie games was born
@emilstumme96459 ай бұрын
this video is BY FAR better than any of the other comparison videos!! even though you are obviously biased, I feel you were completely fair. :D you had a couple uh-ohs with missing features that fix ur problems, but that just highlights how godot needs to improve on letting beginners know its a thing!! ESPECIALLY since you are no beginner to the programming world, only to godot.
@wagfeliz10 ай бұрын
At 3m, you can use tweens to do that, and much more.
@othmanalq98495 ай бұрын
Youre a legend. The only accurate godot review on the platform. I love all your videos and wish you all the best
@Volt-Eye.4 ай бұрын
Funny thing is, 🤖🤖 You don't know any of Godot's Methods to do stuff and still Comparing Godot's Workflow with Unity's
@icecrystals285510 ай бұрын
2:05 - There's live runtime scene in godot. When running a game in the editor two options appear at the top left of the Scene dock, Remote and Local. While using Remote you can inspect or change the nodes' parameters in the running project. Basically, equivalent to Unity runtime hierarchy.
@TalhaHussain-fm4chАй бұрын
You can right click and the collision shape where you set the shape and select "make unique"
@snarkbucham40776 ай бұрын
I’ve been using Godot for years, but I’m not a programmer, so I’m making progress in fits and starts. I’m learning more from the comments on Godot critique/analysis videos, like this one, than from godot documentation.
@scotmcpherson10 ай бұрын
There is a root node, it’s just hidden. You can still reference it and make children to it.
@natanmaia357528 күн бұрын
4:17 to find the root of a Packed scene, use the ``owner`` keyword. So, in a player state child of a player packed scene that's inserted into a level packed scene, that state's owner is player because it was saved together with player in its packed scene. When you create a new node at runtime its owner won't be its parent, so you can change that manually with .owner = Also no, don't use get_parent() a million times, that's noob behavior even in Unity. Create @export fields to save references of the nodes you want and connect them in the editor or at runtime, like SerializedFields.
@Yogoda12710 ай бұрын
I don't know in C#, but in GDScript there are at least 2 ways to delay a call: create_tween().tween_callback(your_method).set_delay(1.5) await get_tree().create_timer(1.5).timeout your_method but I agree something easier would be welcome 🙃
@D0mD6v10 ай бұрын
I'll check this out. Thanks :)
@kartopod10 ай бұрын
Solid video, good points, good pacing, wastes no time. Great job!
@D0mD6v10 ай бұрын
Much appreciated!
@fefeman285610 ай бұрын
1:26 You can simplify the steps of this by just puting the meshInstance node, selecting the mesh options (above the viewport), and clicking "Create trimesh static body". It'll put the static body as a child of the mesh, meaning you can scale the mesh directly without affecting collision. It's an alternative to the "CSGBox3D" trick that work with custom meshes.
@AkaSilentCreed3 ай бұрын
I've been 100% fine watching any Godot tutorial and just translating whatever is said into C#. As long as you know a few differences in the way they handle things (like events/delegates) you are good to go. Simply remove the _'s for the method names and use camel case and you will find it.
@jesusmora937910 ай бұрын
you are wrong on a few things: 0:35 unity has taught you wrong. you are NEVER supposed to use the primitives in an editor, those are just for prototyping and debugging (and maybe some other things), and godot has CSGs for prototyping. the workflow is to create your mesh in a 3d editor like blender, you can also create your colliders here. then in godot you create ONE staticBody3D for each specific part of the scenery, and then add your colliders. the reason why the unity way is wrong is because it's faster to send a single high poly mesh to the gpu than to send several hundreds of simple shapes like cubes, this is also a problem in unity where having too many cubes and collision shapes will have an impact on performance, so the way to do it is to create a mesh with your rooms and terrain in blender, maybe also a collider, and then export it to godot. there's also a button in mesh to create convex, concave and copy of mesh colliders automatically. It's by design. the other time where you would need to do this would be with rigidbodies and moving parts, but at that point you are saving those to a scene and adding a script, so it's not that much more work. the way godot does it is better and safer, because you never want your mesh, code and colliders in the same object, so your physics object moves your mesh and collider, and those are separate from each other. but if you REALLY want to do it that way, scaling a parent object does work... I've tried it. 1:54 godot is objectively more tidy than unity's components, less prone to errors and mistakes, faster, and easier to debug. it forces you to code *the way you are supposed to code* , by splitting big structures into smaller, self contained parts. 3:39 no they are not. you just have to use a raycast *node* . then have raycast.is_colliding() and two more methods that return the hit object and point respectively. you can also change the properties in code. this is better than unity where it is ACTUALLY *overly complicated* (you have to create a hit object, then do hit.collider.gameObject and hit.collider.point and check if it's null all in the same reference). 3:58 everything inside godot works with dictionaries, it's faster internally. your problem is you are using c#. gdscript has very good integration with the properties and paths running in the editor. it's a tradeoff of trying to use c#, it runs faster but coding is more complex. gdscript runs less fast but it's easier to use. 4:17 bad coding again. you should NEVER, EVER test for names of objects, in godot, in unity, in unreal, or in any engine. you have groups and functions like has_method to test nodes. you have meta_data. use the interfaces provided by godot. 4:28 you define that per scene, by creating a reference to another node in the local scene beforehand. I don't know how it's done in c#, but in gdscript you either drag your nodes and files, or type it, like: @onready var mynode = ".." but again sound like you are coding it wrong, they say you are supposed to "call down, signal up". 5:10 you can totally rotate 3D particles in godot... also the particles in godot are superior to unity, they can spawn physical particles that collide with particle colliders and are affected by attractor nodes, and you can create a custom shader if there's any feature you are missing. 5:47 WRONG. there are FOUR ways to do transitions in godot. 1 - through bools like in your example 2 - automatically 3 - through the "travel()" method 4 - and this is not documented so ill explain it to you, though expressions: first you select (in animation tree) an expression node, this node must have a script. there you put export variables. second, go to your transition and write an expression, you can use *any* variable in your script. an expression is a single line of code in gdscript that returns a boolean value. they can be: isRunning # a single boolean variable not isRunning # equivalent to !isRunning isRunning > 0.6 # evaluation of a float isRunning == 1 # or any type velocity.y < 0.5 # internal variables of your script isRunning and velocity.y > 0.5 # combination of variable evaluations i[0] == 0 # dictionaries and arrays in theory you could also call a function, but I need to test this. also, changing these export variables or the parameters can be tested *in real time* , the animations will transition given the expressions *inside the editor* godot animation is FAR superior to unity's mechanim 7:10 the particles system has trails for that. and there's the ribbonTrailMesh primitive. 7:42 when using c#, you need to compile your code in order to be able to see the exported variables
@moneyisenergy4 ай бұрын
thank you for this amazing video I am looking to restarting gamedev as I used Unity in the past, am very inclined to try out Godot
@ThotTee10 ай бұрын
The most unity user trying to force the unity experience in the godot, and they don't understand that godot is not unity! After this they talk about the experience of godot, what is based on some week of missing knowledge of godot. Compare the two engines together is pointless in that way what software is better. This 2 engines are total different in the logical structure. There are a lot of failed opinion in the most "unity dev tried godot", because they don't know the engine. Godot has tons of "hidden" features, what several old godot user don't know too. I use it from 3.0, and i still find tricks what i didn't know earlier. So why unity users think it they can make a valid opinion with some week experience. Sorry for my harsh words, it's not personal. Just i saw a lot of pointless video in this topic. I'm really glad if somebody is open for the new things, and they trying new softwares. I tried more than 10 engines, and every engines have good and idiot sides, and most of them aren't better than any other. I welcome all people who give a try to godot, or any other engine, but before they make compare videos from it, learn about more from them.
@ThotTee10 ай бұрын
the problem is, this video is full of wrong arguments and comments, like most of them, due to the fact that you obviously don't know enough about the engine.
@ThotTee10 ай бұрын
I don't want to offend you with this, because otherwise you are pleasant to listen to. rather, I wrote it precisely for this reason, and I trust that if you are interested, you will devote a few more years to godot, so that you will know why so many people love it.
@mrjshzkАй бұрын
This comment just feeds into the hivemind idea of godot users. Just because you don't know the best way to do something you can't comment on it? I believe the video having something wrong is actually not bad and just goes to show how important UX and intuitivity is
@Sylfa10 ай бұрын
Regarding the GetParent()^3 chain, is it the owner property you're looking for? It can be changed to specify which node instantiated the current one, and by default will point to the scene root of the scene that defines it, allowing you to get to the "root" of each "prefab."
@surplusking24254 ай бұрын
All you want is just get a 'root' node then just use get_root() function.
@JACKRIDERPLAYZ10 ай бұрын
I think that there is no such thing as a game engine being better than another. Certain engines do things better than other engines. Unreal Engine does it better with graphics. You can achieve these levels with Unity and probably Godot but it's just harder and more time consuming. Unity and Godot both do 2D quite well. But a lot of people would say that Unity does it better or that Godot does it better. It's all preference.
@D0mD6v10 ай бұрын
I agree, it really does depend on each dev's requirements :))
@jesusmora937910 ай бұрын
no, there are engines that are better than others. it of course depends on what you need. I would argue that unity is the ADHD of game engines, where it not only tries to do everything at once, be an indie dev tool, a hobbist engine, a platform for s*ty steam games, and a AAA engine that lacks all the features, but also does everything wrong because the base over which it's built is not very sturdy. and this is because of bad management, the executives wanting the engine to compete with everything while adding random features nobody asked for and giving them "special names" to trademark. godot is more lightweight and the devs are not afraid to remove outdated functionality and deprecated methods or rework entire parts of the engine, but it's also built over a sturdy base that is actually designed to do everything. an example of this is how godot has dedicated 2D and 3D engines that are mostly independent from each other, and can take advantage of powerful UI systems over the 3D environment. while unity simulates 2D by looking at 3D from the side, so it has a lot of wasted variables and functionality running when they are not needed. or how everything in godot is inherited from something else, so all the nodes are compatible with each other while not wasting memory when not needed. AnimationTree is a node that exists in the tree, but it doesn't hold positional or rotational data, so adding more nodes doesn't feel like a waste.
@JACKRIDERPLAYZ10 ай бұрын
@@jesusmora9379 I don't know much about Godot but it does sound like an amazing engine. Especially if it's open source
@mrbonono295110 ай бұрын
All of these criticisms are valid, not being able to attach multiple scripts to a single node is silly, the scaling from a static body and a mesh etc. not all being scaled is also silly, and duplicating the nodes not being unique is silly as well, although there is a solution to that there is a way to separate the nodes from each other when duplicating them somewhere you can "make unique" the node and they no longer share the same values between each separate other. Being able to criticize aspects of the engine for growth and I hope there are solutions to some of these in the near future.
@Sylfa10 ай бұрын
For the negation of the condition, the request to add that functionality was closed because the "AnimationTree Advance Expressions" would resolve it and add more flexibility. Unfortunately the expression feature is poorly documented, with the best description being the pull request itself at the moment. However, the idea behind it is to *not* use the blackboard flags like "isRunning" and instead use properties from the script itself. The example being "velocity() > 0" to determine if it should move from idle to running. Like I said, it lacks a lot of documentation and I can't find a tutorial, so you'd have to test out how it works with C#
@D0mD6v10 ай бұрын
Interesting I'll have to look into this in the future :)
@ZEN46710 ай бұрын
there's a make unique option for making each collision shape unique edit : Also you can use await to get the same result as you get from unity's invoke function
@ghostradiodelete9 ай бұрын
I switched to Godot from Unity (2nd time building my game in Godot, I originally did it in 3.5). At this point I'm back in Unity because I can't make any progress in Godot. There's a bug which makes using "remote" to debug the scene impossible after a certain number of Node3D are added. I think I have about 578 on one floor of the dungeon and that basically means I can't see where objects end up, or switch them on and off to test things, or even just generally see if items are being added where they should be because remote is entirely useless at that point. So, I'm designing in Unity and testing meshes and things until Godot gets fixed, which I know it will at some point. Oh and I'm also a C# Godot dev.
@xymaryai82837 ай бұрын
if you can implement instructions with subscripts, then you could make plugins that completely overhaul the scripting flow with more intuitive beginner friendly instructions, at the cost of performance, since an instruction is made of several instructions to translate it to syntax Godot understands
@HuangShengHong8 ай бұрын
I love Godot because it's modular nature. Yes, things get complicated, but there's likely a workaround for everything because of that. I've run into projects that needed runtime loading gltf files, and processing live bvh streams, and on top of that syncing them in multiplayer. I'm surprised that Godot can handle those purely in GDScript, although it took thousand lines of code + few weeks to accomplish that.
@DunnoWhoIAm54617 күн бұрын
ahem there are some stuff you can do but you dont know so you thought godot can't.... First [Export] var variable = 6 this is the syntax to see custom types in the property editor, read the documentation
@12kenbutsuri10 ай бұрын
Short answer : yes. Long answer : yeeeeeeeeeees
@jorgiz010 ай бұрын
Hey buddy, lemme just tell u you r comparing more than features, you are also comparing experience. I mean, u probably have years of experience with unity so you know straight foward how to do what u want. As for godot you are still learning where are the tools you need and what they can do for u. Important to remember that, as different engines, they don't have one-to-one translations. Both have their own ways of doing things so yes, there will be things you can do in unity easier than in godot and vice versa. If you keep your interest, what u think of remaking this vid after some time of experience just to look back and see how far u got? Awesome video, keep the good work :D
@KutGames7 ай бұрын
Just discovered you, great stuff. But please reduce the BGM volume or use one with lower BPM :P
@Stmate0310 ай бұрын
Recently joined godot user here: I'm not very versed in C# as I also failed miserably in unity so my opinions might be skewed as I actually got things done in Godot as opposed to Unity To really summarize this video I think if you used Godot first then unity you'd make the same video and say the same complains about Unity, most of the video is just preferences and in general the video conveys that compared to Unity, Godot is an okay engine, that sure needs some extra features here and there but somebody out there will see this video, agree, tell the dev or code an addon that does exatcly what you want and it's just fine, such is the wonders of open-source, still a really nice video on what to expect when transitioning as a veteran, as I was unity noob I didn't get this feeling of "oh god this is way different" But yeah overall a great video on what to expect when switching :D
@draftingish48336 ай бұрын
Just FYI, I think the Export in the editor issue might only be a C# issue as GDScript Definitely allows it. The few weird issues you had don't happen in GDscript, like updates in the inspector, but it would be nice if C# would do that better I ma sure
@3d_smart7 ай бұрын
for invoke in godot there is timer node after amunt of second you specific code will run what ever it
@UnityGamer20774 ай бұрын
Godot is great, but I just can't live without Cinemachine & New Input System
@LetterlessAlphabet3 ай бұрын
I would agree with you until this week when I used godot again after a long time using Unity. Godot action system is VERY similar and there are free plugins like Phantom Camera that are based on the cinemachine workflow. Seriously I’m amazed at how far this engine has come in such a short time. Its all so clean and light 🥹
@user-ps9qd2pf2j10 ай бұрын
With exported variables you need to select a different node then click the node you made the variable with for it to show
@dotkio10 ай бұрын
In Godot, you scratch your own itch. If you have a problem or bug, just fork the repo and fix it.
@D0mD6v10 ай бұрын
Very true :) It's a bit too in-depth for me though haha
@igorthelight9 ай бұрын
Alternative route: find a Godot plugin developer and ask him/her to make a special plugin for you ;-) If it's not that complex - it may just cost you like 25$!
@leonardoraele7 ай бұрын
You don't need to create a new scene whenever you want to make resources unique per node. That would be stupid. You just have to click on "make unique".
@dylantocco658210 ай бұрын
in godot 2d Vector2.up is (0, -1) for some reason. Its not a problem, its just weird
@D0mD6v10 ай бұрын
Ohh Interesting. Similar issue with the forward direction in 3D
@red3tango10 ай бұрын
Was just a design decision based on underlying technology. Example in Windows, coords are from the top-left of the screen, the same coord system Godot uses. Same with 3D, -Z is "forward" as OpenGL +Z brings the rendering to the "front" (toward viewer)
@igorthelight9 ай бұрын
It's hectically correct! pixel (0, 0) is the top left corner!
@kartopod10 ай бұрын
I was thinking of looking into using c# with godot, how long are the compile times? Ive been loving godot due to how fast i can iterate, but i just found out c# had compile time in godot too
@Klayperson10 ай бұрын
C# always has compile time because C# is a compiled language. But it is fast, on the order of mere seconds. AFAIK Godot also does incremental compilation, which I have heard Unity does not (it has to build the whole project assemblies every time??) - In general, I keep seeing Unity refugees elated with fast build times even when using C#
@kartopod10 ай бұрын
@@Klayperson Okay thats awesome to hear!
@u9vata10 ай бұрын
I will be honest: most of this video is "trying to use godot like unity". Its already fascinating you can somewhat do that actually... try doing between unreal and unity to realize why it is. Exporting variables work for me in gdscript and I am pretty sure there is some solution in C# - but I just don't know what it is.... likely this is because you tried to use the less documented C#... I am not saying its flawless, but real test would be a class of students first touching godot / vs. class of people first touching unity. Also there is a neat side-effect for Godot already much better for 2D: That most real starters start with that and then when they are already familiar with node structure and "godot way of doing things" 3D again is not at all bad. That being said, the community is still thankful so you made such video, because there are still some lacking parts AND when it is not lacking (its easy to create a box with CSGBox3D for example), the community might get feedback to advertise those features better in documentation or on gui or whatever. Oh and about not having "root node" just for the scene. I think you misuse godot "as if its unity" again in that you DO should CREATE SCENES for smaller parts of your project that make a sense where you want this feature. Then for that smaller scene it works exactly as you wished for. This is more of a "how you structure your project" kind of thing that you inherited from unity being clumsy for scenes, prefabs, gameobjects just being different... Also you can just refer to nodes of the scene (at least again this is easy with gdscript) by name or path and even drag&drop that into the editor. So I think you should in this case just accept it is different - and honestly I used unity before too and I find this godot way much more logical. But I might be also heavily biased as I program in like 20+ programming languages, learned last major one in like a week and generally work in very moving environments ranging from embedded through cad / 3d and simulation through hiperf optimization through random web etc.... So maybe for me its natural for example to just learn gdscript (as its basically just a variant of python and is better supported so I did that path despite previously using unity for AR mostly in C#) but I see some people like the idea to stick to languages. Its not really that different when you code in a different language - after the first 2 or three its very easy to just pick the best available - without the need for comfort.
@Stunex10 ай бұрын
100% agree on everything said in the video, so far this has been pretty much my experience as well. But I disagree on Unity's direction. I think the engine is now actually in a way better place than before. Unity (the company) is still not profitable so they had to change something. The initial plan was of course beyond stupid and hostile, so they deserved every bit of criticism and backlash for it. But with the engine department generating more revenue I think there will also be more funds available for its development, which is obviously good. And the revenue threshold for the Personal license being increased from $100k to $200k is also way better for indie devs + you can still sell about 1 million copies (which is probably your best estimator for "initial engagements") before you have to pay even a cent for the runtime fee. If your game costs even $5 per copy you could make about $5 million in revenue before you have to start to pay royalty (at this point Unreal would already ask for $200k in royalty). Free mobile games probably suffer the most here. But if any of this is a concern to somebody I'm not trying to prevent you from Godot, just thinking that people misjudge the situation for Unity's community (in fact, I'm still trying to get into Godot, maybe I can get used to the workflow and it suddenly clicks - always good to branch out in your knowledge anyway). Which has proven to still have a say. Also, I don't necessarily need to trust the management (I don't really trust Godot's management either btw - aka Juan and some maintainers) because I trust the community and I think the prospect of losing 26% in stock value (and still being in a downtrend) is a big enough deterent for scummy execs to try overreaching again. With version 2023+ being a rather hard sell (probably) I could imagine that Unity is now more incentivized than ever to actually improve a lot of the engine features so devs actually want to switch to the new model. And I don't think Godot is ahead in this department as its "management" is allegedly blocking quite a bit of progress with the engine too, especially if it is not "accessible" enough - which may hurt Godot going forward imo. One of these examples is a 3D terrain, which I've read some people discuss on the Godot subreddit was basically because Juan didn't think was an important feature to have.
@saulsantos41329 ай бұрын
Who you read that from? Juan said no terrain in core , because there are many ways to do it.
@ShivanshBansal034 ай бұрын
3:35 @export is used to export var to property editor much easier than unity
@expectnull10 ай бұрын
For transitions inside animtree set complex expressions object in animtree properties, manage vars in script @selected obj and use them in the animation transition of the animatortree by typing boolean expressions however you see fit below the parameter field.
@expectnull10 ай бұрын
Note: not var (gdscript) = !var c#
@Rocknoob497 ай бұрын
Hmm iirc the root thing is generally a bad practice no? If you end up changing something in the hierarchy it shouldn't really mess up your code.
@Rocknoob497 ай бұрын
yeah for sure, don't do the parent stuff. Not in Unity, probably not in Godot although I don't use Godot yet. Instead, pass a reference via the inspector, or find your object through some sort of global manager, ID, whatever. something entirely unrelated to the "physical" arrangement of your hierarchy
@OminousHvh10 ай бұрын
you should do a video on the new Godot update
@LightVelox10 ай бұрын
I actually consider the Godot's animator inferior because even though it does have better support for sub-trees and all, it's really bad for things like checking for transitions, animation beginning-ending and all, while Unity allows you to attach an script to each individual state if you want, far more powerful in the technical side in my opinion, even if the animator tree itself is simpler
@geams10 ай бұрын
"I don't think Godot is more beginner friendly than Unity.." Wrong. The UI and prefab system in Unity is a beginner's nightmare whereas in Godot every scene is a prefab and there is only one UI system instead of three.
@Rahulsingh-theraha10 ай бұрын
and you can use it only ugui if you want ,it is production ready and works in almost every solution,UIToolkit exists to provide extreme flexibility in creating ui just like in web,if having a more robust solution is a bad thing ,then i can't say anything
@Ponald-hv2uw10 ай бұрын
I dont know i find Unitys Interface easier except for when it comes to Shaders those are a nightmare in Unity
@EvilGamesRb.10 ай бұрын
ayhan
@Samuel119597 ай бұрын
in godot raycasts are actyuly simple if you use gd script
@yuriaugusto10848 ай бұрын
I'm kinda sad that Godot it's so messy, overcomplicated and limited. I've been using unity for years but after the the new fee rules i was hoping that Godot become the new 'Blender' but for games but unfortuanlly our only choices are still Unity for Indie Games / Unreal for teams(big games with AAA graphics)
@ivanonlyone71607 ай бұрын
Very true. In Godot I won't be able to make the same game as in Unity. For example, making a large procedurally generated maze in Godot 3.5 was not performancely possible, because Godot didn't even have a proper CULLING!! A must-have feature in any 3d engine!! Also 3.5 couldn't bake lights on runtime... All generated location lagged as hell, even though it didn't generate that many objects. Same generated maze in Unity runs very smoothly. Also Unity is just better optimized than Godot. I was using Godot for a long while but jeez, Godot really lacks some basic features (that Unity had already for a long time), and in such cases you need to make your own workaround, or hope that it will be added in future versions.
@jamesforte537910 ай бұрын
Nice 👌🏾
@D0mD6v10 ай бұрын
Thanks 💯
@VitoPetranovicJokic-zx8jn2 күн бұрын
4:44 use sub scens
@surplusking24254 ай бұрын
Unity is suited for making simple games as fast as possible. Godot is suited for making complex games seriously for small to medium scale developers. Unity is great for simple 2D games while for complex games, it isn't great...especially UI. Godot is great for complex games and 3D games.
@oo--77142 ай бұрын
3d???😂
@Games2Dev8 ай бұрын
Godot is the winner! =)
@edward319010 ай бұрын
can't export custom class and struct is really the deal breaker for me. It's a basic feature that most engines have
@MrChick198410 ай бұрын
Ofc, you can do it in Godot. You can use either Resource which is Unity's scriptable object or named class, which basically adds your type to Godot and can be then used as Node in the tree, parameter etc.
@edward319010 ай бұрын
@@MrChick1984 it's hacky work-around that involves woth unwanted behaviour, not a solution. it's been asked by hundreds of people in github, for more than 5 years, but godot can't do it.
@igorthelight9 ай бұрын
... or just read what was added to Godot 4.2 Beta ;-)
@rexoverwatch7 ай бұрын
cool
@xderen_xd8 ай бұрын
Jah bless, but honestly as someone who is really into 3d optimization is better in my case to be that precise about each process of the rendering of a 3d object since in environments as webgl if you do a bad configuration in performance just because was easy all your game could be screw
@wagfeliz10 ай бұрын
The thing people comming from unit dont understand is that godot is more flexible, you guys want to create a cub, but with physics or not, and what kind of physics ? There is a lot of scenarios where you dont want rigid bodys. There is a lot of vicios you guys want to bring to godot, adding multiple scripts to an node is not good, you should think in extending components, not adding wires to it. In your case, first, if you want your character to have this behavior, you could add this in the main rigidbody script, or you could add an simple node controller with characteristics you define in the editor, or in runtime, try to clean this way of unit thinking from your mind.
@0xcpp9125 ай бұрын
Too many popping noises in the video overall. Just can't watch.
@dinok477410 ай бұрын
Godot will never break your heart like epic and unity
@D0mD6v10 ай бұрын
That's probably true haha :)
@CrowGamesDev10 ай бұрын
GODOT CUBE IS EASY. Why don't you just add a CsgCombiner node that you can enable collision on and all its children will automatically get collision and add CsgBox node or any Csg node as a child to it it easily allows you to resize it and you can duplicate it and it works great!
@Cunnah10110 ай бұрын
For animation using an AnimationNodeBlendTree works better than a statemachine I find. Oneshot acts like a trigger and transition works like unitys transition you set the states you want and call them. Even better you can have mutiple transitions from one node.
@jesusmora937910 ай бұрын
both are useful for different things, the best is to combine the two. for instance, a blendTree can do bone filter(masks), change animation speed, seek, blend2, blend3, and oneshot, on the other hand, stateMachine can do states and has really good control over transitions using Expressions. putting blendtrees inside states make sense to change states, the individual animations can be used to create smooth transitions between the states. like an "unarmed" blendTree state that goes into a "drawWeapon" animation, that goes into a "holdingWeapon" blendTree. on the other hand, you can put statemachines connected to oneshots or blend2, and change which animation you are going to play. it's an incredibly powerful system, the way you use it depends on your specific needs for your project. you can also NOT use an animationTree, if the object is very simple and only has one animation, you can just play it in the animationPlayer. godot doesn't force you to use statemachines the way unity forces you to use mechanim for everything.
@broshtheprosh10 ай бұрын
NO GODOT IS BETTER
@broshtheprosh10 ай бұрын
ok so i mean you should use what ever you want but sense that pricing update godot just got better