{"id":701,"date":"2023-10-22T18:19:20","date_gmt":"2023-10-22T23:19:20","guid":{"rendered":"https:\/\/www.jasonsblog.place\/?p=701"},"modified":"2023-10-22T18:19:20","modified_gmt":"2023-10-22T23:19:20","slug":"tips-for-making-scenes-and-nodes-modular-in-the-godot-engine","status":"publish","type":"post","link":"https:\/\/www.jasonsblog.place\/index.php\/2023\/10\/22\/tips-for-making-scenes-and-nodes-modular-in-the-godot-engine\/","title":{"rendered":"Tips for making scenes and nodes modular in the Godot engine"},"content":{"rendered":"\n

When I\u2019m designing a game, I try to make the nodes and scenes modular. When they are modular, the scenes can be placed in many situations and are easier to debug. This is even recommended by the developers of the engine (see more examples from the developers in the Godot documentation<\/a>). So please join me in a little article on making nodes and scenes modular.<\/p>\n\n\n\n

Note<\/strong>: this is meant for intermediate to advanced designers of the Godot engine. The concepts and code discussed here may be unfamiliar to those who haven\u2019t been programming for a while, or who haven\u2019t made a few games, and have not read up on object oriented programming (OOP). Also note that some of the syntax described here works in Godot v3.4 and v3.5. It has not been tested in Godot v.4.0+.<\/p>\n\n\n\n

Self containment<\/h2>\n\n\n\n

A node or a scene should rely mainly on what’s in the scene or node. If a node must<\/em> depend on something outside of it, then it should at least be given to the node (something I think is called “dependency injection”). I usually do it like this:<\/p>\n\n\n\n

# Top of the script for the node or scene.\nextends Node2D\n# This is the node that will be \"injected\" into the node or scene.\nexport(NodePath) var foobar_node_path = @\"\"\nonready var foobar_node = get_node_or_null(foobar_node_path)<\/pre>\n\n\n\n
After that is written in the node’s script, I add it to the node via the editor:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Then all I need to do is instance this node in the modular scene:<\/p>\n\n\n\n
# You can do this in the `_ready()` function. Or you could do it in other parts of the script.\nfunc _ready():\n    var foo = foobar_node.instance()<\/pre>\n\n\n\n
Be careful when using NodePath<\/code>s. They should not be used for nodes that will move around the scene tree (or will be freed at runtime). It is best to rely on the editor to generate the NodePath<\/code>, or have them constructed programmatically. To get the path of a Node<\/code>, use the get_path()<\/code> method of the Node<\/code> class:<\/p>\n\n\n\n
var my_path = foobar_node.get_path()<\/pre>\n\n\n\n
Loose coupling<\/h2>\n\n\n\n
When you have a node that’s modular, it still<\/em> has to perform its job: the node has to show the bad guy, the scene has to animate the main character, or the node just needs to keep track of things. So how do you make it usable yet also prevent it from wrecking the other parts of the game with bugs and stuff? Use this motto from the developers: call down, signal up<\/strong>. What does that mean? In the scene tree of your average Godot scene, all of the nodes are arranged in a tree, with one node as the root. The parent of nodes can call methods on their child nodes so as to get them to do something. When they need to call to sibling nodes or other parent nodes, they can use signals to get those other nodes to react. Here’s some examples of calling down and signaling up.<\/p>\n\n\n\n
We have here a scene tree:<\/p>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
The Mama_node<\/code> can call methods on the Baby_node<\/code> so as to get it do something. Here’s something that the Baby_node<\/code> may do:<\/p>\n\n\n\n
## In Baby_node\n# These variables are local to the Baby_node, and should only be used in this node, or its child nodes.\nvar health = 10\nvar move_distance = 10\nfunc move_player():\n    # Move the player here with something like move_and_slide().<\/pre>\n\n\n\n
In this example, the Baby_node<\/code> has the Player_node<\/code> as a child. It can use its methods, variables, and what-have-you to perform actions on the Player_node<\/code>. If the Mama_node<\/code> needs to move the Player_node<\/code>, it could call down<\/em> to the Baby_node<\/code>. When the Mama_node<\/code> needs to have the Player_node<\/code> do other things (like take damage in some cutscene), it can access the health<\/code> variable on the Baby_node<\/code>. All that the Baby_node<\/code> needs to worry about is the Player_node<\/code> (or any other child nodes in its custody). It doesn’t need to worry about the enemy nodes, or the scenes that need to interact with the Player_node<\/code>; that’s something for the Mama_node<\/code> (or higher parent nodes) to solve. So what if the Baby_node<\/code> needs to tell the Mama_node<\/code> (or other important nodes) about the Player_node<\/code>? That’s where the node needs to signal up<\/strong>.<\/p>\n\n\n\n
On the Baby_node<\/code>, a signal may be defined:<\/p>\n\n\n\n
# In the script attached to the Baby_node.\nsignal player_died<\/pre>\n\n\n\n
When another node (such as the root_node<\/code> or some “director” node) needs that information, all it needs to do is listen for this signal. It may be hooked up like this:<\/p>\n\n\n\n
# In a script attached to some \"director\" node.\nfunc _ready():\n    connect(\"player_died\", self, \"_on_player_death\")\n\n# Further down the script.\nfunc _on_player_death():\n    # Show player death animation, and fade to black.<\/pre>\n\n\n\n
Now these two nodes (or scenes) don’t need to rely on each other. The “director” scene can have its optional player death (either by directly animating it, or using an AnimationPlayer<\/code> node). This also helps with debugging. When we encounter a bug where the player is suppose<\/em> to die and doesn’t, we don’t have to go far to figure out where the error is. We could look in the Mama_node<\/code> (which has indirect access to the Player_node<\/code>), or we could look at the Baby_node<\/code> (the most likely culprit) for our bug. When we reduce our nodes and scenes to separate steps in the possible states of what can happen, it makes debugging easier because we know where in the steps how things are suppose<\/em> to happen.<\/p>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
Hope you enjoy these couple of tips. I’m sure there are many<\/em> other ways the scenes and the nodes (or various objects) of the Godot engine can be made modular. Just remember to watch out for code or designs which break NodePath<\/code>s, mess up function calls, or make it difficult to use signals, and your development journey will be made easier.<\/p>\n","protected":false},"excerpt":{"rendered":"
Making modular scenes and nodes in the Godot engine will really help with moving around objects and pieces of a game. Here’s some tips on making your game more modular.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7,76,31],"tags":[55,106,91,54,23],"class_list":["post-701","post","type-post","status-publish","format-standard","hentry","category-information-technology","category-programming","category-video-games","tag-design","tag-game-development","tag-godot-engine","tag-programming-languages","tag-video-game"],"_links":{"self":[{"href":"https:\/\/www.jasonsblog.place\/index.php\/wp-json\/wp\/v2\/posts\/701","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.jasonsblog.place\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.jasonsblog.place\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.jasonsblog.place\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.jasonsblog.place\/index.php\/wp-json\/wp\/v2\/comments?post=701"}],"version-history":[{"count":2,"href":"https:\/\/www.jasonsblog.place\/index.php\/wp-json\/wp\/v2\/posts\/701\/revisions"}],"predecessor-version":[{"id":705,"href":"https:\/\/www.jasonsblog.place\/index.php\/wp-json\/wp\/v2\/posts\/701\/revisions\/705"}],"wp:attachment":[{"href":"https:\/\/www.jasonsblog.place\/index.php\/wp-json\/wp\/v2\/media?parent=701"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.jasonsblog.place\/index.php\/wp-json\/wp\/v2\/categories?post=701"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.jasonsblog.place\/index.php\/wp-json\/wp\/v2\/tags?post=701"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}