up:: [[Godot MOC]] tags:: #note/develop #on/computing/gamedev # Godot Best Practices This is a collection of best practices for using the [[Godot MOC|Godot Engine]]. This is not an exhaustive list, but rather a list of things I've picked up during my [[Godot Learning Plan|learning journey]]. If you are interested in this topic, I highly recommend reading through the Best Practices Guide on [Godot's documentation website](https://docs.godotengine.org/en/stable/tutorials/best_practices/introduction_best_practices.html). ## Design Principles The Godot team recommends applying object-oriented principles to your projects. Principles such as Single Responsibility and Encapsulation are useful for creating projects that are clean and scalable. ### Understanding Scripts and Scenes [[GDScript|Scripts]] and [[Godot Scenes|Scenes]] are the two ways that you can create reusable objects in Godot. Neither of them actually define any classes under the hood, but it's still useful to think of them that way since most of the best practices involve applying object-oriented programming principles to them. #### Scripts ##### How Scripts Work Before touching on how to effectively use scripts, we need to understand how they work. Scripts can be used to extend built-in nodes and create derived types. They are not technically classes, but rather resources that tell the engine a sequence of initializations to perform on a built-in class. Godot's internal classes have methods that register a class's data with a [ClassDB](https://docs.godotengine.org/en/stable/classes/class_classdb.html#class-classdb) object. This object provides runtime access to metadata stored for every available class, including properties, methods, constants, and signals. When objects perform an operation like accessing a property or calling a method, they check the ClassDB to verify whether that operation is possible. Attaching a script to an object extends the methods, properties, and signals available from the ClassDB. ##### Script Inheritance Scripts that don't use the `extends` keyword implicitly inherit from Godot's base `RefCounted` class. This is why you can instantiate scripts without `extends`. However, since they extend `RefCounted`, you cannot attach them to a `Node`. #### Scenes ##### How Scenes Work Scenes behave similarly to classes. They are reusable, instantiable, and inheritable groups of nodes. Creating one is similar to having a script that creates nodes and adds them as children using `add_child()`. Instances of scenes are objects, so many object-oriented principles apply to them. These include single responsibility, encapsulation, and more. Scenes are often paired with a scripted root node that makes use of the scene's nodes. You can interpret a scene as part of a class, since scenes are always an extension of the script attached to its root node. **Most of the techniques explained in this note build upon this point.** ### Organizing Your Scenes #### Dependencies > [!TIP] Best Practice > If possible, design your scenes to have no dependencies. With OOP, one of the biggest things to consider is maintaining singular-purpose classes with loose coupling. This keeps the object sizes small and improves their reusability. Scenes should keep everything they need within themselves. In cases where they really do need to interact with an external context, use [[Dependency Injection]]. See the [Godot documentation](https://docs.godotengine.org/en/stable/tutorials/best_practices/scene_organization.html#how-to-build-relationships-effectively) for more details and examples. #### Node Tree Structure > [!TIP] Best Practice > A game should always have a singular "entry point". This is a place where a developer can track where things begin and follow the logic as it continues elsewhere. In most cases, the entry point would be the Main node. Your game world and GUI would be children of the Main node. In this case, you would be able to change levels by just swapping out the children of the World node. > [!TIP] Best Practice > Consider what gameplay systems your project requires. Each subsystem within a game should have its own section within the scene tree. Carefully consider what types of systems your game has. For example, if you have a system that tracks all of its data internally, should be globally accessible, and should exist in isolation, then you should create an [autoload singleton node](https://docs.godotengine.org/en/stable/tutorials/scripting/singletons_autoload.html#doc-singletons-autoload). Likewise, if you have systems that modify other systems' data, then you should define those as their own scripts or scenes. ### When to Use Scenes Vs. Scripts ## References Juan Linietsky, Ariel Manzur, and Godot Community. “Best Practices.” Accessed March 1, 2024. [https://docs.godotengine.org/en/stable/tutorials/best_practices/index.html#](https://docs.godotengine.org/en/stable/tutorials/best_practices/index.html#).