Applying object-oriented principles in Godot

Still, many best practices using Godot involve applying object-oriented programming principles to the scripts and scenes that compose your game. That is why it’s useful to understand how we can think of them as classes.

This guide briefly explains how scripts and scenes work in the engine’s core to help you understand how they work under the hood.

The engine provides built-in classes like . You can extend those to create derived types using a script.

These scripts are not technically classes. Instead, they are resources that tell the engine a sequence of initializations to perform on one of the engine’s built-in classes.

• Methods.
• Constants.

This ClassDB is what objects check against when performing an operation like accessing a property or calling a method. It checks the database’s records and the object’s base types’ records to see if the object supports the operation.

Attaching a Script to your object extends the methods, properties, and signals available from the .

Note

Even scripts that don’t use the extends keyword implicitly inherit from the engine’s base class. As a result, you can instantiate scripts without the keyword from code. Since they extend Reference though, you cannot attach them to a Node.

Scenes

We often pair a scene with a scripted root node that makes use of the scene’s nodes. As such, the scene is often an extension of the script’s declarative code.

The content of a scene helps to define:

• What nodes are available to the script
• How they are organized
• What signal connections they have with each other

Why is any of this important to scene organization? Because instances of scenes are objects. As a result, many object-oriented principles that apply to written code also apply to scenes: single responsibility, encapsulation, and others.

The scene is always an extension of the script attached to its root node, so you can interpret it as part of a class.