Is Godot BETTER than Unity? | 3D Comparison
Вставка
- Опубліковано 1 чер 2024
- In this video, I compare Unity and Godot and discuss why Godot can be considered better than Unity.
Let me know your thoughts in the comments.
Don't forget to like & subscribe :)
Follow me on:
Instagram: / project_rebounds
Twitter: / awakenstudiosnz
For business enquiries you can contact us via our website or email:
awakenstudios1@gmail.com
awakenstudios.co.nz
The outro music was by our older brother: James Forte
UA-cam: / james forte - topic - Наука та технологія
About making a cube, in Godot you can just make a CSGBox3D and tick Use Collision.
Sheshhh can't believe I missed this. I'll pin this comment. thanks :))
And why can't it just be called a cube, like in every other program in existence?
@@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
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
@@SoremwarCSGs serve this purpose, but I think the workflow needs work to make it smoother to use.
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
Alot of useful points. Thank you! :))
@@domevans_dev 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
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.
When the next American CEO goes crazy, you too will know: Godot is better than unity!
hahaha love this
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
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.
Very true :)
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
@@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.
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
Good comment. Gj
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!
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.
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.
Wow, you're super talented! This quick project is looking super polished already. :)
Thank you! :)
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.
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
Thanks :)
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!
Holy crap, 2 weeks of Godot and already making something like the scene you made is impressive imo, good job!
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.
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.
Well said!
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.
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.
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.
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."
All you want is just get a 'root' node then just use get_root() function.
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.
Haha I totally get where you coming from
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.
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
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#
@@Klayperson Okay thats awesome to hear!
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);
}
}
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
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.
Youre a legend. The only accurate godot review on the platform. I love all your videos and wish you all the best
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
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#
Interesting I'll have to look into this in the future :)
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.
Just discovered you, great stuff. But please reduce the BGM volume or use one with lower BPM :P
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
Solid video, good points, good pacing, wastes no time. Great job!
Much appreciated!
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
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
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
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.
With exported variables you need to select a different node then click the node you made the variable with for it to show
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.
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.
Note: not var (gdscript) = !var c#
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
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
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
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
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.
There is a root node, it’s just hidden. You can still reference it and make children to it.
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.
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.
Agree with all these points. And from a person who favored Godot before Unitys downfall. Great vid as always :)
Glad you agree. Thanks :)
you should do a video on the new Godot update
At 3m, you can use tweens to do that, and much more.
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.
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.
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 .
Agreed Competition is good :)
There are still the board of directors, the CEO is just a scapegoat.
for invoke
in godot there is timer node after amunt of second you specific code will run what ever it
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
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 🙃
I'll check this out. Thanks :)
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
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".
In Godot, you scratch your own itch. If you have a problem or bug, just fork the repo and fix it.
Very true :) It's a bit too in-depth for me though haha
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$!
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.
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
Godot is great, but I just can't live without Cinemachine & New Input System
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 🥹
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.
I agree, it really does depend on each dev's requirements :))
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.
@@jesusmora9379 I don't know much about Godot but it does sound like an amazing engine. Especially if it's open source
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.
can't export custom class and struct is really the deal breaker for me.
It's a basic feature that most engines have
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.
@@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.
... or just read what was added to Godot 4.2 Beta ;-)
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
in godot 2d Vector2.up is (0, -1) for some reason. Its not a problem, its just weird
Ohh Interesting. Similar issue with the forward direction in 3D
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)
It's hectically correct!
pixel (0, 0) is the top left corner!
3:35 @export is used to export var to property editor much easier than unity
Nice 👌🏾
Thanks 💯
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.
Who you read that from? Juan said no terrain in core , because there are many ways to do it.
i don't understand what are you talking about . somethings you said doesn't make sense . I'm a noob but the animationtree doesn't need this 5:53 and you can rotate particles ..
"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.
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
I dont know i find Unitys Interface easier except for when it comes to Shaders those are a nightmare in Unity
Short answer : yes. Long answer : yeeeeeeeeeees
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)
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.
Funny thing is, 🤖🤖
You don't know any of Godot's Methods to do stuff and still Comparing Godot's Workflow with Unity's
Unity is also better for multiplatsupport, especially for consoles.
in godot raycasts are actyuly simple if you use gd script
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
cool
ayhan
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.
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.
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.
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.
3d???😂
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.
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.
Too many popping noises in the video overall. Just can't watch.
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.
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!
Godot will never break your heart like epic and unity
That's probably true haha :)
NO GODOT IS BETTER
ok so i mean you should use what ever you want but sense that pricing update godot just got better
Godot is the winner! =)
JUST WoW
Thanks!