My usual "learning by doing" approach fails with #Godot and I don't like that. ;__;
-
Willowreplied to Natasha Nox πΊπ¦π΅πΈ last edited by
@Natanox Learning curve steep. Do it like a mountain. Slowly, deliberately, attentively. If you go too fast... well you won't fall, but you will get stuck. Unless it makes you rage quit, I guess.
Good luck and have patience. οΈ -
Natasha Nox πΊπ¦π΅πΈreplied to Willow last edited by
@Paradox Thanks.^^ Stuff like this feels more like a hall full of doors though. Once I learn how to open one the next one is 10cm ahead. And some doors even require multiple keys.^^ So it gets frustrating rather quickly, especially if I don't have a clear inner "map" yet how stuff is related (as I mention sometimes, everything is visually to me, even code, language, concepts etc).
And I get confused by the stuff that's being done in GUI because I keep expecting it on code. xD
-
dasparadoxonreplied to Natasha Nox πΊπ¦π΅πΈ last edited by
@Natanox have you done unity or unreal or another engine where you did not have this feeling ?
-
Natasha Nox πΊπ¦π΅πΈreplied to dasparadoxon last edited by
@tomtrottel No, in terms of game engines this is my first one. I've learned other tools like Blender, Inkscape, Photoshop (from back in the days) and am learning Kdenlive and (soon) Ardour. Usually once I get a hang of the basic shortcuts it doesn't feel like that anymore because any knowledge from that point on is 'adding to an existing base', not a hard requirement for the next step. A lot can also be inferred; I supposed that's the case for Godot as well once you know *all* the basics.
-
Natasha Nox πΊπ¦π΅πΈreplied to Natasha Nox πΊπ¦π΅πΈ last edited by
@tomtrottel Since I'm more of a visual learner a tool build around multiple intertwined, abstract concepts is more or less my arch nemesis. π€
-
DreamGryphonreplied to Natasha Nox πΊπ¦π΅πΈ last edited by
Here is a video explaining all nodes in Godot, maybe that helps a bit? https://www.youtube.com/watch?v=tO2gthp45MA (timestamps are in the pinned Youtube comment)
-
Natasha Nox πΊπ¦π΅πΈreplied to DreamGryphon last edited by
@DreamGryphon Thank you. Right now I'm stopped by how different scenes relate to each other and how I can access information from a node in a different scene. There seem to be multiple solutions, the most prevalent being autoloading in the project settings or working with signals.
I'm not sure how to visualize a project yet that consist of multiple scenes except as multiple class structures next to each other with a lot of parenthesis.
-
Jonathan Hartleyreplied to Natasha Nox πΊπ¦π΅πΈ last edited by
@Natanox hey, I'm learning Godot too, and definitely empathize with that.
-
Jonathan Hartleyreplied to Jonathan Hartley last edited by
@Natanox ah, now I've read to the end of your thread, I definitely struggled with exactly that (relating to different scenes) but I feel like i sort of have the hang of it now. Let me see if I can condense my mental model into a few useful words...
-
Jonathan Hartleyreplied to Jonathan Hartley last edited by
@Natanox What's your background? Are you a programmer who is learning Godot/gamedev? (That's me)
-
Jonathan Hartleyreplied to Jonathan Hartley last edited by
@Natanox When you define the **main** scene in the editor, then it contains one or more classes, and parent-child relationships between them. When you run your game, godot creates one instance of each of these classes, with the relationships between them. So a parent node can refer to its children with $ChildName, and children can refer to their parent with .get_parent(). So far, so good.
-
Jonathan Hartleyreplied to Jonathan Hartley last edited by
@Natanox When you define **other** scenes in the editor, these also consist of trees with parent and child relationships. However, when you run your game, godot will not, by default, create instances of these classes, so they don't exist and cannot be referenced by your running game.
-
Jonathan Hartleyreplied to Jonathan Hartley last edited by
@Natanox To create them, some code in your main scene must instantiate the other scene, using load or preload to create it:
var scene = load("res://my_scene.tscn")
This creates the tree of scene nodes. Then you need to add this scene to your running main tree of nodes:
add_child(scene)
-
Jonathan Hartleyreplied to Jonathan Hartley last edited by
@Natanox When you do this, your main tree gets modified, by adding a copy of the other scene to it. The 'add_scene' function adds scene as a child of the current node.
Now that they are in the tree, the nodes in your other scene will become "active", getting their "_ready" and "_process" and "_draw" functions called, etc.
-
Jonathan Hartleyreplied to Jonathan Hartley last edited by
@Natanox When figuring out how to reference nodes from other scenes, envisioning your main tree is the important mental model. When seeking to reference another node, you must visualize the relationship between the node of your calling code, and the node it wants to reference. Whether the referenced node came from another scene, was loaded dynamically at runtime as described above, or was put in the main tree by your editor and has been there all along, is irrelevant at this point.
-
Jonathan Hartleyreplied to Jonathan Hartley last edited by
@Natanox So you can use the $Child/get_parent() tools I mentioned above, to reference your immediate children or parents.
Or you can use get_node() to reference nodes further away from your current node.
Nodes and scene instances
This guide explains how to get nodes, create nodes, add them as a child, and instantiate scenes from code. Getting nodes: You can get a reference to a node by calling the Node.get_node() method. Fo...
Godot Engine documentation (docs.godotengine.org)
-
Natasha Nox πΊπ¦π΅πΈreplied to Jonathan Hartley last edited by
@tartley That explanation is extremely helpful, thank you! Makes perfect sense the way you describe it. It seems like I had a false interpretation of the word "scene" and tried to use the engine in a rather convoluted way.
Adding and removing complex scenes at runtime will probably only get interesting with very large projects where you don't want unnecessary junk cluttering the memory. -
Natasha Nox πΊπ¦π΅πΈreplied to Natasha Nox πΊπ¦π΅πΈ last edited by
@tartley In regards to the other question, my background is one of "amateur at everything, master of nothing". π€ I've learned almost every single kind of tool at some point (except for music production / DAWs) but never had the opportunity to use them productively beyond one or two projects (most of them hobby projects). I'm actually quite happy about GDScript being so similar to Python, Pascal and BlitzMax given I once learned to use the latter - still learning Rust though, too. π€