Might be time to shine. Start a migration guide series for your Unity fellows, maybe even collab with them and develop a series to ease transition. Welcome to the Godot side of the fence - enjoy!
Yup, hope that with Unity fumbling the bag, Godot can grow to become the Blender of Game Engines. UE5 is a good and powerful option too, but we need competition, not monopoly.
@@daphenomenalz4100 Won't matter; the community would just fork them and move to those instead. That's basically what happened to Emby with Jellyfin They'd just be giving the founders free money, which they do deserve.
29:20 Each node can only hold one script In order to attach multiple scripts inside an object, you need to add multiple nodes inside said object, each with their own individual script. At that point, these children nodes become Unity's equivalent of "components" That's exactly how it works here
@@simonlow0210 It's pretty much the equivalent, you have the orchestration script that handles sub scripts either through children or through an export, but yes
@@FlooferLand It was ugly and confusing to you? That's interesting, I found it really intuitive if you think of it as _nodes_ ; atomized/modularized components
@@sheepcommander_ I just found the whole concept really confusing at first, turned me away from learning Godot in the beginning because I really loved ECS and still do. Over time I got used to it however and realized both ECS' and Node systems suck in their own ways XD Also learned you can basically emulate ECS using Godot's node system, so that's fun
even if they fully revert the changes, heck even if they somehow backtracked further then that, the damage is done... People will never trust Unity again
@@waron4fun597 I'd need some kind of guarantee that they will and can't do anything like that in the future again, if they really roll back and want us to trust them again...
I like it. I abandoned Unity when they let that scumbag EA executive join and started turning Unity into an Ad driven wasteland. I saw the writing on the wall a couple of years ago... I am only sad it has taken this long for everyone else to get a clue. Unity has made it clear how sinister their evil is for a while now.
Unity's CEO said "What if battlefield players paid a dollar per reload?" and he was fully serious. Also, he did this to make his AAA friends happy, since AAA games are being challenged by indies more then ever.
Ah welcome to Godot! hope you like it. here's some answers to questions you brought up. 1. You can set the "default texture" in the import tab above where the root node is. 2. Yes you can mix GDScript, C# and probably other languages too if you have their GDExtenstions installed, 3. This was probably just a slip of the tongue but GDScript isn't propriety, It's also opensource. 4. You can have Godot open the scripts in your editor of choice automatically, skipping the built in editor. 5. Nodes are all Classes, So "inherents" in attach script window does refer to inheritance in an OOP context. 6. You can "extend scripts" but not add new ones, Usually you would instead add Node Children, and attach scripts to them, those would act as components that you could also instance as children in other scenes. Also in GDScript, you don't have to close the game window when editing code or the scene tree, most changes will get loaded live.
@@outsiderealmgames and although scripts are usually attached to nodes, you can also add loose ones if they define their own global classes. The editor will always load them automatically. (this is for gdscript, I don't really know how it works for c#)
On #3, GDScript is "unique" to Godot, let's say. While I use and like Godot, I can definitely understand people wanting to use the more widespread C# (Which I believe IS proprietary to Microsoft) especially if they're already familiar with it.
@@thegardenofeatin5965 well, the C# has been open source for years too. I've been pleasantly surprised that Godot 4.0 now supports Net 6, which is far more up to date while Unity is still struggling with Net 4.7 (it's a pain sometimes, really...)
The X and Y on the Transform is actually its Basis the origin is what you want to change. But you can actually get and change its position by just getting it position i.e Position or GlobalPosition
so it's Transform.Position.X that you set and get? (makes sense since Transform has more attributes and functionality in it than just Position?) edit: answered my own question by watching the video fully, Transform has Position, Scale, Rotation and Skew attributes or components (not sure what they're called here).
@@pijcab No, you don't use this.Transform, it's a 2 dimensional matrix, you just use the exposed direct values, this.Position, this.Scale, this.RotationInDegrees instead. If you MUST use a transform (you literally never do), you can do this.Transform.Origin instead... (that is the equivalent of this.Position) Transform2D and Transform3D are really fancy names for Matrix2D and Matrix3D, specific version of them used in OpenGL/DirectX/Vulcan for location/rotation stuff, used generally in graphics math. You are not supposed to use Matrices unless you know what they are. P.S. I use GDscript, not C#, so i use self.position, self.rotation_in_degrees, self.scale when i need to, i might have gotten the capitalisation wrong. I don't use self.transform.origin anymore cause, you dont' need to, and it's actually hard to edit (you have to create a whole new transform and set it as a reference because the values of a transform are read only, video creator already knew about that problem which is why he got stuck, like we all do at the start).
@@pijcab Transform has origin rotation and basis. In 2D basis is 2 Vector2s X and Y, in 3D Basis is 3 vector3s X Y and Z. The basis determines how move an object was rotated for its initial transform Its useful for getting camera relative velocity for example.
Its very interesting to see the perspective of someone who hasnt seen any tutorials yet. Gives some insight on how self-explanatory and intuitive the Godot UI and systems actually are for beginners, even though you're not really a beginner in game dev as a whole. PS: 16:20 the GDscript syntax is basically like Python. Its extremely easy and clean to use, and most tutorials use it.
and the C# support overall has gotten MUCH better, but still has a lot of kinks (sadly) compared to gdscript, I'd highly suggest starting with gdscript and moving to C# later (if that's what you prefer)
@@zaftnotameniWhen I try GDScript the in-Godot editor is atrocious and debugging barely works. I thought GDScript was brand new. Where do people normally edit and debug their GD Script?
if i'm not mistaken, unity's 2D is really 3D with a camera pointed at a plane. godot's 2D engine is a true 2D engine. that's why you can't see anything in the 3D view. the in-editor documentation for gdscript is outstanding. i primarily use c# but i use gd script to explore things sometimes. also the names of things are usually the same as the name in the inspector. so this.Position this.Rotation this.Scale etc many properties come with methods like rotation_degrees for rotate as well.
Some answers to questions in the video, might be helpful to someone checking the video :0. 1. Import is where you can set the filter options for your sprite per file rather than what you did per instance (or in settings you can set defaults per resource type to begin with ;)) - Where you add child nodes at the top there's Scene tab and Import tab, click on Import and then in your FileSystem click on TestSprite.png. 2. In the export, at the bottom after pressing on export project you exported a debug build, for release build uncheck that so you can make a better comparison. 3. Inheritance works just as usual, but if you input a random string as a class name and that class doesn't exist then godot is going to complain ;-). 4. Godot uses net with generators, this led to need for the partial classes. 5. Godot script editor is built only for gdscript (and shaders) so use external editors for c# (but set up your IDE of choice in godot's settings so godot starts the editor for you when you attach a script or open a new one, this also allows better debugging and such since everything is already connected from the get go - seamlessly works while launching on your own can sometimes cause issues, if you used Unreal Engine it's the similar thing). 6. _physics_process(): method is the FixedUpdate from unity basically 7. In general godot also uses floats but for specific implementation reasons the deltas are doubles, you need to cast them to floats when you use them though since godot's api will expect floats (you can build godot on your own with double precision though if you ever needed to) - though I think there's a draft or already a PR to change this. 8. Transform is local space transform, GlobalTransform global space, Transform.Origin (position), Transform.Basis (is the basis obviously ;)), you can also just use Position or GlobalPosition instead of transforms straight (internally it uses transforms so it's just a comfortable shorthand). 9. Unity's RigidBody equivalent is Godot's RigidBody2D/3D ;). 10. Holding right click and WASDEQ allows fps style movement in 3D viewport (mouse wheel to speed up/down). 11. Clicking on 3d/2d opens related window but if you want you can combine 2d and 3d (3d in 2d or 2d in 3d, or mix it even more). 12. One script per node, you can use other nodes and attach scripts there when needed. 13. Offset in sprite basically helps if you needed to have a pivot point. 14. ChatGPT doesn't have info about Godot 4.0 or later unfortunately. :'/ 15. To move in a simple way you can for example Position += Vector3.Right * (float)delta * _yourSpeedVar; 16. Using `this` keyword is not necessary in godot unless you get to a situation you need it for c# reasons (could be just preference I know ;)). 17. Camera2D is a node too. 18. You can change scaling and such in settings. Cool to see you checking it out. :)
This is super helpful! I'm also a long time Unity dev taking a look at other options like Godot. I was curious about the camera which you mention is a node; if you do not specify or add a Camera Node explicitly, is there a way to access the default one that the Engine seems to be using? In Unity each scene has a camera added by default that you can either replace, add more, extend, etc. While it's typically best to cache your camera reference if you plan to access it, you have the option to access the current main camera statically through variables like: Camera.main, Camera.current, Camera.allCameras. Wondering if there was some kind of equivalence.
@@legendarydragoon Hm, I think you need to add a Camera2D for that but I work mostly with 3D so maybe you can find something more. You can get some basic info form the viewport though for example width, height if that's what you need but in general you always add a camera be it in 2d or in 3d (3d won't even render anything without a camera in the scene unlike 2d). I wish I could help better.
@@legendarydragoon As far as i know there's no way to access the default camera, i don't even know if there's such a thing as a default camera, however it's trivial to add one, just add a Camera or Camera2D node anywhere in the scene and check the enabled property (it's checked by default) and it turns into the current one. If you want the camera to move in any way you would add a camera in any case, and it's easy too, just add the camera as a child of the player and it follows it around, or put it as a sibling and add a RemoteTransform node as child of the player, with the remote path as that of the camera.
@@legendarydragoon In 3D you explicitly need to create a camera, in 2D you implicitly have a camera, but can use ones you add yourself. You can access the default camera through Viewport.get_camera_2d/3d(), I don't know what's the c# equivalent, but I'm sure it's similar.
@@legendarydragoon There isn't a "default camera." If you don't add a Camera2D, it is painting directly to screen. Unlike Unity, the 2D engine is independent from the 3D one, so it doesn't need an orthographic camera in the background to show the 2D content. The Camera2D node is actually "faking" movement by moving and transforming the canvas in a more natural way, whereas the Unity camera is an actual 3D camera (which is why Unity has no problems if you toss 3D objects on your 2D scene, whereas Godot won't allow it).
I really like the node system in Godot. If you take a look at the documentation they go into minute detail about that system. I think it's better than game objects.
I think it's more intuitive for beginners, but if you're working with more complex things where the hierarchy isn't entirely clear, the ECS/component style quickly becomes an advantage.
@@squelchedotter it's a matter of perspective only, but it is there. The scenes act as components. Each escene with their own nodes which serve a specific purpose can be reused in the main tree as components. So, for example, you don't create one scene with map, player, enemies, ui, objects, etc. you would create as many scenes as you can for re-usability and you would add the scenes to the main scene. So it's a naming thing only but they are essentially components / objects.
Thank you UNITY!!! I've been stuck in "Game Engine Choice Hell" for a while now, and just when I needed to make a decision, you made it for me!!! Thank you!!!
As someone who switched from unity to godot a year ago, i wish you good luck! personally it didn't take me long to get used to the engine, only about a week actually, but i heard a lot of people have troubles with it
20:06 -The Godot editor does have built in documentation, if you right click a node and select "open documentation" it will, essentially, tell you everything you can do with it. 22:51 -Godot does have a _Physics_Process function, that sounds like what you were looking for. 25:04 - ... That's weird. May be a C# thing, when using Godot's editor, the X variable of a transform is a float. This may be an issue with the visual basic 29:19 -Only one script per node, yeah. Most what you would call "Objects" in godet are trees of nodes, a node can double as both an entire object or simply a component of one, depending on how the hierarchy in the scene tree is organized. You wont really need multiple scripts on one singular node.
25:04 is because the transform there isn't the transform section of the node (or whatever it's called in Godot), it's the transformation matrix of the node. So X is actually M00->M03 - it's the first row (or column, depending on which one is major in Godot).
When you import anything, you can select the file down left in the file explorer and then go to "import" on the upper left. You can then select the options you want the file to be imported as. For Pixel Art, you can select the Preset "2D" and it works well. When you add a script to a node, you're basically changing the node type to a new type that inherits from the original node type. You can't add multiple scripts like you do in Unity, because the script is the node, not a component of the node. Everything is done through child hierarchy. For example when you have an Area2D, you add colliders as a child node to it, and the Area2D uses those colliders to determine its area. Every node has a position property, which you can use instead of the transform. Same for rotation. It's better to use those instead of transform,
The filter option is available on import tab just in godot 3.x. In godot 4, you can set filter option / node (like in 3d / material), and you need to set your main canvasitem node (Node2D) for inherits to all other children.
To be specific, in Unity each node (GameObject) is a container of leaf nodes (MonoBehaviour). When moving over to Godot you just have to lift the "main" behaviour up in the hierarchy as all nodes can be both leaves and branches. So instead of having a GameObject that is both a sprite, a rigid body, and a collision shape you pick what the main feature is for this, presumably the rigid body, which then has a sprite as a child, etc. It's more straightforward this way, in my opinion. The unity method differentiates between Scene, GameObject, and MonoBehaviour, making one valid as root only, and one valid as leaves only. In Godot your scene can be any type of node, say a rigid body. More straightforward implementation of a tree data structure. The transform seems to be the Matrix that is used, not a separate component like it is in Unity. It did have functions for translating it it seems, but it makes sense to use the position property instead of reinventing it's implementation.
I personally would use UE as I don't think Godot is ready yet, it's a great product but it still needs some time in the oven, this is my sincere opinion and thoughts about it. I understand that UE is much harder to learn though since it has so much and it also uses cpp, which is a harder language. (Has BP though but I personally do not use that for heavier calculations) A mix of cpp and BP is the way to go I think, with cpp doing the heavy lifting. *That being said,* Godot definitely has a future and I think after this Unity debacle Godot will improve fast because they have an opportunity to fill a void. And honestly people who say UE is bad for indie or "2D" are just wrong. That is such an old take. You do need patience though because UE is heavy, so many features.
These types of raw videos are amazing, if I'm being honest. It lets the viewer follow along with the presenter's thought process, while allowing them to generate their own thoughts. Personally, this type of video is more useful for me than a tutorial.
Small tip for using Godot's docs: When using Godot's in-engine script editor, Ctrl + Left Clicking on any built-in class variables will bring you to that document within the editor. For example: Using it on the text "Sprite2D" would open the document for Godot's Sprite2D Class. P.S. I hope you enjoyed using Godot!
The node system is weird at first but once you get it it's really powerful, for example if you're making a car game, you can have the car body as the parent node and then the wheels, engine etc as child nodes and now all you have to do is swap out the mesh files of the children and you have instant car customization without having to reposition all of the different parts manually.
i tried Game Maker , Unity, Gdevelop, Ue5 ,etc, and for me 2D Godot its the best so far, intuitive node system, you can use a component approach like Unity or OOP, the UI nodes are better, you can animate ANYTHING with Animation Player , much better than the Timeline in Unity
personally I switched to UE5 from unity a while back but for 2D UE5 is a hassle to work with, unless you want super good graphics id go with GODOT as well.
@@kevinzawarrior Tbh, if you are willing to work for it, Godot is also capable of super good graphics. Look at PVKK for example, a game that's releasing soon and is made with godot.
A closed source proprietary game engine capturing most of the indie game market was never going to end well. Sooner or later, there was always going to be someone come along and get the bright idea to treat their customers like cattle.
Watching someone new to godot just opened my eyes it's like a baby walking lol I hope you find a engine that's best for you with this unity "crisis" goin on!
Welcome to Godot. Theres plenty of tutorials around to get your feet wet. I have a playlist as well covering how to use GDScript if you want to try out the builtin language. Its all centralized within the editor. Even each classes documenting is all builtin offline.
Try adding a camera2D as a child to the node you want to zoom in on. The node structure takes a bit to get used to but I don't miss the component structure anymore especially since I feel the scene system is a lot better integrated then the prefab system I constantly had problems with back when I was using unity full time
Honestly, I still use nodes as components. Heck, godot uses nodes as components by default sometimes. Like how it asks you to add collision shape nodes to physics bodies. I've recently taken to more composition based project organisation.
another tip on this is dont be scared to have hundrids of small scenes. it makes working with things a lot easyer and you can put a seen in the node tree
As someone who only has 22 hours of coding in Godot; Godot is WAY easier to get a hold of and learn Godot than Unity. In 22 hours of using this game engine I have been able to do the following; 1. different animation states 2. Reloading 3. Shooting 4. Wall sliding, wall jumping/ kicking 5. Melee attacks 6. Change the hit box and hurt box 7. Add enemies 8. Sound play 9. Animation pauses 10. change inputs types/ add inputs 11. add combos etc. Meanwhile in Unity I was f-ing stuck worse than anything I have ever been stuck in. Godot has to be my favorite game engine so far.
I mainly use Unreal and dabbled a bit in Godot. Both are good. But I'm so far deep into learning Unreal, I just can't switch engines. Maybe once I create and release a game in Unreal, I might dabble more in Godot.
Me too. Looking into Godot and Unreal right now. Not sure what to pick. Godot is 100% free but lacks lots of features, and Unreal has all the features but coat 5% of revenue. Honestly not sure, both have pros and cons
@@diligencehumility6971 The 5% royalty only kicks in after you make $1 million dollars. The learning curve is massive and it's just information overload for 1 person. You've got so many tools and it's all very powerful and you can do so much. The huge issue I have is the Epic Games launcher, it's garbage.
Some little tips: - with F1 you can get the in editor documentation open. - In the script Editor crtl + left click on a class opens up the documentation of the class
After the whole Unity drama, I got interested into game engines and downloaded Godot recently. I don't know what I'm doing but I'm down to stick around :D
You can set the interpolation type for your parent node. By default each child node will inherit this setting. So by setting nearest neighbour to your parent scene, all children will use that setting. Quick and easy. Basically you could apply this setting to the very root node and it is set for your whole game.
Welcome! I hope you like it, bro! Godot is really underrated in my opinion, and even though I think they are already doing well on features and always improving, I belive that their core values do matter a lot too. You can really tell that you're using a tool made out of passion from users to users, instead of pure greed.
Wow, I've just met your channel and I loved the video. Differently from other channels, you actually describe what your experience really is, explaining what calls your attention, what seems confusing, familiar, etc. I wish more channels made "Trying out" videos as descriptive as you just did!
When I changed from Unity to Godot I ended up just switching to gdscript as well. I love C# but GDscript is actually a really nice language and of course better integrated in to Godot.
Yes, I feel bad for how many people will fall into the C# trap. Godot only put the bare effort into it for MS funding. The engine's actual intention is to use GDScript and if necessary C/C++ for speed ups. An example would be for procgen. You might have to implement your own C code for speed up.
@@enochsadventures -- If you had some complicated serialization, taking XML or JSON files and packing/unpacking with something like Ceres to a binary... In C# that makes sense, but what about GDScript?
@@BrandanLee You write the handler in C# and communicate with it in GD script , you can use both in the same project. So write what you need in C# but if you do most of the design work in GDscript it works well.
As someone with only a passing familiarity with Unity and no exposure to Gadot, this was very interesting to watch! Thanks, can’t wait to see what’s next
I played around with Godot the past few days as well. Incredibly interesting and full of potential. For my needs its a little light on features, in particular 3D ones such as a Terrain editor and the ability to paint intanced objects for vegetation and the like. I would need to code quite a few tools to get myself up and running with it, but I am keeping my eye on it. I was particularly impressed with the performance, managed to get10.000 (instanced) objects on screen at over 3k FPS. Tried the new and improved Unreal 5 as well. Incredible visual fidelity and cutting edge tools, but MY GOD the overhead is crippling. I struggles to get 400FPS after stripping it as much as I could, on a blank scene. RTX 4080. So for me Unity is still the tool of choice. But I'm jumping over to Godot the moment they add more 3D features (they are so close).
They are working on a lot of 3D tooling but where quite lite on those recently since they switched their backend to Vulkan which was obviously a enormous undertaking.
one thing that really helped me understand godot was the realization that everything is a node. Every class inherits from node, and everything in your game will be a node. Scripts are attached to nodes and you attach those nodes to other nodes in a tree structure to give them functionality. In unity theres components, think of a node as a component. Attach a script to a node, save that node and drag it into another node to add that "component" to your other nodes. good luck in your godot journey, the community is great and with unitys fumbling with their pricing model, hopefully our community will grow
Ye, I found it way more intuitive than other engines' way of handling this stuff. Like, UI, characters, worlds, levels, even components that don't even get rendered, like state machines or HTTP request handlers, they are all just nodes. Scenes are also just nodes (although I think this is a really bad naming scheme, because initially I thought a scene was the same concept as a level, but for Godot, scenes are more equivalent to templates). They are not arbitrarily distinct. In Unreal, for example, all these would be completely different concepts, so you'd need to learn how to interact with each of these, but in godot you just need to learn how to interact with one thing; all others are just extensions of that one thing.
Welcome to the community, man. I personally gave up on Unity close to a year ago, when it started feeling like I was fighting the engine for basic stuff. Godot 4 blew my mind. Wait until you get a load of the new physics nodes. It's got in-engine support for soft body collisions. It's amazing that it's unconditionally free. The biggest thing I needed to get used to was Godot's child nodes serving the same purpose as Unity's sibling MonoComponents. Instead of tacking another script onto the same node (which isn't possible), just add a child and tack it onto that, which is what the internal nodes use; or find a way to merge the functionality into the same script. Also note that resources (textures, sounds, models, etc.) are kind of their own thing, and sometimes you need to change their metadata (under the Import tab) to get them to do things, like loop. Lastly you can think of scenes as being _kind of_ like prefabs.
8:00 in settings you can set default render mode for textures and you can change that to `Nearest`. That's why Sprite2D has "Inherit", it inherits from configuration. Also, think of Nodes in Godot as of classes that have hierarchy. So Sprite2D extends Node2D, and Node2D extends Node etc. So Sprite2D is ALSO a Node2D so it has properties of both.
I hope you explore this further. I just finished my first project with Godot and am thoroughly happy with it. I dabble in Unreal for Animation and Rendering and it certainly is waaay more taxing and complex. It has all right to be that way, it's a powerful engine, but it also makes simpler stuff, like 2D, that much harder to get into and run. The editor sample projects alone can set your machine on fire with the raw processing power it can require.
From a game dev hobbyist perspective, I was just thinking about how well this shows off his critical thinking skills. “Oh, I noticed this feature I’m used to having in Unity doesn’t seem to be present here. Maybe it’s somewhere I’m not looking or called something different,” shows immense maturity and wisdom as a developer imo. All too often, I feel like people will immediately assume that if something they actually already know is framed in a different context from what their used to, it’s not actually there and they’ll panic and immediately search for tutorials instead of putting in a little more effort to just figure it out. I found this vid really inspiring, not just as someone who wants to get better at game dev, but also as someone who values and wants to get better at critical thinking and problem solving.
@@RenderingUser so theres no way? it's just that every engine and modding software I have experience with use +Y as Up. this will take some time to get used to
@@pasta8026 it's +y up in 3d in godot But canvas coords always put - y up in 2d I've seen some game engines use that a lot. The ones that deal with 2d. It's sort of fine in godot cause you can just use the enums for vec 2 eg: Vec2.UP It will generate Vec2(0, -1)
So .. right as you were opening Godot for the first time i got hit with an ad .. and it was so smooth Aannnd a game intro .. .. it took me a few seconds to realize it was a commercial and not some super fancy splash screen .. .. yep.
Nodes in the scene tree (left) and properties in the inspector (right) you can right click -> Open Documentation Within Godot's code editor, hold control and click on an variable/type/function name within a script to jump to the documentation or where it is defined in your code (at least this works with GDScript). You will sometimes have to do strict typing e.g. var MyVar: String to get auto complete/documentation when doing something like MyVar.format()
As a sucker for Godot, thanks for giving it a shot! Always lovely to see people trying out other engines and giving them a spin.. not the least for one I'm pretty passionate about! Darn freaking shame about the circumstances.
A solution perhaps is to have a shift towards supporting and using open source and/or public owned alternatives. If there is increased demand for alternatives, I believe open source/public owned alternatives can outshine corporate offerings.
the X and the Y are basis vectors of the transform they are not the x and y components of the position , basically the transform has a position with xyz ,and three basis vectors X Y Z that describe the orientation. basically its the rotation vectors that you were accessing
Actually a pretty good tutorial video. I am not coming from a game dev background and didn't actively look for tutorials but i found it widely interesting to have the insight of someone with solid overall understanding of game engines
Yup, can also deal with the camera issue there too by using the window and viewport settings. I like to use 320x180 and set my viewport to 1280x720 for pixel art games
This was entertaining to watch for sure! There are a couple of differences between nodes/scenes and Unity GameObjects/scenes. A scene in Godot is just a collection (or prefab) of nodes with a root node as part of a scene. As such, you can instantiate scenes within scenes however much you want, and each scene is just a tree of nodes (or smaller scenes). The reason why you didn't see a camera in 2D mode (although there is a 2D camera node) is because the 2D and 3D engine are actually separate. Unity basically draws 2D on top of a 3D background (which can be empty) but doesn't fundamentally distinguish between 2D and 3D outside of specific object types. Godot 2D is a full 2D system, complete with its own lighting and physics implementations, which is why you have separate 2D and 3D nodes for most things. You only had the X and Y on your 2D scene because it doesn't have a Z axis at all, and it's "pixel perfect" because that's the default. If you want to do pseudo-3D in 2D mode you have to fake it with cameras and parallax. You can only have 1 script per node. That being said, you can have as many "empty" nodes with attached scripts as children of another node. A common design pattern is to create a Node (the type, which is the most basic object you will normally mess with) that just has a script attached as a "component" that runs various functions on the parent. Note that you can also have "autoload" scripts that run independently from any nodes (Project Settings -> Autoload). This is commonly used for "Game Manager" scripts or global functionality. It's also a common place to handle signals between objects in an encapsulated way (signals are very important, somewhat similar to events). Hope that helps!
This was a cool video, it's really interesting seeing how other people interact and explore. Thanks for posting this! I'm also just starting to look into Godot and the differences to unity are intriguing!
It was fun watching this, as I hit a lot of the same problems when I first tried Godot 4. Although, I just used GDScript. Since I was able to translate what I wanted to do, that seemed to be the easiest route.
For setting up default import options for assets (i.e. filtering), see the import tab near the Scene hierarchy panel. As for having multiple scripts/components per node, you can't. Game objects as containers of components is a very Unity thing. Godot uses an approach more like each node is both an object and a component. To make composite objects you put them as children of others.
Welcome to Godot! I hope when you learn the engine you like it and get better at it, Godot has so much potential and i love this engine, I've had a better reception/experience on Godot than Unity for me, personally.
this was awesome to watch, i'm glad the discovery process and thought processes were mostly unedited even if mistakes happened, it helped me learn how to think through things better :)
I really liked the video, this concept is super cool. Since I think that the Godot documentation is really great and that GDScript is easy to learn I'd love to see you blindly jump into the documentation and GDScript and see if you can do the same.
I'm also migrating from Unity to Godot and I'm pretty hyped up about it. Though I have to refactor my scripts to create a backend-frontend structure. Meaning the game logic and framework is the backend that doesn't use any logic of the game engine and could technically run anywhere, and the "frontend" is what interacts with the game engine. I partially did that in Unity already, though still thousands of lines of code to go. Still a good practice IMHO.
So yeah, one script per node. But for things like state machines you just compose them of Nodes with the scripts attached. Great thing is you can save a single node with script as a scene, then instance it anywhere just like any other node. Export variables that you can tweak in the editor. Saves a lot of time.
Note: GDScript isn't proprietary. It's included in the source code of Godot, which is licensed under the MIT license (which means that it's free and open source)
@@trickster721 that it is, but it's heavily inspired by Python, so if you know Python you'll probably know most of GDScript, and if you know GDScript you'll probably understand Python. The main differences I know of is: func (def in python) var (python doesn't have a keyword for this) const (not a thing in python) match (not a thing in python)
Godot nodes only support one script because it is a mostly object oriented design buuut you can do stuff like Option 1 (I prefer option 2): @export var scripts : Array[Resource] Which lets you attach resources to a a node and you could dynamically load them within the single script so with a little work you could make a system to add multiple scripts to a single node that inherits this “script loader” Option 2(I generally use this way): Alternatively a common way I’ve used a lot and seen done in Godot is that you make a custom node for each of your generic scripts you want to add to multiple objects and you add these as child nodes like components Like for example a movement controller that listens for wasd inputs would be a Node with a script attached to listen for inputs but instead of programming the script to move itself it moves it’s parent You then can add this component node to any node as a child and it will have movement controls
It is moving slow because you're only moving it by delta pixels each frame, so about one pixel/s. The measurements in Godot 2D are in pixels, not in units (they're in units in 3D).
@@dustlol5221 that would be great. but afaik you can only extend class derived from the node/object and attach it to a Node. The scene system was designed to work with the node system where you'll have seperate _Process, event listeners etc.. Maybe you can create another file an reference it but it cant override method and functions from the derived class directly.
This showed up in my recommends and I clicked on it in light of the recent controversy. I immediately recognized your voice. This video has some reach!
A great first look. Thanks for showing us. I've only ever played with Unity and played with Godot but I have made working things in both. It took me a little while to convert my thinking over to the Godot way of doing things but I generally prefer it. In some things it's better than Unity, in some worse, but mostly it's just a slightly different way of thinking about things. It took me a while to work out how to get full Visual Studio integration with running and debugging working from within VS in V4 (well documented for V3) but it is possible. As others have mentioned, the integrated documentation in the Godot editor is well worth investigating. Also V4 of the engine is relatively new and a pretty heavy overhaul so there are a few things that are a little clunky in places in V4 and more stable in V3. But it's improved every time I've updated a point release.
Welcome to Godot! For me it seems like Godot is a better option than unreal for most people coming from Unity unless you really need the supergreat graphics capabilities of UE5 (which weren’t on unity either anyway). Tho Godot is pretty much on-par with Unity, and will get even better with time. You also benefit from the ✨open source✨ thing and all, and it’s literally impossible for godot to pull an unity move. Unreal does have its nice parts too, but it’s not like you have to always stick to one engine either: you can always use one or another depending on what will fit better your needs for the specific game you’re making.
Its so funny to see the splash-screen sensitivity of unity converts ^^. It is just a check mark. And it will not charge you anything ^^ All good bro, you will unlearn certain anxieties pretty quickly.
liked this video just because Godot, as an open source engine, is fundamentally like good for the industry if it becomes a larger part of it. have not watched yet, will do
Welcome to Godot, I made my transition few months back from Unity into Godot. I was working in Godot 4.1.1 now trying out 4.2 RC. I was starting out as C# but i had some issues where my UID's would be changed and cause some issues about not finding components, this can be solved by viewing dependencies and relocating them. So far after a month using GDScript I haven't run into this issue since then. I am actually liking Godot as the more I use it, also 35:26 that is what also turned me over to using GDScript was the fact that error dialogs would be zipping through without being able to read them
The node / scene system is really functional and intuitive when you get ahold of what and how it's abstracting things. You'd make a scene and setup a parent node and children nodes for say, a character or setpiece. Then combine those smaller scenes on a bigger level scene. It's procedural in the sence you can edit a single separate "enemy scene" and have that enemy update its instances across all your levels
I really wish Godot to blow up. Especially because it has a native Linux version and it's a lot easier to make Linux supported games with Godot than Unity and UE. Linux gaming is getting more and more popular.
I love the concept of this video. I was literally trying out Godot for the first time yesterday, too. Spent a lot of time playing with the Material parameters lol.
With 10 years of experience moving to either one will be easy, the best advice here is to test multiple engines and pick what is a good match in terms of workflow and features needed.
if u don't think about making so big games godot 4 is the best not in graphics but every tool every node you gonna use in godot is made for u for making the game easier and u can change or make what ever u want in godot like unity , unreal is for 3d ik there is alot of 2d games have made by unreal but godot is better for 2d than unity and unreal and for 3d 🤷🏻 its just a time if godot growth like how its growth RN in few years there is no reason to use unity and if u want AAA graphic for your game unreal the onlyone in the stage
@@VectorDevIMO Unity is King of 2D, but I cannot use Unity after recent events. So now Ill say Godot is the Best option for 2D, hands down. And Unreal is best option for 3D. Both should I learn both?
I was reading the documentation for Godot and then stumbled across this video and decided to watch it first. Thought maybe seeing someone play around in the engine will make the documentation make more sense.
To make the sprite bigger for "uneven" pixel art you can just just increase the scale of the base node2d. You can do a better job of this in project settings, display/window/ and setting stretch scale. If you want pixel perfect rendering, you can instead go to the same exact page in project settings, and set the viewport width and height to smaller values more in line with a retro system. Then set the stretch mode to 'viewport'.
The first thing I did when hearing about Unity's decision was open up Godot and make a Rust extension. Favourite language, and may become my favourite game engine.
Might be time to shine.
Start a migration guide series for your Unity fellows, maybe even collab with them and develop a series to ease transition.
Welcome to the Godot side of the fence - enjoy!
This is a great idea
no
Perfect time to make something like that! I love Godot. Would love to see it.
@@cerilious Absolutely.
@@jimmycat7774 shut
Same as Blender. The more the community help each others and pursue FOSS the more we're gonna be free
Yup, hope that with Unity fumbling the bag, Godot can grow to become the Blender of Game Engines. UE5 is a good and powerful option too, but we need competition, not monopoly.
Unless Adobe buys them all 💀
@@daphenomenalz4100 Won't matter; the community would just fork them and move to those instead. That's basically what happened to Emby with Jellyfin
They'd just be giving the founders free money, which they do deserve.
@@st.altair4936Or it will be like with Audacity: everyone pretends everything is all ok.
@@daphenomenalz4100you do realize that adobe already donates to them every month
29:20 Each node can only hold one script
In order to attach multiple scripts inside an object, you need to add multiple nodes inside said object, each with their own individual script. At that point, these children nodes become Unity's equivalent of "components"
That's exactly how it works here
Really ugly and confusing at first, but it's something I've grown to love the more I've used the engine
You can also extend scripts!
@@simonlow0210 It's pretty much the equivalent, you have the orchestration script that handles sub scripts either through children or through an export, but yes
@@FlooferLand It was ugly and confusing to you? That's interesting, I found it really intuitive if you think of it as _nodes_ ;
atomized/modularized components
@@sheepcommander_ I just found the whole concept really confusing at first, turned me away from learning Godot in the beginning because I really loved ECS and still do.
Over time I got used to it however and realized both ECS' and Node systems suck in their own ways XD
Also learned you can basically emulate ECS using Godot's node system, so that's fun
It's so sad, watching this mass exodus, hopefully this will make them reconsider or help other engines like Godot get even better.
even if they fully revert the changes, heck even if they somehow backtracked further then that, the damage is done... People will never trust Unity again
@@waron4fun597 I'd need some kind of guarantee that they will and can't do anything like that in the future again, if they really roll back and want us to trust them again...
I like it. I abandoned Unity when they let that scumbag EA executive join and started turning Unity into an Ad driven wasteland. I saw the writing on the wall a couple of years ago... I am only sad it has taken this long for everyone else to get a clue. Unity has made it clear how sinister their evil is for a while now.
Ain't no way any studio would trust them after this lol. They are not going to switch back
Unity's CEO said "What if battlefield players paid a dollar per reload?" and he was fully serious. Also, he did this to make his AAA friends happy, since AAA games are being challenged by indies more then ever.
Ah welcome to Godot! hope you like it.
here's some answers to questions you brought up.
1. You can set the "default texture" in the import tab above where the root node is.
2. Yes you can mix GDScript, C# and probably other languages too if you have their GDExtenstions installed,
3. This was probably just a slip of the tongue but GDScript isn't propriety, It's also opensource.
4. You can have Godot open the scripts in your editor of choice automatically, skipping the built in editor.
5. Nodes are all Classes, So "inherents" in attach script window does refer to inheritance in an OOP context.
6. You can "extend scripts" but not add new ones, Usually you would instead add Node Children, and attach scripts to them, those would act as components that you could also instance as children in other scenes.
Also in GDScript, you don't have to close the game window when editing code or the scene tree, most changes will get loaded live.
Thanks for the detailed reply! This is very helpful.
@@outsiderealmgames and although scripts are usually attached to nodes, you can also add loose ones if they define their own global classes.
The editor will always load them automatically.
(this is for gdscript, I don't really know how it works for c#)
On #3, GDScript is "unique" to Godot, let's say. While I use and like Godot, I can definitely understand people wanting to use the more widespread C# (Which I believe IS proprietary to Microsoft) especially if they're already familiar with it.
@@thegardenofeatin5965C# used to be proprietary but it was open sourced
@@thegardenofeatin5965 well, the C# has been open source for years too. I've been pleasantly surprised that Godot 4.0 now supports Net 6, which is far more up to date while Unity is still struggling with Net 4.7 (it's a pain sometimes, really...)
The X and Y on the Transform is actually its Basis the origin is what you want to change. But you can actually get and change its position by just getting it position i.e Position or GlobalPosition
This comment should probably he higher.
so it's Transform.Position.X that you set and get? (makes sense since Transform has more attributes and functionality in it than just Position?)
edit: answered my own question by watching the video fully, Transform has Position, Scale, Rotation and Skew attributes or components (not sure what they're called here).
@@pijcab No, you don't use this.Transform, it's a 2 dimensional matrix, you just use the exposed direct values, this.Position, this.Scale, this.RotationInDegrees instead. If you MUST use a transform (you literally never do), you can do this.Transform.Origin instead... (that is the equivalent of this.Position)
Transform2D and Transform3D are really fancy names for Matrix2D and Matrix3D, specific version of them used in OpenGL/DirectX/Vulcan for location/rotation stuff, used generally in graphics math. You are not supposed to use Matrices unless you know what they are.
P.S. I use GDscript, not C#, so i use self.position, self.rotation_in_degrees, self.scale when i need to, i might have gotten the capitalisation wrong. I don't use self.transform.origin anymore cause, you dont' need to, and it's actually hard to edit (you have to create a whole new transform and set it as a reference because the values of a transform are read only, video creator already knew about that problem which is why he got stuck, like we all do at the start).
@@pijcab Also, just press F1 whenever in doubt.
@@pijcab Transform has origin rotation and basis. In 2D basis is 2 Vector2s X and Y, in 3D Basis is 3 vector3s X Y and Z. The basis determines how move an object was rotated for its initial transform Its useful for getting camera relative velocity for example.
Its very interesting to see the perspective of someone who hasnt seen any tutorials yet. Gives some insight on how self-explanatory and intuitive the Godot UI and systems actually are for beginners, even though you're not really a beginner in game dev as a whole.
PS: 16:20 the GDscript syntax is basically like Python. Its extremely easy and clean to use, and most tutorials use it.
and the C# support overall has gotten MUCH better, but still has a lot of kinks (sadly) compared to gdscript, I'd highly suggest starting with gdscript and moving to C# later (if that's what you prefer)
Thanks for the feedback! I did indeed want to avoid tutorials for this very reason. I may check some out later on.
@@outsiderealmgamesGDquest's youtube videos are a good source, imo. Welcome to Godot!
@@zaftnotameniWhen I try GDScript the in-Godot editor is atrocious and debugging barely works. I thought GDScript was brand new. Where do people normally edit and debug their GD Script?
@@PhyloGenesisvscode through an extension . . .
if i'm not mistaken, unity's 2D is really 3D with a camera pointed at a plane. godot's 2D engine is a true 2D engine. that's why you can't see anything in the 3D view. the in-editor documentation for gdscript is outstanding. i primarily use c# but i use gd script to explore things sometimes. also the names of things are usually the same as the name in the inspector. so this.Position this.Rotation this.Scale etc many properties come with methods like rotation_degrees for rotate as well.
Some answers to questions in the video, might be helpful to someone checking the video :0.
1. Import is where you can set the filter options for your sprite per file rather than what you did per instance (or in settings you can set defaults per resource type to begin with ;)) - Where you add child nodes at the top there's Scene tab and Import tab, click on Import and then in your FileSystem click on TestSprite.png.
2. In the export, at the bottom after pressing on export project you exported a debug build, for release build uncheck that so you can make a better comparison.
3. Inheritance works just as usual, but if you input a random string as a class name and that class doesn't exist then godot is going to complain ;-).
4. Godot uses net with generators, this led to need for the partial classes.
5. Godot script editor is built only for gdscript (and shaders) so use external editors for c# (but set up your IDE of choice in godot's settings so godot starts the editor for you when you attach a script or open a new one, this also allows better debugging and such since everything is already connected from the get go - seamlessly works while launching on your own can sometimes cause issues, if you used Unreal Engine it's the similar thing).
6. _physics_process(): method is the FixedUpdate from unity basically
7. In general godot also uses floats but for specific implementation reasons the deltas are doubles, you need to cast them to floats when you use them though since godot's api will expect floats (you can build godot on your own with double precision though if you ever needed to) - though I think there's a draft or already a PR to change this.
8. Transform is local space transform, GlobalTransform global space, Transform.Origin (position), Transform.Basis (is the basis obviously ;)), you can also just use Position or GlobalPosition instead of transforms straight (internally it uses transforms so it's just a comfortable shorthand).
9. Unity's RigidBody equivalent is Godot's RigidBody2D/3D ;).
10. Holding right click and WASDEQ allows fps style movement in 3D viewport (mouse wheel to speed up/down).
11. Clicking on 3d/2d opens related window but if you want you can combine 2d and 3d (3d in 2d or 2d in 3d, or mix it even more).
12. One script per node, you can use other nodes and attach scripts there when needed.
13. Offset in sprite basically helps if you needed to have a pivot point.
14. ChatGPT doesn't have info about Godot 4.0 or later unfortunately. :'/
15. To move in a simple way you can for example Position += Vector3.Right * (float)delta * _yourSpeedVar;
16. Using `this` keyword is not necessary in godot unless you get to a situation you need it for c# reasons (could be just preference I know ;)).
17. Camera2D is a node too.
18. You can change scaling and such in settings.
Cool to see you checking it out. :)
This is super helpful! I'm also a long time Unity dev taking a look at other options like Godot.
I was curious about the camera which you mention is a node; if you do not specify or add a Camera Node explicitly, is there a way to access the default one that the Engine seems to be using?
In Unity each scene has a camera added by default that you can either replace, add more, extend, etc. While it's typically best to cache your camera reference if you plan to access it, you have the option to access the current main camera statically through variables like: Camera.main, Camera.current, Camera.allCameras. Wondering if there was some kind of equivalence.
@@legendarydragoon Hm, I think you need to add a Camera2D for that but I work mostly with 3D so maybe you can find something more. You can get some basic info form the viewport though for example width, height if that's what you need but in general you always add a camera be it in 2d or in 3d (3d won't even render anything without a camera in the scene unlike 2d). I wish I could help better.
@@legendarydragoon As far as i know there's no way to access the default camera, i don't even know if there's such a thing as a default camera, however it's trivial to add one, just add a Camera or Camera2D node anywhere in the scene and check the enabled property (it's checked by default) and it turns into the current one. If you want the camera to move in any way you would add a camera in any case, and it's easy too, just add the camera as a child of the player and it follows it around, or put it as a sibling and add a RemoteTransform node as child of the player, with the remote path as that of the camera.
@@legendarydragoon In 3D you explicitly need to create a camera, in 2D you implicitly have a camera, but can use ones you add yourself.
You can access the default camera through Viewport.get_camera_2d/3d(), I don't know what's the c# equivalent, but I'm sure it's similar.
@@legendarydragoon There isn't a "default camera." If you don't add a Camera2D, it is painting directly to screen. Unlike Unity, the 2D engine is independent from the 3D one, so it doesn't need an orthographic camera in the background to show the 2D content. The Camera2D node is actually "faking" movement by moving and transforming the canvas in a more natural way, whereas the Unity camera is an actual 3D camera (which is why Unity has no problems if you toss 3D objects on your 2D scene, whereas Godot won't allow it).
I really like the node system in Godot. If you take a look at the documentation they go into minute detail about that system. I think it's better than game objects.
I think it's more intuitive for beginners, but if you're working with more complex things where the hierarchy isn't entirely clear, the ECS/component style quickly becomes an advantage.
@@squelchedotterI'm pretty sure you can create components in godot, with nodes put onto parents and a script.
the node system is really ellegant, it's a simple idea that solves so many use cases
@@squelchedotter it's a matter of perspective only, but it is there. The scenes act as components. Each escene with their own nodes which serve a specific purpose can be reused in the main tree as components. So, for example, you don't create one scene with map, player, enemies, ui, objects, etc. you would create as many scenes as you can for re-usability and you would add the scenes to the main scene. So it's a naming thing only but they are essentially components / objects.
@@squelchedotter nodes are components if you want them to be
Thank you UNITY!!! I've been stuck in "Game Engine Choice Hell" for a while now, and just when I needed to make a decision, you made it for me!!! Thank you!!!
LOL
As someone who switched from unity to godot a year ago, i wish you good luck! personally it didn't take me long to get used to the engine, only about a week actually, but i heard a lot of people have troubles with it
20:06 -The Godot editor does have built in documentation, if you right click a node and select "open documentation" it will, essentially, tell you everything you can do with it.
22:51 -Godot does have a _Physics_Process function, that sounds like what you were looking for.
25:04 - ... That's weird. May be a C# thing, when using Godot's editor, the X variable of a transform is a float. This may be an issue with the visual basic
29:19 -Only one script per node, yeah. Most what you would call "Objects" in godet are trees of nodes, a node can double as both an entire object or simply a component of one, depending on how the hierarchy in the scene tree is organized. You wont really need multiple scripts on one singular node.
25:04 is because the transform there isn't the transform section of the node (or whatever it's called in Godot), it's the transformation matrix of the node. So X is actually M00->M03 - it's the first row (or column, depending on which one is major in Godot).
Godot's built in documentation is one of its best features for me
@@AlphaGarg ah, gotcha, thanks for the clarification 👍
When you import anything, you can select the file down left in the file explorer and then go to "import" on the upper left. You can then select the options you want the file to be imported as. For Pixel Art, you can select the Preset "2D" and it works well.
When you add a script to a node, you're basically changing the node type to a new type that inherits from the original node type. You can't add multiple scripts like you do in Unity, because the script is the node, not a component of the node. Everything is done through child hierarchy. For example when you have an Area2D, you add colliders as a child node to it, and the Area2D uses those colliders to determine its area.
Every node has a position property, which you can use instead of the transform. Same for rotation. It's better to use those instead of transform,
The filter option is available on import tab just in godot 3.x. In godot 4, you can set filter option / node (like in 3d / material), and you need to set your main canvasitem node (Node2D) for inherits to all other children.
Thanks, that's helpful!
@@ThotTee addendum: you can set the root node's filter method from the project settings
@@RenderingUseri found it. thanks.
To be specific, in Unity each node (GameObject) is a container of leaf nodes (MonoBehaviour). When moving over to Godot you just have to lift the "main" behaviour up in the hierarchy as all nodes can be both leaves and branches.
So instead of having a GameObject that is both a sprite, a rigid body, and a collision shape you pick what the main feature is for this, presumably the rigid body, which then has a sprite as a child, etc.
It's more straightforward this way, in my opinion. The unity method differentiates between Scene, GameObject, and MonoBehaviour, making one valid as root only, and one valid as leaves only. In Godot your scene can be any type of node, say a rigid body. More straightforward implementation of a tree data structure.
The transform seems to be the Matrix that is used, not a separate component like it is in Unity. It did have functions for translating it it seems, but it makes sense to use the position property instead of reinventing it's implementation.
I personally would use UE as I don't think Godot is ready yet, it's a great product but it still needs some time in the oven, this is my sincere opinion and thoughts about it.
I understand that UE is much harder to learn though since it has so much and it also uses cpp, which is a harder language. (Has BP though but I personally do not use that for heavier calculations)
A mix of cpp and BP is the way to go I think, with cpp doing the heavy lifting.
*That being said,* Godot definitely has a future and I think after this Unity debacle Godot will improve fast because they have an opportunity to fill a void.
And honestly people who say UE is bad for indie or "2D" are just wrong. That is such an old take. You do need patience though because UE is heavy, so many features.
These types of raw videos are amazing, if I'm being honest. It lets the viewer follow along with the presenter's thought process, while allowing them to generate their own thoughts. Personally, this type of video is more useful for me than a tutorial.
This might be one of the most helpful videos for the engine's developers; you're basically giving them feedback on the UX of the editor, I love it
Small tip for using Godot's docs: When using Godot's in-engine script editor, Ctrl + Left Clicking on any built-in class variables will bring you to that document within the editor. For example: Using it on the text "Sprite2D" would open the document for Godot's Sprite2D Class.
P.S. I hope you enjoyed using Godot!
The node system is weird at first but once you get it it's really powerful, for example if you're making a car game, you can have the car body as the parent node and then the wheels, engine etc as child nodes and now all you have to do is swap out the mesh files of the children and you have instant car customization without having to reposition all of the different parts manually.
i tried Game Maker , Unity, Gdevelop, Ue5 ,etc, and for me 2D Godot its the best so far, intuitive node system, you can use a component approach like Unity or OOP, the UI nodes are better, you can animate ANYTHING with Animation Player , much better than the Timeline in Unity
im looking forward to using it
personally I switched to UE5 from unity a while back but for 2D UE5 is a hassle to work with, unless you want super good graphics id go with GODOT as well.
@@kevinzawarrior Unreal Engine 5 wasn't really made for 2D game development, so it being a hassle is understandable.
@@HakoTaco1 yeah it really isn't, I'm working on a retro fps so it uses both 3d and 2d elements so it's really annoying lol
@@kevinzawarrior Tbh, if you are willing to work for it, Godot is also capable of super good graphics. Look at PVKK for example, a game that's releasing soon and is made with godot.
A closed source proprietary game engine capturing most of the indie game market was never going to end well. Sooner or later, there was always going to be someone come along and get the bright idea to treat their customers like cattle.
Watching someone new to godot just opened my eyes
it's like a baby walking lol
I hope you find a engine that's best for you with this unity "crisis" goin on!
Welcome to Godot. Theres plenty of tutorials around to get your feet wet. I have a playlist as well covering how to use GDScript if you want to try out the builtin language. Its all centralized within the editor. Even each classes documenting is all builtin offline.
Try adding a camera2D as a child to the node you want to zoom in on.
The node structure takes a bit to get used to but I don't miss the component structure anymore especially since I feel the scene system is a lot better integrated then the prefab system I constantly had problems with back when I was using unity full time
Honestly, I still use nodes as components. Heck, godot uses nodes as components by default sometimes. Like how it asks you to add collision shape nodes to physics bodies. I've recently taken to more composition based project organisation.
@@RenderingUser yeah, agreed.
That's one of those mind shifts I had to go through
Thanks, I'll give that a shot.
another tip on this is dont be scared to have hundrids of small scenes. it makes working with things a lot easyer and you can put a seen in the node tree
@@RenderingUser And that is why I would say nodes are better, because you can use them as components too, that's great
As someone who only has 22 hours of coding in Godot; Godot is WAY easier to get a hold of and learn Godot than Unity. In 22 hours of using this game engine I have been able to do the following;
1. different animation states
2. Reloading
3. Shooting
4. Wall sliding, wall jumping/ kicking
5. Melee attacks
6. Change the hit box and hurt box
7. Add enemies
8. Sound play
9. Animation pauses
10. change inputs types/ add inputs
11. add combos
etc.
Meanwhile in Unity I was f-ing stuck worse than anything I have ever been stuck in. Godot has to be my favorite game engine so far.
I've also been with unity for over a decade... I hear Godot is looking nice this time of the year... Maybe unreal wants to have a chat with me too.
I mainly use Unreal and dabbled a bit in Godot. Both are good. But I'm so far deep into learning Unreal, I just can't switch engines. Maybe once I create and release a game in Unreal, I might dabble more in Godot.
Me too. Looking into Godot and Unreal right now. Not sure what to pick. Godot is 100% free but lacks lots of features, and Unreal has all the features but coat 5% of revenue. Honestly not sure, both have pros and cons
@diligencehumility6971 its only 5 percent revenue with unreal after you make your first million dollars, so its not that bad.
@@diligencehumility6971 The 5% royalty only kicks in after you make $1 million dollars. The learning curve is massive and it's just information overload for 1 person. You've got so many tools and it's all very powerful and you can do so much. The huge issue I have is the Epic Games launcher, it's garbage.
@@diligencehumility6971 No, it covers that 5% if your game generates 1,000,000 dollars, if you don't get here they don't charge you.
Some little tips:
- with F1 you can get the in editor documentation open.
- In the script Editor crtl + left click on a class opens up the documentation of the class
After the whole Unity drama, I got interested into game engines and downloaded Godot recently. I don't know what I'm doing but I'm down to stick around :D
I don't need tutorials for Godot. I NEED THESE VIDEOS. This video singlehandedly taught me more about godot than any tutorial could've done ever
honestly watching this from someone also new at godot but not new to game dev is way more informative and helpful than a regular godot tutorial
You can set the interpolation type for your parent node. By default each child node will inherit this setting.
So by setting nearest neighbour to your parent scene, all children will use that setting. Quick and easy. Basically you could apply this setting to the very root node and it is set for your whole game.
Welcome! I hope you like it, bro! Godot is really underrated in my opinion, and even though I think they are already doing well on features and always improving, I belive that their core values do matter a lot too. You can really tell that you're using a tool made out of passion from users to users, instead of pure greed.
Wow, I've just met your channel and I loved the video. Differently from other channels, you actually describe what your experience really is, explaining what calls your attention, what seems confusing, familiar, etc.
I wish more channels made "Trying out" videos as descriptive as you just did!
When I changed from Unity to Godot I ended up just switching to gdscript as well. I love C# but GDscript is actually a really nice language and of course better integrated in to Godot.
Yes, I feel bad for how many people will fall into the C# trap. Godot only put the bare effort into it for MS funding. The engine's actual intention is to use GDScript and if necessary C/C++ for speed ups. An example would be for procgen. You might have to implement your own C code for speed up.
@@enochsadventures -- If you had some complicated serialization, taking XML or JSON files and packing/unpacking with something like Ceres to a binary...
In C# that makes sense, but what about GDScript?
@@BrandanLee Godot has a JSON class
@@BrandanLee You write the handler in C# and communicate with it in GD script , you can use both in the same project. So write what you need in C# but if you do most of the design work in GDscript it works well.
@@BrandanLee If it has to be external file type JSON if it can be internal filetype then godot has amazing built in serialization for resource types
I am impressed of how good of an "think a loud" you did here. Like UI/UX people would probably love to have you as a tester.
As someone with only a passing familiarity with Unity and no exposure to Gadot, this was very interesting to watch! Thanks, can’t wait to see what’s next
I played around with Godot the past few days as well.
Incredibly interesting and full of potential.
For my needs its a little light on features, in particular 3D ones such as a Terrain editor and the ability to paint intanced objects for vegetation and the like. I would need to code quite a few tools to get myself up and running with it, but I am keeping my eye on it.
I was particularly impressed with the performance, managed to get10.000 (instanced) objects on screen at over 3k FPS.
Tried the new and improved Unreal 5 as well. Incredible visual fidelity and cutting edge tools, but MY GOD the overhead is crippling.
I struggles to get 400FPS after stripping it as much as I could, on a blank scene. RTX 4080.
So for me Unity is still the tool of choice. But I'm jumping over to Godot the moment they add more 3D features (they are so close).
They are working on a lot of 3D tooling but where quite lite on those recently since they switched their backend to Vulkan which was obviously a enormous undertaking.
one thing that really helped me understand godot was the realization that everything is a node. Every class inherits from node, and everything in your game will be a node. Scripts are attached to nodes and you attach those nodes to other nodes in a tree structure to give them functionality. In unity theres components, think of a node as a component. Attach a script to a node, save that node and drag it into another node to add that "component" to your other nodes.
good luck in your godot journey, the community is great and with unitys fumbling with their pricing model, hopefully our community will grow
Lots of classes don't inherit from Node, but yeah, anything you can add as a node inherits from Node
@@kevinscalesi guess i shouldve been explicit in that anything that attaches to a node is a node. its just a big tree.
Ye, I found it way more intuitive than other engines' way of handling this stuff. Like, UI, characters, worlds, levels, even components that don't even get rendered, like state machines or HTTP request handlers, they are all just nodes. Scenes are also just nodes (although I think this is a really bad naming scheme, because initially I thought a scene was the same concept as a level, but for Godot, scenes are more equivalent to templates). They are not arbitrarily distinct.
In Unreal, for example, all these would be completely different concepts, so you'd need to learn how to interact with each of these, but in godot you just need to learn how to interact with one thing; all others are just extensions of that one thing.
This blew up. A series would fund your next project. Haha, if only. Good stuff
Welcome to the community, man. I personally gave up on Unity close to a year ago, when it started feeling like I was fighting the engine for basic stuff. Godot 4 blew my mind.
Wait until you get a load of the new physics nodes. It's got in-engine support for soft body collisions. It's amazing that it's unconditionally free.
The biggest thing I needed to get used to was Godot's child nodes serving the same purpose as Unity's sibling MonoComponents. Instead of tacking another script onto the same node (which isn't possible), just add a child and tack it onto that, which is what the internal nodes use; or find a way to merge the functionality into the same script. Also note that resources (textures, sounds, models, etc.) are kind of their own thing, and sometimes you need to change their metadata (under the Import tab) to get them to do things, like loop. Lastly you can think of scenes as being _kind of_ like prefabs.
8:00 in settings you can set default render mode for textures and you can change that to `Nearest`. That's why Sprite2D has "Inherit", it inherits from configuration.
Also, think of Nodes in Godot as of classes that have hierarchy. So Sprite2D extends Node2D, and Node2D extends Node etc. So Sprite2D is ALSO a Node2D so it has properties of both.
I hope you explore this further.
I just finished my first project with Godot and am thoroughly happy with it. I dabble in Unreal for Animation and Rendering and it certainly is waaay more taxing and complex. It has all right to be that way, it's a powerful engine, but it also makes simpler stuff, like 2D, that much harder to get into and run. The editor sample projects alone can set your machine on fire with the raw processing power it can require.
This is weirdly inspiring even though it's such a simple first-try thing
From a game dev hobbyist perspective, I was just thinking about how well this shows off his critical thinking skills. “Oh, I noticed this feature I’m used to having in Unity doesn’t seem to be present here. Maybe it’s somewhere I’m not looking or called something different,” shows immense maturity and wisdom as a developer imo. All too often, I feel like people will immediately assume that if something they actually already know is framed in a different context from what their used to, it’s not actually there and they’ll panic and immediately search for tutorials instead of putting in a little more effort to just figure it out.
I found this vid really inspiring, not just as someone who wants to get better at game dev, but also as someone who values and wants to get better at critical thinking and problem solving.
note: on Godot, Up is -Y
but Right is still +X
but.. why? Is there a way to change that through settings? Don't wanna invert every Y axis cos im so used to Unity
@@pasta8026it's canvas coords. It's what makes sense in computers.
@@RenderingUser so theres no way? it's just that every engine and modding software I have experience with use +Y as Up. this will take some time to get used to
@@pasta8026 it's +y up in 3d in godot
But canvas coords always put - y up in 2d
I've seen some game engines use that a lot. The ones that deal with 2d.
It's sort of fine in godot cause you can just use the enums for vec 2
eg: Vec2.UP
It will generate Vec2(0, -1)
@@pasta8026 , GameMaker has the same, Up is -Y
So .. right as you were opening Godot for the first time i got hit with an ad .. and it was so smooth Aannnd a game intro .. .. it took me a few seconds to realize it was a commercial and not some super fancy splash screen .. .. yep.
Nodes in the scene tree (left) and properties in the inspector (right) you can right click -> Open Documentation
Within Godot's code editor, hold control and click on an variable/type/function name within a script to jump to the documentation or where it is defined in your code (at least this works with GDScript). You will sometimes have to do strict typing e.g. var MyVar: String to get auto complete/documentation when doing something like MyVar.format()
As a sucker for Godot, thanks for giving it a shot! Always lovely to see people trying out other engines and giving them a spin.. not the least for one I'm pretty passionate about! Darn freaking shame about the circumstances.
A solution perhaps is to have a shift towards supporting and using open source and/or public owned alternatives.
If there is increased demand for alternatives, I believe open source/public owned alternatives can outshine corporate offerings.
My favorite thing about godot is how often it follows the principle of least surprise. Things are very often where I'm expecting them to be
the X and the Y are basis vectors of the transform they are not the x and y components of the position , basically the transform has a position with xyz ,and three basis vectors X Y Z that describe the orientation. basically its the rotation vectors that you were accessing
Technically proprietary means privately owned / trademarked, but GDScript is just the in-house engine language & ofc open source :D
Actually a pretty good tutorial video. I am not coming from a game dev background and didn't actively look for tutorials but i found it widely interesting to have the insight of someone with solid overall understanding of game engines
Love seeing you experiment and figure things out on the fly, would love to see some more of this
Thanks for this video. I'm in a very similar position of needing to explore other non-Unity options. Godot looks promising.
idk if I should cry or be relieved here..... 10 years dayum.
You can set the texture filter to nearest in the project settings for all sprites :)
Yup, can also deal with the camera issue there too by using the window and viewport settings. I like to use 320x180 and set my viewport to 1280x720 for pixel art games
Great vid! My fav part was hearing your surprise around Godot's build speed
This was entertaining to watch for sure! There are a couple of differences between nodes/scenes and Unity GameObjects/scenes. A scene in Godot is just a collection (or prefab) of nodes with a root node as part of a scene. As such, you can instantiate scenes within scenes however much you want, and each scene is just a tree of nodes (or smaller scenes).
The reason why you didn't see a camera in 2D mode (although there is a 2D camera node) is because the 2D and 3D engine are actually separate. Unity basically draws 2D on top of a 3D background (which can be empty) but doesn't fundamentally distinguish between 2D and 3D outside of specific object types. Godot 2D is a full 2D system, complete with its own lighting and physics implementations, which is why you have separate 2D and 3D nodes for most things. You only had the X and Y on your 2D scene because it doesn't have a Z axis at all, and it's "pixel perfect" because that's the default. If you want to do pseudo-3D in 2D mode you have to fake it with cameras and parallax.
You can only have 1 script per node. That being said, you can have as many "empty" nodes with attached scripts as children of another node. A common design pattern is to create a Node (the type, which is the most basic object you will normally mess with) that just has a script attached as a "component" that runs various functions on the parent. Note that you can also have "autoload" scripts that run independently from any nodes (Project Settings -> Autoload). This is commonly used for "Game Manager" scripts or global functionality. It's also a common place to handle signals between objects in an encapsulated way (signals are very important, somewhat similar to events).
Hope that helps!
This was a cool video, it's really interesting seeing how other people interact and explore. Thanks for posting this! I'm also just starting to look into Godot and the differences to unity are intriguing!
I´ve never seen such a fast change after a new measure, and I couldn´t be more proud.
It was fun watching this, as I hit a lot of the same problems when I first tried Godot 4.
Although, I just used GDScript. Since I was able to translate what I wanted to do, that seemed to be the easiest route.
For setting up default import options for assets (i.e. filtering), see the import tab near the Scene hierarchy panel.
As for having multiple scripts/components per node, you can't. Game objects as containers of components is a very Unity thing. Godot uses an approach more like each node is both an object and a component. To make composite objects you put them as children of others.
This is the most Non Tutorial tutorial yet is going to be the best tutorial out there about Godot.
Welcome to Godot! I hope when you learn the engine you like it and get better at it, Godot has so much potential and i love this engine, I've had a better reception/experience on Godot than Unity for me, personally.
Haven't watched yet but thanks for making this. Downloaded Godot yesterday and back on the learning grind. 💪💪💪
this was awesome to watch, i'm glad the discovery process and thought processes were mostly unedited even if mistakes happened, it helped me learn how to think through things better :)
I really liked the video, this concept is super cool. Since I think that the Godot documentation is really great and that GDScript is easy to learn I'd love to see you blindly jump into the documentation and GDScript and see if you can do the same.
I'm also migrating from Unity to Godot and I'm pretty hyped up about it. Though I have to refactor my scripts to create a backend-frontend structure. Meaning the game logic and framework is the backend that doesn't use any logic of the game engine and could technically run anywhere, and the "frontend" is what interacts with the game engine. I partially did that in Unity already, though still thousands of lines of code to go. Still a good practice IMHO.
The change is quite hard. I did that 2 years ago. But as soon you have it, you will love it.
This was such an awesome video. Very interesting watch. Congrats on the recent success too!
So yeah, one script per node. But for things like state machines you just compose them of Nodes with the scripts attached. Great thing is you can save a single node with script as a scene, then instance it anywhere just like any other node. Export variables that you can tweak in the editor. Saves a lot of time.
This was a really fun watch to see an experienced developer test out new tools!
Note: GDScript isn't proprietary.
It's included in the source code of Godot, which is licensed under the MIT license (which means that it's free and open source)
I think what he meant to say is that it's a language specific to Godot.
@@trickster721 that it is, but it's heavily inspired by Python, so if you know Python you'll probably know most of GDScript, and if you know GDScript you'll probably understand Python.
The main differences I know of is:
func (def in python)
var (python doesn't have a keyword for this)
const (not a thing in python)
match (not a thing in python)
Godot nodes only support one script because it is a mostly object oriented design buuut you can do stuff like
Option 1 (I prefer option 2):
@export var scripts : Array[Resource]
Which lets you attach resources to a a node and you could dynamically load them within the single script so with a little work you could make a system to add multiple scripts to a single node that inherits this “script loader”
Option 2(I generally use this way):
Alternatively a common way I’ve used a lot and seen done in Godot is that you make a custom node for each of your generic scripts you want to add to multiple objects and you add these as child nodes like components
Like for example a movement controller that listens for wasd inputs would be a Node with a script attached to listen for inputs but instead of programming the script to move itself it moves it’s parent
You then can add this component node to any node as a child and it will have movement controls
It is moving slow because you're only moving it by delta pixels each frame, so about one pixel/s. The measurements in Godot 2D are in pixels, not in units (they're in units in 3D).
30:00 "Will have to figure out how to do the multiple script thing later".
Hint: No, you won't 😂
technically you can, by extending with another script with class_name.
@@dustlol5221 that would be great. but afaik you can only extend class derived from the node/object and attach it to a Node. The scene system was designed to work with the node system where you'll have seperate _Process, event listeners etc.. Maybe you can create another file an reference it but it cant override method and functions from the derived class directly.
This showed up in my recommends and I clicked on it in light of the recent controversy. I immediately recognized your voice. This video has some reach!
Thanks for stopping by Brittan :) Good to see you.
I didn’t see anyone else mention it, but the partial modifier is required because Godot utilizes source generators to add code to your classes
A great first look. Thanks for showing us. I've only ever played with Unity and played with Godot but I have made working things in both. It took me a little while to convert my thinking over to the Godot way of doing things but I generally prefer it. In some things it's better than Unity, in some worse, but mostly it's just a slightly different way of thinking about things. It took me a while to work out how to get full Visual Studio integration with running and debugging working from within VS in V4 (well documented for V3) but it is possible. As others have mentioned, the integrated documentation in the Godot editor is well worth investigating. Also V4 of the engine is relatively new and a pretty heavy overhaul so there are a few things that are a little clunky in places in V4 and more stable in V3. But it's improved every time I've updated a point release.
Welcome to Godot!
For me it seems like Godot is a better option than unreal for most people coming from Unity unless you really need the supergreat graphics capabilities of UE5 (which weren’t on unity either anyway). Tho Godot is pretty much on-par with Unity, and will get even better with time. You also benefit from the ✨open source✨ thing and all, and it’s literally impossible for godot to pull an unity move.
Unreal does have its nice parts too, but it’s not like you have to always stick to one engine either: you can always use one or another depending on what will fit better your needs for the specific game you’re making.
The node system is something you come to love while working with Godot
Its so funny to see the splash-screen sensitivity of unity converts ^^. It is just a check mark. And it will not charge you anything ^^ All good bro, you will unlearn certain anxieties pretty quickly.
liked this video just because Godot, as an open source engine, is fundamentally like good for the industry if it becomes a larger part of it. have not watched yet, will do
I would definitely love a part two of learning Godot, very entertaining and fun.
Welcome to Godot, I made my transition few months back from Unity into Godot. I was working in Godot 4.1.1 now trying out 4.2 RC. I was starting out as C# but i had some issues where my UID's would be changed and cause some issues about not finding components, this can be solved by viewing dependencies and relocating them. So far after a month using GDScript I haven't run into this issue since then. I am actually liking Godot as the more I use it, also 35:26 that is what also turned me over to using GDScript was the fact that error dialogs would be zipping through without being able to read them
I would watch a series of that.. maybe I would start again trying to learn godot
The node / scene system is really functional and intuitive when you get ahold of what and how it's abstracting things.
You'd make a scene and setup a parent node and children nodes for say, a character or setpiece. Then combine those smaller scenes on a bigger level scene. It's procedural in the sence you can edit a single separate "enemy scene" and have that enemy update its instances across all your levels
Using children nodes would be how you have multiple scripts / objects under a parent node
I really wish Godot to blow up. Especially because it has a native Linux version and it's a lot easier to make Linux supported games with Godot than Unity and UE.
Linux gaming is getting more and more popular.
honestly impressive how much you managed without looking up anything at all
I love the concept of this video. I was literally trying out Godot for the first time yesterday, too. Spent a lot of time playing with the Material parameters lol.
Godot experts, its your time to shine!!! There's a vacancy or lack of UA-cam experts on Godot. Better get cracking to gain the algorithms good wishes.
this will be me soon, 10+ years plus of using unity, now time to change, but not sure either unreal or godot.
With 10 years of experience moving to either one will be easy, the best advice here is to test multiple engines and pick what is a good match in terms of workflow and features needed.
if u don't think about making so big games godot 4 is the best not in graphics but every tool every node you gonna use in godot is made for u for making the game easier and u can change or make what ever u want in godot like unity , unreal is for 3d ik there is alot of 2d games have made by unreal but godot is better for 2d than unity and unreal and for 3d 🤷🏻 its just a time if godot growth like how its growth RN in few years there is no reason to use unity and if u want AAA graphic for your game unreal the onlyone in the stage
@@VectorDevIMO Unity is King of 2D, but I cannot use Unity after recent events. So now Ill say Godot is the Best option for 2D, hands down. And Unreal is best option for 3D. Both should I learn both?
Ah the rhyming at the start 😌
as a Godot User it's really fun to see you stumble your way around, Great Video :)
definitely give godot a shot. its different than unity on so many levels. and it really is a great engine if you understand it
The best way to see if it's viable is to try it! Was a good watch.
i am so happy for you to try anything but unity... good luck ! and a lot of patience. it will be good
I was reading the documentation for Godot and then stumbled across this video and decided to watch it first. Thought maybe seeing someone play around in the engine will make the documentation make more sense.
To make the sprite bigger for "uneven" pixel art you can just just increase the scale of the base node2d. You can do a better job of this in project settings, display/window/ and setting stretch scale.
If you want pixel perfect rendering, you can instead go to the same exact page in project settings, and set the viewport width and height to smaller values more in line with a retro system. Then set the stretch mode to 'viewport'.
The first thing I did when hearing about Unity's decision was open up Godot and make a Rust extension. Favourite language, and may become my favourite game engine.