Composition is something in Godot that I feel like I've been greatly underutilizing.
@MrEnvisioner
9 ай бұрын
2:12 Just for people's clarification: the primary advantage of Godot's approach to "composition" (as Lukky puts it) here is twofold: 1. Godot's reliance on inheritance allows it to offer a large library of built-in tools for specialized use cases using a SINGLE, common API (everything is a Node basically). This runs in contrast to Unity having 3+ different APIs for every little thing. When Godot DOES offer multiple APIs for the same task, it's because they each solve very distinct, separate use cases. 2. Godot's node hierarchy isn't actually "composition", but rather "aggregation". Each node can exist independently of an owner, unlike Unity's MonoBehaviour type which depends on GameObject. This then allows Godot's 1:1 mapping between scenes and nodes via a root node. The aggregation allows easy refactoring of subtrees into their own scenes, the attachment of other scenes into the current scene, and choosing multiple options for customizing nodes (scripts vs scenes vs GDExtensions). They all follow the common Node API and thus make everything simple and intuitive. 3:28 "So that it stays clear in the composite" If you are not familiar with the Composite design pattern: that is what is truly being showcased here. The Node API is an implementation of that pattern and allows each one to serve as an abstraction of and/or aggregation toward a given subtree of nodes. There are also more interesting applications of this idea featured in the Godot source code. For example, whenever a Control node is added to the SceneTree, it will search up the tree for the Viewport node above it and add itself to a SceneTree group (like a Unity tag) specific to that Viewport node. Then, whenever the Viewport node detects an input event, it will get that SceneTree group and iterate over all the nodes inside it to call various virtual input handler methods on them (such as `_gui_input()`). This is how every single node in the SceneTree gets access to the different input handling callbacks. It isn't that every node is listening for input. They just each register themselves with the ancestral Viewport and the Viewport does all the listening/triggering logic. In this way, the nodes are aggregated into the Viewport subtree's logic. 6:34 While the documentation focusing on GDScript is an important aspect, the bigger reason to use GDScript is really the tight integration with the engine that it offers you and its lightning-fast compilation speed. When you use GDScript, you are able to iterate on logic INCREDIBLY fast, and that is honestly the most important factor WHEN IT COMES TO GAME DEVELOPMENT. In other industries, there are established patterns and solutions for most things that you'll need to do to achieve your goal. In game development, however, you're constantly tweaking things left & right to pursue an abstract ideal of "fun" you imagine in your head. Before you ever decide to code things up in a heavier language like C++ or C#, it can often be far simpler to work out what concrete logic you ACTUALLY want to have using a scripting language built with iteration in mind before then porting that logic to a more long-term, stable implementation that can contribute toward your own reusable framework. That is, in fact, how many Godot features will be implemented. Someone creates a prototype using GDScript and showcases it directly via a running scene or an EditorPlugin, and then with that demo approved/supported by others, they get to work on a concrete implementation in C++ to submit for a PR.
@nixellion
9 ай бұрын
2:12 In Unity you don't need to create a new class to combine 2 behaviours. You can add 2 components to an entity, just like you did in Godot. EDIT: Godot even has a full article written an linked in their very first pages of documentation comparing ECS to Inheritance, in which it explains that philosophically Unity is built around ECS and Godot is relying on more classic inheritance, and how its composition is actually done on a higher level. Which, according to Godot docs, is overall less performant, but is otherwise easier to work with etc.
@sacredgeometry
9 ай бұрын
Right its identical in unity. I always assumed that Godot copied it directly from unity
@roguestargun
9 ай бұрын
Unity doesn't actually use ECS under the hood. ECS is superior and classic inheritance has a lot of downsides -- to the point that many modern programming languages ditch it entirely (to their benefit). What Godot actually has is a tree node based inheritance hierarchy. Its not performant at all, but its amendable to authoring. Honestly, under the hood it could be replaced by an ECS.
@sacredgeometry
9 ай бұрын
@@roguestargun You dont sound much like you know what you are talking about. For a start the tree data structure used in Gadot and unity has literally nothing to do with the type system as its a separate in memory structure and could be done with (and is done with) practically self similar types. Thats not what ECS is fixing. Both unity and Godot relies on heavily on composition. They are architected very similarly in that regard. Also no many modern programming languages dont ditch inheritance or to their benefit ... yes inheritance is misused. Yes it can create large memory footprints and a lot of unnecessary cruft but you can avoid almost all of that in any system or language even unity by just writing better code. There is no reason most of your game logic cant be done with 1 step models. i.e. classes which derive only from the base object
@RayOfDust
9 ай бұрын
I just love how this whole situation is looks from the side. Like your evil step-parents kicked you out of the house, and some sentimental guys that found you on the streets picked you and now showing you your new home, the feeling of distress and relief is very similar.
@aomadeira
9 ай бұрын
I strongly believe that just explaining godot without comparing to anything is already crystal clear, godot is incredibly simple to understand!
@Lythowastaken
9 ай бұрын
For 2:15, thats not true. You can just simply create multiple scripts and attach it to one GameObject to modify it. There is no need to use an inheritance approach in unity.
@Stunex
8 ай бұрын
I feel like a lot of people who praise Godot and criticize Unity really don't have a lot of experience (yet). So far I have yet to come across a single example of something I could do easier in Godot than in Unity (at least for 3D). From what I can tell Godot is usually a lot more restrictive when it comes to structuring your project and code, especially due to the node system. Personally, I see this as a detriment but I can totally see how this can also be a huge benefit for complete beginners tho, as there is essentially 1 true way you have to understand and you know how the entire engine works.
@JingIeFett
9 ай бұрын
0:30 and 2:15 No, in Unity you would generally NOT create a character class and then inherit from it. You can do it that way, it's an option, but that's generally not how it's done. That's how you'd do it in Unreal. In Unity you'd break things up as components. You'd make a movement component, a behavior component, etc. and then use composition to create different prefabs by attaching different combinations of components.
@hbiblia
9 ай бұрын
En unreal también puedes hacerlo con componentes lo que pasa es que no existen muchos tutoriales sobre eso, pero trabajo de esa forma.
@JingIeFett
9 ай бұрын
@@hbiblia si tiene componentes pero los componenentes en Unreal son relativamente nuevos, la architectura de Unreal es diseñada principalmente con inheritance en mente
@samach
9 ай бұрын
There are multiple ways in Unity and C# to do what you are doing here in Godot without writing a new enemy MonoBehaviour class in order to get a modified movement (or other type) of behavior. My enemy could implement the IMovement interface and inherit from different base classes. Or I could simply put all movement functionality into different component classes, again using an interface, and attach them to my enemy game object as desired.
@3dsteveo765
9 ай бұрын
Thanks for taking your time to put this together. I've just begun making progress in Unity with playmaker but will now always be waiting for the next shoe to drop, the need for Unity to shovel money to shareholders instead of the engine. Maybe next they decide personal isn't worth it for the bottom line at all. It's good to have alternatives.
@NightFoxZero
9 ай бұрын
This video was actually very helpful. In the little bit that I tried Godot previously I hadn't really thought of making different behaviors be their own nodes. Doing it this way makes it really easy and modular and is just easier to locate rather than digging through tons of lines of code on a single script
@RayOfSunlight984
9 ай бұрын
5:04 "The window's window" 😂
@GeorgeNoiseless
9 ай бұрын
GDscript has more documentation right now, but if GDscript vs C# Godot tests here on KZitem are anything to go by, the community has to start working on C# documentation _stat,_ because those test show a significant performance advantage for C#.
@renynzea
9 ай бұрын
Not to mention if you use c# you could add a test project to the solution, and have code coverage. Not sure if it is possible to do that for gdscript or not.
@NihongoWakannai
9 ай бұрын
As an experienced C# developer I'm not really having too many issues. Most things in the API basically function the same way as GDScript but the name is just PascalCase instead of snake_case, so the GDScript documentation works for me
@RenderingUser
9 ай бұрын
not that much tbh only things that improved were c# specific functions. all godot api calls are bottlenecked
@platonicgamer
9 ай бұрын
Great tips, thank you!
@leonpijudo6875
9 ай бұрын
i start to use a composition approach in Godot using nodes as components and signals, and its great, so scalable
@mleii1169
9 ай бұрын
Super helpful, thank you.
@penonpaper7007
9 ай бұрын
hey man great video
@kritik_mb2144
9 ай бұрын
Somewhere in that twitter thread he answers someone about how to use interfaces in GDScript which is hard to understand/visualize in a practical way. Can you make a video explaining that, please.😅
@sziklamester1244
9 ай бұрын
I am totally new to coding and game making. I am trying to figure out and make something working in Godot but I have little to no time to do it but regardless of this I value the tutorials.
@puzzud
9 ай бұрын
Thanks for making this video. It's a good supplemental to Linetsky's posts. However, it's a better practice for the parent to relay what it wants to have manipulated by its child to its child rather than a child always calling get_parent. And if it can be done with signals--but sometimes it's not so easy or nice.
@jlewwis1995
9 ай бұрын
Well you can cache the reference to the parent in a variable right? So theoretically you don't have to call get_parent() every time, only once
@puzzud
9 ай бұрын
@@jlewwis1995 Indeed, in most implementations, getting the parent can be slower than one might expect. I would not surprised if that value is already cached internally when a node becomes a child. I'm speaking more on composition in design. But I'd be lying if I didn't call get_parent() every now and then ;)
@BrettStriker
9 ай бұрын
the parent then becomes too monolithic, you are using the components as lego blocks. instead of making the components require being under a specific parent, you can just add an export variable then assign whatever you want the component to control. if that means controlling the parent then assign the parent to the variable.
@FuzzballStudios
9 ай бұрын
I’ve heard it’s actually better to use the `owner` keyword instead of `get_parent()`. Less prone to error that way, as reparenting at runtime or rearranging in the editor could cause a crash if it’s looking for a property or method on a node’s parent; the node’s owner doesn’t change unless you change it.
@RenderingUser
9 ай бұрын
or better yet, just use a node_path export variable
@chillsavasniko
9 ай бұрын
un capo, lo amo
@albertolameira5224
9 ай бұрын
amazing content, thank you very much for this! I only have a question if you or someone could answer, in Unity you can have an open world game by rendering scenes around the player, so essentialy the world is a big grid of scenes, and not all are visible at the same time and Unity makes this very trivial to implement, is this also the case for Godot, or do we need to implement this ourselves? Thank you in advance! :D
@stephenharperisgay
7 ай бұрын
You have to implement your own chunk loading, yes. Pretty sure you need to implement chunk loading in Unity yourself as well. Unless you mean LOD.
@wattlefox
9 ай бұрын
good video
@shodanargie1574
9 ай бұрын
I didnt know Godot's creators were Argentinian or that the engine was made here. Nice
@monawoka97
9 ай бұрын
I feel like composition over inheritance is one of those things that sounds super good in theory, but in practice it can be difficult. You really need to consider how your behaviors interact to ensure they don't conflict. There are also difficulties with dependencies where multiple behaviors depend on another behavior existing (EG a health component might depend on a stats component to determine how much maximum health a unit should have). Not insurmountable, but can sometimes make stuff very edge casey and difficult to reason about.
@tryoxiss
9 ай бұрын
If you are doing it right it should be fairly obvious when they conflict since components/behavours should be atomic (do one thing).
@stephenharperisgay
7 ай бұрын
That's why you use signals. Code coupling is an issue in any engine, but signals help a great deal with managing this.
@b4ph0m3tdk9
9 ай бұрын
Also C# in Godot need recompile al the time, so turnaround time is higher for C#
@ghostradiogames
9 ай бұрын
Honestly I'm probably alone here, but I prefer being able to have more than one script on a single object. It's not confusing to have multiple scripts IMO. Having a whole giant tree of children for no reason other than to add scripts to the parent is more confusing and feels clunky and cumbersome, and it's the number one thing I dislike about Godot so far. But, Godot isn't trying to rob people so I'm sticking with it.
@elionsylwin1665
9 ай бұрын
You are definitely not alone here, I prefer the same. Being able to see all the scripts, their variables and main dependecies in one game object is very nice. And while I cannot fully agree that it is not confusing, it might be when you first see such game object, usually you can figure out the structure really quickly and then it's simple. Not long ago, I had an opportunity to see the source code and scene structure of a commercial indie game and when I take a player and weapon objects as an example, player object had like 12-15 different scripts that ensured everything worked, same with weapon at around 9-10 scripts. When the game was played, the weapons prefabs became children of the player object. Imagining that in Godot, there would be a tree of at least 20 more children that I would have to go through every time I had to change sometime while debugging sounds hellish IMO.
@mikeha
9 ай бұрын
scripts are components in unity so it makes perfect sense to write a script to do a certain thing and attach that to a prefab. but what I see from first glance in Godot is it looks like they are doing the same thing, just doing it in the hierarchy instead of in the inspector, so that you see all the components as children of the prefab in the hierarchy
@flyingjudgement
9 ай бұрын
Your not alone, just imagine how a 2 and a half year project will look like in godot. Just the world with dinamic light weather and basic object will bloat the hierarchy. I wait and see, finish a small project firs but the more I learn the more I am convinced this engine isnt the right choise for a mid sized project.
@flyingjudgement
9 ай бұрын
Agree Thats exactly how most of my assets look and almost everything is reusable code. Some code simply self assembling, from smaller components can I even do that here? I know I can do everything in Unreal I could in Unity. Still I realy wish to make Godot work, 3 months thats my budget than Move to Unreal if its not possible. @@elionsylwin1665
@stephenharperisgay
7 ай бұрын
The one script per node really forces you to think about your implementation. I take it further and generally do one script per scene, and manage a small number of child nodes from the root script. Then you can compose more complex objects by loading multiple scenes. Like a weapon scene, armor scene, player scene and so on. It really forces you to make your design very modular, instead of having this very static and very coupled monolith of code.
@msg332
9 ай бұрын
Lukkiest students on the net. Thank you.
@zendraw3468
9 ай бұрын
2 questions. 1-how can one handle IK in GOdot? Unity has Animation Rigging, the goal being, make a character that can pick and return weapons from his back, aim them at a point, while at the same time retaining his baked animations to the skeleton. Basicly i want to make a GTA character, aim the guns, when i pickup items, he reaches out and his arm actually connects with the item regardless of wwhere it is. 2-which godot version is stable and usable long term, 3 or 4?
@chrismcpherson7582
9 ай бұрын
3 if you're starting a project today that you're planning on selling, 4 if you're just starting out in godot You can do all of that in Godot, yes
@fantiball
9 ай бұрын
Personal opinion: Godot 3.5-3.6 is better for 2D than 4.X. 4 is better for 3D
@TheHelderVinicius
9 ай бұрын
@@fantiballWhy is that?
@zendraw3468
9 ай бұрын
im planning on a 3d project@@chrismcpherson7582
@zendraw3468
9 ай бұрын
also another thing, do you have to pre warm particle effects so they dont freeze your game when created for the first time?
@diligencehumility6971
9 ай бұрын
That was quite usefull thanks. But I dont understand, if you have an enemy "prefab" you save it as a scene? And how do you spawn an enemy at run time?
@Clarkzer0
9 ай бұрын
They can be instantiated at runtime, comment gets deleted if I post the link, the "Nodes and scene instances" documentation explains how to do this
@brunosarkar6812
9 ай бұрын
Yes you save it as a scene, you can put scenes in other scenes or if you want to spawn a scene at run time you can use this: var instance = load("res://Scenes/name_of_scene.tscn").instantiate() add_child(instance) and basically you will add a child on the node where the script is
@sinisterdesign
9 ай бұрын
The fact that they're called "scenes" is immensely confusing for a beginner. They should use clearer terminology, like "NodeCollection" or something
@NihongoWakannai
9 ай бұрын
@@sinisterdesign yes, the name "scene" is badly chosen. It's easier to understand godot if you imagine it as having no scenes and everything is a "prefab" in unity terms. You play the game by simply loading a prefab
@stephenharperisgay
7 ай бұрын
Everything is a scene which just means everything is a prefab. It's prefabs all the way down.
@crazyperson123
9 ай бұрын
not on topic but do you plan on making a discord?
@sahabatgamerID
9 ай бұрын
So cool. So you can program enemy by adding more script
@SG-js2qn
9 ай бұрын
Does Godot really leverage its open sourceness? It seems like it should progress faster if people can submit fixes for bugs and submit new features. Maybe that is more difficult than it seems, but if it can be done, it would appear to be a way to take advantage of any knowledgeable and skilled people / studios moving away from Unity.
@stupidburp
9 ай бұрын
Needs more people to contribute
@SG-js2qn
9 ай бұрын
@@stupidburp Yes, I assume the level of code contributions in the past have been small. Contributions could go up if skilled Unity users begin working with Godot. With it being open source, you'd think users could add a little here and there, and before long the community would have most of what they want. Perhaps create a request board, so that people can see what's needed and if anyone is currently working on it. That sort of thing.
@arjix8738
9 ай бұрын
Aside from the obvious fact that there weren't many contributors, it ain't easy for a huge number of people to cooperate. Chances are, a team of 5 people could outperform a team of 50 people. Either way, it all boils down to how active and dedicated the people with write access are, if a PR is reviewed and possibly merged in under a week then that would mean that they are very active.
@SG-js2qn
9 ай бұрын
@@arjix8738 Of course. But sometimes a person running into a bug knows exactly how to fix it, and could submit the fix. Things like that.
@arjix8738
9 ай бұрын
@@SG-js2qn it is not rare for a PR to stay open for years, even if the PR fixes a bug, it will be useless until it is merged. I haven't seen how PRs are handled for Godot, but it is not as simple as making a PR.
@sinisterdesign
9 ай бұрын
I originally came from Flash to Unity, habituated to code-first development. It took me a while to wrap my head around how editor-dependent Unity's workflow is, but I managed to create an in-engine framework that's flexible and code-driven. This makes it seem like doing that will be even harder in Godot--and that is honestly a huge turn off for me.
@stephenharperisgay
7 ай бұрын
You can do a game entirely in code aside from creating an empty scene with one empty node as the engine will throw an error at you. But you could absolutely write a "main script" set as an auto load and write a pure code game. The editor is primarily a tool to visualize node structures and spacial positioning of visual components, but theres nothing stopping you from creating nodes in code and adding them in their tree using add_child. The engine under the hood is very decoupled from the editor. Which is why they were able to build the editor in the engine itself.
@neko_haerin
9 ай бұрын
4:46 Didn’t you mention that Godot has an Autoload feature, so don’t that he like global features for a scene? Why do you say there is nothing else?
@ShiloBuff
9 ай бұрын
Honestly what the creator says feels a bit exaggerated (maybe for marketting purposes?). Some of his statements felt a bit misleading. I think both engines have a lot of simulaties in design. Godot just being more straightforward, simple, and lightweight. I had no problems at all picking up Godot after using Unity. Looking forward to the growth of Godot because of people migrating.
@chriszymurgist
9 ай бұрын
This comparison to Unity comes form a fundamental misunderstanding of how Unity works. You can, and should, use composition in Unity in the exact why they are promoting in this video.
@AustinPinheiro_uniquetexthere
9 ай бұрын
why do i feel a number of tutorial videos when explaining unity feel like they never even tried unity. the idea that in unity you have inheritance but not composition feels extremely untrue. for unreal it might be true but for unity its much closer to godot and easier to switch too.
@RavenTaleLive
9 ай бұрын
I guess it mostly boils down to how the outliner works and the way components are attached to game objects which means you're not going to see them in the hierarchy of the outliner.
@voidling2632
9 ай бұрын
this feels like an apocalypse, mass immigration towards a more safer land.
@CarbonI4
9 ай бұрын
Hrmm, will have to think about the way this video shows scripts being used. At first glance I much prefer unity's object oriented code first approach, It seems adding a bunch of different scripts to an object is a recipe for disaster if they have weird/potentially buggy interactions with each other. I already didn't like Unity's noob friendly but sloppy/inefficient feeling workflow of just throwing scripts on gameobjects and this seems to take the workflow and amp it up to 11?
@skaruts
9 ай бұрын
Composition is still OOP, though. But you don't have to do it that way. Godot is actually pretty flexible. You can do inheritance instead of composition, and you can have a script that controls many things instead of multiple scripts in those things. I once prototyped a roguelike where I even did nearly everything through code, rather than though the editor. It's up to you how you do things.
@pythonxz
9 ай бұрын
@@skarutsI say to always use the right tool for the job. Inheritance is good for certain things, and composition is good for others.
@not_ever
9 ай бұрын
The tweets comparing Godot and Unity are really weird. You can use inheritance in Godot and obviously the creator of Godot knows this. There are many people who prefer composition over inheritance (in programming in general, not in Godot) to the point that it's a hard rule for them, maybe he is one of the composition evangelicals or maybe it's hard to express yourself fully in tweets.
@skaruts
9 ай бұрын
@@not_ever I think he's trying to illustrate how godot can use composition to build game objects in a very similar way to how Unity does it. Probably the tweets were a bit rushed too. He may have felt it was urgent to throw that out there.
@Matkins85
9 ай бұрын
Sounds like Juan doesn't really know Unity at all. It's very flexible, you can compose using components or extend via inheritance in code, you're not forced to do things one way or the other, you're free to do it which ever way suits your project or game system you're creating. So are you telling me that Godot doesn't support inheritance? What about if I decide to use it with C#? Surely it's an option. If not I'm very disappointed.
@ImNotGam
9 ай бұрын
Godot does support inheritance. In fact, I use it a lot in C#.
@not_ever
9 ай бұрын
You can use inheritance, even if using GDScript.
@roflcopterpilot
9 ай бұрын
Agreed. Literally the first minute was wrong. Also how long will Godot will support C#? Most stuff I see is Python, and that is one line I will not cross. I can code in Python, but detest every second.
@justlimeguy
9 ай бұрын
me a "Go-Dot" user just enjoying the chaos and is ready to help: hi
@Nylnezz
9 ай бұрын
kinda unrelated but we are allready having the usual app refugee effect, people are allready asking for godot to change from using gdscript to only c# i dont know about you all but i find that very irritating, but the creator is shutting it down it seems
@uzeconshikory8174
9 ай бұрын
😭😭😭😭😭😭😭😭😭😭😭😭😭😭 so after 7 years all my Unity Knowledge is wasted
@ywenp
8 ай бұрын
1:40 Isn't this practice at odds with the "call down, signal up" design pattern? Not to criticize, because I also find value in it, but when learning Godot it seemed creating this upwards dependency via the use of `get_parent()` was sort of discouraged.
@stephenharperisgay
7 ай бұрын
It depends. It's ok for some nodes to be tightly coupled, particularly intra-scene. You know the sprite child is probably always gonna be where it is relative to its parent node in a player scene for example.
@vast634
9 ай бұрын
Global Scene setting: but there is that root node above the "world" node, that defines things like the viewport setup. Strangely it must be edited in the projects settings, and cant be edited in the inspector like child viewports. Would be better if this is also a node in the tree, that always has to be first.
@RenderingUser
9 ай бұрын
the thing that has viewport setup is the window node. it can be edited in project settings.... but it can also be edited in the inspector.... when the game is running also, there doenst seem to be any reason to edit viewport setup in the inpector cause the window is basically global. and it would be annoying to add the window node to each scene. and would be much cleaner without that
@vast634
9 ай бұрын
@@RenderingUser If its a node it would be consistent to use as any other node, it just cant be deleted as root, but it could be pushed as a sub-viewort. And this node could be saved as template and exchanged with another one. This saves resetting all those setups in a new or parallel project.
@RenderingUser
9 ай бұрын
@@vast634 you can always just do that another way. Just make a window node, and set all the properties there. Then you can just use data from that.
@watercat1248
9 ай бұрын
Ther 2 things I don't able to understand in Godot as unity developer 1. Why I'm not able to move the window in whatever order I want 2. How to add the components in Godot 😅 3. Why the camera priority dasn't work wean i add 2 cameras in my project and the have teknikly camera priority as opinion but wean I tried to Chenge the go buck to 0 4. How to make a object (note) to activate and deactivate The are other's stuff I don't understand as well but those is stuff I don't really getting right now
@obkf-too
9 ай бұрын
1- I don't understand the question. 2- there is no components, you add child nodes. let's say you want to make a bouncing ball, first add RigidBody3D node then add CollisionShape3D as a child of that and choose a shape from properties panel, and finally add MeshInstance as sibling to the Collision shape and choose the same shape as earlier. so the node tree shoold look like this: RigidBody3D (for physics simulation, script should be added here if needed) |__CollisionShape3D (shape of the physics objects exp: sphere) |__MeshInstance3D (Mesh shape of the object exp: sphere, here goes materials and shaders) 3- Set camera to "Current" in the property panel and the last "current" camera will take priority. 4- Use "process_mode" property which controls the node behavior pause or process. I suggest reading the documentation, especially the tuturials and watch couple of videos, and of course join Godot Dev groups and stuff. Cheers.
@watercat1248
9 ай бұрын
@@obkf-too okay
@flyingjudgement
9 ай бұрын
Well that looks quiet limited and confusing after a certain complexity. The last thing I want is to fumble around in any kind of UI. There is only 50 line of code, 5 objects and the hierarhy alredy looks messy. How easy is it to write Dev tools, do ppl create they own Nodes? Assembling and placing assets by hand sounds like a lots of unecessary work, I rather have a database for all the properties and generate what ever needed, code should do the work.
@lukky.
9 ай бұрын
Godot is a sandbox in many ways he is just talking about what he would consider best practics. I have made games where the entire world is just one node and everything is generated by code. You dont have to do anything in Godot just code and Create how you like !
@gamecoder77
9 ай бұрын
3D Nightmare. Godot is bad for 3D when it comes to 3D Game development. for 2D I will definitely recommend Godot 2D. There are still thousands of performance problems in Godot.
@scotmcpherson
9 ай бұрын
You can do this in unity as well
@paulblart5358
9 ай бұрын
No visual script editor?
@chrismcpherson7582
9 ай бұрын
They discontinued it a while back. It's still around, just maintained by the community
@paulblart5358
9 ай бұрын
@@chrismcpherson7582 Sounds like I'll have to do some digging for it. Thanks for the reply. 👍
@chrismcpherson7582
9 ай бұрын
@@paulblart5358 honestly, though, GDScript is super easy, I'd recommend just using that. They found that people who were used to Jolt and Blueprints had no issue with GDScript, which is why they got rid of visual script. Do note that Shader programming still has a visual script option (it's quite robust too)
@skaruts
9 ай бұрын
@@paulblart5358 they ditched it because it wasn't that great. Imo it seemed just like writing code, but much more laboriously. I don't know much about visual scripting, but I wouldn't suppose that's the ideal visual scripting. I've no idea what the community has been doing with it, though.
@rikrishshrestha5421
9 ай бұрын
2024 is gonna be Godot revolution era. No one hated godot before but unity was gud enough people didnt bother switchin but now...hehhehehhhahahahah
@zardify_
9 ай бұрын
I don't know.... as a mainly hardcore programmer... Godot feels less and less inviting to be honest. :/
@kevinscales
9 ай бұрын
You can make a game with one node if you like, just use code to create and manage everything. Use composition, use inheritance, have a single array for all your data, load your assets from a server at the moment they need to be displayed, do whatever, you do you, Godot wont stop you.
@weslleyalcoba
9 ай бұрын
I appreciate the sentiment and idea of the video, but it looks like you don't have much experience with Unity, so the advice ends up falling a little flat in a sense. At least for those who know Unity, which is the audience the video is targeting.
@containedhurricane
9 ай бұрын
Unfortunately, Godot is way behind Unreal for realistic graphics and massive scenes, since the creator said it will never adopt data-oriented design or ECS for its gameplay scripting. Its Nintendo Switch porting cost is $3,000 and there is no tool to port a Godot game to Switch ourselves
@lucienarcos-palma3834
9 ай бұрын
In the downfall of unity godot should rise
@Dream_scape47
9 ай бұрын
The only Issue I have with Godot is not GDscript, its Its lack of features and its focus on change for the sake of change, rather than Stability, and as an indie game dev I prefer stability since I can't afford my project being obsolete moving from version to version.... that's without even mentioning the amount of plugin compatibility we lost with Godot 4.0 that are still not supported... So my advice for people who are switching from unity is to know this. Godot is still unstable at the moment, by switching to it you are committing to an engine that will get good over time, If you are looking for Stability you should probably considering using Unreal Engine 5. I had to say it so people don't waste their time.
@yusarimahubara
9 ай бұрын
Good luck trying to make 2D games on unreal engine 5
@chrismcpherson7582
9 ай бұрын
It's 100% not "change for the sake of change", they took the opportunity to make a long list of backwards compatibility breaking changes at once with 4. These changes were good and have been a major improvement, and we are much less likely to see a massive list of breaking changes like that again for a long while If you value stability, 3.5 is STILL being updated and improved on for LTS. Long term stability just means not upgrading your project to 4 In all reality, there's no difference between that and some of the changes Unity had to go through a few years ago.
@DillBee
9 ай бұрын
Big number changes like Godot 3 > 4 obviously have breaking changes, just like UE4 >UE5. You can stay within a numbered version and will continue to get more stable updates. Also you have the ability to just not update, nothing is forced on you.
@zendraw3468
9 ай бұрын
maybe he doesnt want to make 2d games @@yusarimahubara
@zendraw3468
9 ай бұрын
i have been sayng exactly the same thing, people bash on unity for being shady pice of shit company, but lets bash a bit godot for just trying to prove its daddy how good they are, but kinda fail and never enough.
Пікірлер: 134